Quantcast
Channel: Ignite Realtime : All Content - Openfire Support
Viewing all articles
Browse latest Browse all 4778

Explanation: options to mitigate messages loss because of network problems

$
0
0

Disclaimer: i'm not a developer, but as this question pops quite often and i have to dig for the recent conversation to provide a link or repeat everything again, i thought this could be useful to have such document and bookmark it for future references.

 

Background:

 

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.

 

 

Workaround:

 

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 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 Smack version, 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.


Viewing all articles
Browse latest Browse all 4778

Trending Articles