Georg Lukas, 2009-10-27 00:49
XEP-0198: Stream Management is an XMPP extension adding stanza acknowledgements and stream resumption.
What does that mean in English? If you are using Jabber on your cell phone, you are not going to lose messages anymore whenever you get out of service coverage.
So, why do we need it?
Even though Jabber is using TCP, which is called a reliable protocol, messages can be lost when a user loses connectivity: the server still has an open TCP connection to your client, sends the message, and the message vanishes because you are gone. In the good case, the connection is immediately closed by your network provider, causing further messages to be stored on the server. In the bad case however, there is no reply (because your provider employs paranoid admins), and the server takes the usual TCP timeout (several minutes to hours) before taking you offline.
How can XEP-0198 save our lives?
The new proposal can not magically keep the connection while you are offline. However, it introduces two important elements to provide you with the messages you missed when you come back:
stanza acknowledgement allows both the server and the client to request a reply (acknowledgement) on every sent message or a group of messages. Once this reply is received, the messages are considered as delivered.
stream resumption is used when a connection is re-established. By including sequence numbers in the stanza acknowledgements, both client and server can tell each other which messages they received before the interruption, requesting to re-send later messages.
By combining these two enhancements, it is possible to provide a delivery guarantee for every message between you and your server. The same mechanism can also be used on S2S (server to server) links, however these are generally far more reliable.
XEP-0198 also allows to implement throttling of connections on busy servers,
however this does not have such a big effect on the subjective reliability of
Jabber.
Update, 2012-03-31: Protocol Versions
Over the years, the XEP-0198 specification developed, changing the XML stream format on the way. Fortunately, they introduced a protocol version to check for compatibility. Unfortunately, the authors who bothered enough to implement the proposal, only added one single version of the spec, providing no backward compatibility:
| Version | Namespace | Annotations | Implementations |
|---|---|---|---|
| 0.5 (2008-09-29) | urn:xmpp:sm:0 | First version with an official namespace and protocol versioning. | ejabberd |
| 0.6 (2009-03-19) | urn:xmpp:sm:1 | Renamed attributes, added (later deprecated) stanzas attribute. | |
| 0.8 (2009-04-09) | urn:xmpp:sm:2 | Simplified protocol. Added (later out-specced) throttling element <t/>. | Gajim, M-Link, Prosody, Psi, Swift(en)/Stroke |
| 1.2 (2011-03-02) | urn:xmpp:sm:3 | Further simplified protocol. Removed throttling, per-number acks (nobody used these anyway). | |
| 1.3 (2011-06-29) | Clarifications in the spec. |
Where can we get it?
Unfortunately, after XEP-0198 has been proposed to Draft Standard on 2009-06-17, not much has happened. It took some more years for implementations to appear in the wild. The following applications already support the extension, or parts of it (Update: changed from XEP version to application version):
- Gajim 0.15+ (Gnome-oriented XMPP client)
- jabberd2 (deprecated version of the XEP, incompatible to existing clients)
- M-Link ACKs, no stream resumption, as of R15+ (commercial XMPP server by isode)
- Prosody (a lightweight Jabber server written in Lua): 0.8+ with mod_smacks
- Psi (multi-platform XMPP client): forks of Psi and Iris, no official support
- Swift 1.0+ ("your friendly chat client", multi-platform) implements ACKs, but no stream resumption, by means of Swiften, its embedded XMPP library
- Stroke (a Java port of Swiften)
- yaxim 0.8.7+ (yet another Android client, maintained by yours truly)
If your favorite server/client is not in that list, there is something you can do:
- provide patches for your favourite Jabber application.
- kindly request the authors to implement it.
- support existing requests.
Here you can find related requests for different Jabber software:
- SMACK (Updated May 2011, original Forum thread) (a Java client library usable in mobile phones)
- BEEM (Android XMPP client based on SMACK)
- ejabberd (Updated Apr 2014: Up-to-date patchset) (scalable Jabber server written in Erlang)
- ChatSecure (Updated Jul 2012: Security-focused Android client)
- Pidgin (multi-platform multi-protocol IM client)
- xabber (Updated Jul 2012: Android client)
(Thanks to Anonymous commenter for additional bug tracker links)
Notes
There are several related extensions, like XEP-0184: Message Receipts or XEP-0199: XMPP Ping. However, these do not provide the reliability and efficiency of XEP-0198.
If you know of a client or server that supports XEP-0198, please feel free to leave a comment or drop an email to <georg@op-co.de>.
2014-02-13: Tigase XMPP Server 5.2.0 final release
It's on SMACK's queue
ejabberd now has suppport for your extension (with release 14.05).
There is also a bug for Telepathy https://bugs.freedesktop.org/show_bug.cgi?id=46700
Is there any (good) Android client supporting this?
Except the ones that a are mentioned on this page I can recommend Conversations ( see Google Play and Github). It has a pretty different approach, it's more like Google Hangout, but it's worth a try.
If you use ejabberd 14.05 you might want to use a later version. Some XEP-0198 bugs have been fixed after the release. most notable: [1]
We have developed the plugin to ensure that no messages are lost (in the context of Openfire). Using Openfire, in the presence of a weak network, messages/packets are lost. Hence, to ensure deliveries (at-least-once) and no message/packet losses we have developed the plugin. The plugin ensures 'Stanza Acknowledgements' (the ability to know if messages have been received by one's peers) with no losses (at-least-once deliveries).
For more information, please see- https://www.atklique.com/bridge/blog/?q=node/5
For more information (and integration of the plugin with Openfire), please drop an email to support@atklique.com with you requirements.
We have developed the plugin to ensure that no messages are lost (in the context of Openfire). Using Openfire, in the presence of a weak network, messages/packets are lost. Hence, to ensure deliveries (at-least-once) and no message/packet losses we have developed the plugin. The plugin ensures 'Stanza Acknowledgements' (the ability to know if messages have been received by one's peers) with no losses (at-least-once deliveries).
For more information, please see- https://www.atklique.com/bridge/blog/?q=node/5
For more information (and integration of the plugin with Openfire), please drop an email to support@atklique.com with you requirements.
We have developed the plugin to ensure that no messages are lost (in the context of Openfire). Using Openfire, in the presence of a weak network, messages/packets are lost. Hence, to ensure deliveries (at-least-once) and no message/packet losses we have developed the plugin. The plugin ensures 'Stanza Acknowledgements' (the ability to know if messages have been received by one's peers) with no losses (at-least-once deliveries).
For more information, please see- https://www.atklique.com/bridge/blog/?q=node/5
For more information (and integration of the plugin with Openfire), please drop an email to support@atklique.com with you requirements.
Using Openfire, in the presence of a weak network (or when user switches/changes the network), messages/packets are lost.
'Stop Message Loss' plugin may serve your need well. Please see- https://www.atklique.com/bridge/blog/?q=node/5
To download the plugin, click the tab 'Stop Message Loss' (scroll to the bottom).
The plugin ensures that no messages are lost (in the context of Openfire). It implements server acknowledgement for each message received by the server. The plugin ensures deliveries (at-least-once).