[HN Gopher] Internet Messaging vs. Congested Network
___________________________________________________________________
Internet Messaging vs. Congested Network
Author : zaik
Score : 41 points
Date : 2022-02-05 11:47 UTC (11 hours ago)
(HTM) web link (blog.lewman.com)
(TXT) w3m dump (blog.lewman.com)
| raspyberr wrote:
| I wonder why they didn't try out IRC. Especially considering one
| of their previous posts was about IRC.
| kitkat_new wrote:
| it wouldn't have ended up with XMPP>*
| sirl1on wrote:
| 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.
| MattJ100 wrote:
| 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
| toast0 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| asifhoss wrote:
| Without even reading this, lemme guess, XMPP good, rest bad?
| kichimi wrote:
| The article ends with "XMPP > * ;)"
| amaccuish wrote:
| XMPP is good, but I still remember my BlackBerry being able to
| send pictures and messages over BBM over a GPRS network fairly
| swiftly.
|
| Does make one wonder how many inefficiencies are building up in
| our modern infrastructure.
| jancsika wrote:
| > 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.
|
| Not sure I understand. Does it block the UI? Or is the author
| saying it has to do this before you can send a message?
| denton-scratch wrote:
| > tor doesn't handle heavily congested networks very well
|
| I know that actually _running_ tor on a congested network doesn
| 't work well; but unless the author is trying to run a tor node
| through that Verizon tower, then isn't the thing that isn't
| working very well the congested network, rather than tor?
| Arathorn wrote:
| Well, this is why we have low bandwidth Matrix...
| https://matrix.org/blog/2021/06/10/low-bandwidth-matrix-an-i....
| upofadown wrote:
| >Apparently this Verizon tower doesn't carry other traffic, as
| non-Verizon phones don't connect for voice or data.
|
| That seems wrong. It implies that things could be better with
| respect to regulation in that part of the world. You should not
| have to build one tower per brand in rural areas.
___________________________________________________________________
(page generated 2022-02-05 23:02 UTC)