5 ms·

Meh. The whole thing seems to be a shallow summary of various messengers without any detail what made them fail (e.g. Why is HTTP/WebSockets bad?) only to arriv

Meh. The whole thing seems to be a shallow summary of various messengers without any detail what made them fail (e.g. Why is HTTP/WebSockets bad?) only to arrive at the desired "XMPP > * ;)" Conclusion. I don't know why XMPP handled the congestion well, but I suspect the author doesn't either.

upofadown 5y ago
It is not intended to be anything more than a user experience report. This is a pretty reasonable explanation for the Matrix case: >When joining a room, it has to sync everything since the last time the client connected, or in some cases, a ton of history, like megabytes of it. In general you would expect that a stateful message protocol over HTTP over TCP/IP would have a rougher time than mostly stateless XMPP over TCP/IP.
p_l 5y ago
Probably majority of difference involved various kinds of history downloads (like with Matrix). There's nothing special when it comes to base WebSockets-over-TLS vs XMPP, except that there's a possibility that the Websockets-based sytem is more efficient (XMPP has pretty big overhead)
- Zash 5y ago
  WebSockets is just another transport method, by itself it is not going to be very different from plain old TCP/TLS sockets. Other things are going to matter more, like how 'chatty' the protocol is, especially while you are not actively sending messages. XMPP has historically been quite chatty while idle, but todays modern XMPP servers know to optimize traffic so that your phone can sleep undisturbed in your pocket until something important like a message or a call comes in.
MattJ100 5y ago
Not exactly an answer to your question about the original author's experience, but there has been more detailed analysis done about XMPP on very constrained networks. See for example https://www.isode.com/whitepapers/low-bandwidth-xmpp.html https://www.isode.com/whitepapers/low-bandwidth-xmpp.html
toast0 5y ago
If you want to work on overloaded networks like these, there's a lot of stuff you can do, but these are the basics: 0) be able to work offline; try to connect in the background to send and retrieve (but be reasonable so you don't eat the battery) 1) plan for DNS failure; keep last successful DNS response around for later, and have a pool of fallback IPs when you don't have a working response 2) make sure encryption session resumption works (TLS or otherwise), as this lets you send data with one round trip 3) send important data first; usually that's messages, not telemetry and crash reports 4) Make sure to do as good as you can with MTU problems. It's 2022, but pathMTU is still an issue. iOS is (or was) actually really good at shifting to smaller packets and sending smaller MSS in future SYNs; at least last I looked, Android doesn't do anything useful. Server side, there's ways to do better if you're dedicated, but at least making sure icmp need fragmentation packets get processed is the baseline.

upofadown 5y ago

It is not intended to be anything more than a user experience report. This is a pretty reasonable explanation for the Matrix case: >When joining a room, it has to sync everything since the last time the client connected, or in some cases, a ton of history, like megabytes of it. In general you would expect that a stateful message protocol over HTTP over TCP/IP would have a rougher time than mostly stateless XMPP over TCP/IP.

p_l 5y ago

Probably majority of difference involved various kinds of history downloads (like with Matrix). There's nothing special when it comes to base WebSockets-over-TLS vs XMPP, except that there's a possibility that the Websockets-based sytem is more efficient (XMPP has pretty big overhead)

Zash 5y ago
WebSockets is just another transport method, by itself it is not going to be very different from plain old TCP/TLS sockets. Other things are going to matter more, like how 'chatty' the protocol is, especially while you are not actively sending messages. XMPP has historically been quite chatty while idle, but todays modern XMPP servers know to optimize traffic so that your phone can sleep undisturbed in your pocket until something important like a message or a call comes in.

MattJ100 5y ago

Not exactly an answer to your question about the original author's experience, but there has been more detailed analysis done about XMPP on very constrained networks. See for example https://www.isode.com/whitepapers/low-bandwidth-xmpp.html https://www.isode.com/whitepapers/low-bandwidth-xmpp.html

toast0 5y ago

If you want to work on overloaded networks like these, there's a lot of stuff you can do, but these are the basics: 0) be able to work offline; try to connect in the background to send and retrieve (but be reasonable so you don't eat the battery) 1) plan for DNS failure; keep last successful DNS response around for later, and have a pool of fallback IPs when you don't have a working response 2) make sure encryption session resumption works (TLS or otherwise), as this lets you send data with one round trip 3) send important data first; usually that's messages, not telemetry and crash reports 4) Make sure to do as good as you can with MTU problems. It's 2022, but pathMTU is still an issue. iOS is (or was) actually really good at shifting to smaller packets and sending smaller MSS in future SYNs; at least last I looked, Android doesn't do anything useful. Server side, there's ways to do better if you're dedicated, but at least making sure icmp need fragmentation packets get processed is the baseline.