How to use XMPP/Jabber while switching between networks?

Question

When running a Jabber client what happens (or what should happen) when switching networks (or when losing connectivity and the GSM/UMTS modem reconnects)?

Can a mobile Android Jabber client (e.g. Jabiru) be smart about such situations?

Worst case scenario I can imagine: Client does not care, TCP (over TLS) connection to the Jabber server is lost, the Jabber status (displayed remotely) is bogus and there is a time window where messages (from buddies) are lost.

I observed such a worst case for example with a stock Jabber client on a Laptop using an unreliable UMTS connection.

When using a Laptop I can easily shield my Jabber session like this:

• connect via autossh to a system with a stable network connection and directly run screen -Rd
• start a console Jabber client inside screen

Thus, when losing the mobile internet connection the connection to the Jabber server is still fine. And autossh automatically reconnects and re-attaches to the running screen session when a new mobile connection is up.

Is a setup similar to this necessary when using Jabber on an Android device?

Or are there Jabber protocol extensions for mobile clients that actually help to avoid losing messages etc. in network on/off situation (while being connected to a Jabber server)?

Answer 1

^{Not sure if this question is on-topic on Android Enthusiasts. But I work with XMPP and Android, so here is my answer:}

As Lie Ryan already stated, a handover from one mobile cell to another is almost always transparent to the TCP stack on Android devices. But there are situations where the IP of your Android device will change. This are typically GSM/UMTS <-> WiFi switches, which will cause the TCP connection to become unusable by the XMPP client.

On Android the standard XMPP library that most clients use - besides having their own proprietary one - is (a)Smack: Clients that use (a)Smack with the default configuration will not notice a connection change in a timely manner. But there is hope: XMPP Ping support is in Smack trunk and will be shipped with the 3.3 release. Most aSmack apps already use an aSmack version that has support for it, and just need to implement according measures.

On the other side it's the XMPP servers job to set your presence to unavailable (offline) after a (server defined) timeout for reaching the last client of the JID in question.

So it is not necessary to build workarounds if you are using a proper XMPP client, but you may have to live with ghost status situations that should resolve after a few minutes.

There is a nice XEP (XMPP Extension) that would be the silver bullet for mobile XMPP Connections: XEP-0198 - Stream Management. You can read about it in Ge0rg's Blog.

It's being worked on for (a)Smack. But it will take a while until it's stable and you need also server support for XEP-0198.

Answer 2

I'm not an expert in mobile networking, but AFAIK the TCP stack should handle mobile handover transparently, application programs should not need to be aware that the mobile network layer are switching from cell tower to cell tower. From the application program's perspective, there is just one continuous connection.

The only reason I can think of about what you're seeing in the laptop jabber client is that it did not use keepalive when opening a long running TCP connection. When there is a long period of no transmission, one of the intermediary nodes in the network (usually the firewall) may decide to terminate the connection (usually to save resources to serve other active connections) and the server therefore didn't have the chance to tell the client to terminate cleanly. Not using keepalive for a long running connection will make it impossible for the client to detect that the connection has been dropped because the only way for a client to detect a dropped connection is if it tried to send a packet and failed permanently.

Keepalive will cause the TCP stack to periodically ping the server with zero length ACK packets, therefore intermediary nodes will consider your long running connection to still be active and not terminate it.