[folex]

How about XMPP performance on low-performance networks like mobile ones?

I believe poor networking performance was one of the reasons XMPP had to be customised in WhatsApp and overall didn't become as widely used as I'd like it to be :)

Is it still the case? Or was that problem addressed at standard level somehow?

[SamWhited]

I first started using XMPP heavily in 2014 when I was thru-hiking the Appalachian Trail. Much of the trail has extremely limited cell coverage (even if you can get Edge some of the towers are so bad you can literally only get a few bytes per second). I evaluated several different protocols and apps for communication with family, and XMPP beat them all hands down every time. The long lived TCP connections meant that once a connection was established I could keep it up and it would sit there slurping up the bits as it came. That experience later led me to get involved with the community and even write a spec about using XMPP on high-latency low-bandwidth networks.

It may have been bad at this at one time, I don't know, but at least since I've been using it's been fantastic with poor network quality, I suspect the people saying otherwise are just repeating something they learned in the early 2000s that's no longer true.

[davecridland]

XMPP is routinely used on HF radio and SATCOM networks field-deployed by militaries. It's deployed with channel compression (so the links themselves are compressed), but it routinely operates down to way way below mobile. In general, the really bad links are used for federation (s2s) rather than client connections which demand lower latency for user interaction. I've personally watched it operate on HF radio modems down to single-figure bits per second - those are simplex links with a 30 second turnaround. It's slow of course, but it does work - and this is on the base standard. Any server can do this, there's three I know of in use.

WhatsApp decided, at some point in the past, that XML was too verbose and compressed it using a technique borrowed from WAP - essentially a fixed-dictionary compression. Newer WhatsApp systems don't ever bother decompressing to XML, and it's likely it can't be anymore, but it's fundamentally the same traffic patterns even now. Your WhatsApp account still has a jid (with a very short, fake domain) and so do your groupchats (also a very short fake domain). The WAP compression choice was unfortunate, as it only really had an effect back in GPRS/EDGE days, only on certain networks, and only on certain traffic patterns, because it's the number of packets that matter in most cases, not the number of bytes. There'd still be some rare benefit on 3G, but by 4G the benefit had all gone.

Meanwhile, clients like Siskin and Conversations work just fine on modern mobiles. Conversations (an Android client) does work better when given permissions to keep the sessions live rather than rely on push notifications, but testing has consistently shown that battery life in unaffected. There's a number of extensions that are widely deployed that help efficiency, for sure, and I'd not want to run without for preference - though it is possible, and not as bad as you'd think.

So I'd say that XMPP has no performance problems at all on "long thin" networks way beyond mobile.

To get the same performance out of anything based on HTTP, you need to recode to use the parallel protocols of CoAP and friends. Matrix have done this, but it means specialist clients and servers are needed, and as far as I'm aware there's only a single implementation.

[rakoo]

That is a situation documented by people years ago, and has been wrong for years. See https://gultsch.de/xmpp_2016.html. Unfortunately the legend lives on because "it doesn't work" is a better soundbite than "it works"

[southerntofu]

Some extensions like XEP-0352 Client State Indication have been developed to fit the mobile world. XMPP on mobile is nowadays very reliable, except for iOS preventing 3rd party notifications.