Internet Messaging vs. Congested Network
blog.lewman.com
blog.lewman.com
>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.
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.
Does make one wonder how many inefficiencies are building up in our modern infrastructure.
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.
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?
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?