Explanation: options to mitigate messages loss because of network problems

Document created by wroot Champion on Apr 22, 2015Last modified by wroot Champion on Feb 20, 2017
Version 11Show Document
  • View in full screen mode



When a client loses network connection Openfire may not become aware of this, after all TCP was designed to survive physical connection outtakes, and do not store incoming messages in the Offline storage. So messages in this situation are sent into void and are lost.





Set a system setting in Openfire (Server Settings > Client Connections > Disconnect clients after they have been idle for) to 30 seconds or any other reasonably low value to make this issue appear as rarely as possible. This means that Openfire will disconnect clients that have been idle for 30 seconds and are not responding to ping requests. One can set it even lower, but it can have a side effect: clients disconnecting and reconnecting often.


This is only a workaround and there is still a chance to lose a message in this 30 or so seconds gap.



Stream Management:


Stream Management as defined in XEP-0198: Stream Management is meant to solve message loss because of network problems. Both a client and a server has to support this.


Openfire has a partial support of this since 4.0.0 version: [OF-446] Implement XEP-0198: Stream Management - Jive Software Open Source


Both endpoints of a XMPP stream must support Stream Management, so a client has to support this too. Smack library (which Spark and some other clients are based on) has added support for this recently (4.1.0 version): [SMACK-333] Implement XEP-0198: Stream Management - Jive Software Open Source


There is a ticket to add this functionality to Spark: https://issues.igniterealtime.org/browse/SPARK-1785



Message Delivery Receipts:


Another approach would be to implement XEP-0184: Message Delivery Receipts in a client. This way a client would get a notification that a message hasn't been delivered (or vice versa a notification that a message has been delivered). This is strictly a client side feature, server doesn't have to support this.


Smack already supports this (version 3.3.0): [SMACK-331] Add support for XEP-0184: Message Delivery Receipts - Jive Software Open Source


Spark is using the latest stable Smack version of 4.1 branch, but there is no GUI in Spark for this yet: [SPARK-1238] Add support for XEP-0184: Message Delivery Receipts - Jive Software Open Source


Most modern XMPP clients support Message Delivery Receipts. E.g. Gajim client shows a red cross icon beside a message which hasn't been delivered.



Chat Markers:


Similar to delivery receipts is the newer XEP-0333: Chat Markers which implements special markers for messages (e.g. read, displayed, acknowledged). This XEP is still in the proposal state. But some clients and libraries already support it.


Smack added support for it in the 4.2 branch [SMACK-736] Add support for Chat Markers (XEP-0333) - IgniteRealtime JIRA


Android client Conversations is known to support it also. Spark has an open ticket to add such functionality [SPARK-1834] Add support for XEP-0333 Chat Markers - IgniteRealtime JIRA