XMPP works efficiently over medium and high speed networks. Many military deployments will use network links with poor and variable quality, with high latency being a particular problem. This page looks at M-Link capabilities to optimize operation over these "constrained" links.

Isode's architectural approach to messaging deployments in constrained network situations is to run a server-to-server connection over the unreliable link. As can be seen from the diagram below, adopting this approach can protect local communications between clients from the consequences of link failure.

In addition to this architectural approach, Isode's XMPP products incorporate a number of features which make them suitable for deployment over constrained networks and/or unreliable links (including SatCom, HF and Wideband HF Radio).

Optimized Server to Server Protocol

For constrained network operations, Isode recommends operating a server-to-server connection over the unreliable link, rather than client/server. This allows users either side of the link to continue local operation in the event of a link failure. To ensure optimum use of the constrained link, Isode has implemented an optimized server to server protocol

Standard XMPP uses two TCP connections to support a flow of stanzas in each direction with each connection involving a number of handshakes and data exchanges (up to nine handshakes and the exchange of several kilobytes of data). For constrained (and often unreliable) connections, this overhead is a major problem.

To address this, M-Link can use a protocol that reduces data volumes and removes all handshakes at the XMPP level through:

  1. Use of a single bi-directional stream (XEP-0288: Bidirectional Server-to-Server Connections).
  2. Use of peering controls to configure options at both ends of the connection to avoid the need for re-negotiation after a link failure.
  3. Full pipelining of remaining stanzas so that when a connection is initiated initialising stanzas are followed directly by sent messages with no requirement for any returned data to start sending.

More information on this "zero handshake protocol" can be found in the whitepaper [M-Link Support for XMPP over Constrained Networks].

HF Radio Support using STANAG 5066

STANAG 5066 is the NATO standard for running applications over HF Radio. Isode recommends the use of STANAG 5066 with M-Link rather than TCP/IP for slow radio links (amongst other issues, the TCP windowing mechanism for flow control interacts badly with the very long HF turnaround times). Use of STANAG 5066 will result in performance and reliability increases for HF, VHF and UHF connections.

The Isode whitepaper [Performance Measurements of Applications using IP over HF Radio] is a good starting point for those wishing to understand this area further.

HF Operator Chat Gateway

M-Link can act as a gateway between XMPP and STANAG 5066 HF Operator Chat, as defined in Appendix F of STANAG 5066, to support HF Radio systems without XMPP capability and enable integration with XMPP.

Federated Multi-User Chat

Standard Multi-User Chat (MUC) relies on a stable link between the server that hosts the MUC room and the users who are participants in that room and are either connecting directly to that server or connecting indirectly via another server in federation with the host server. When users or groups of users are participating from a location with a constrained link to the host server, a link failure will disrupt their ability to communicate with participants, via MUC, on both sides of the break.

M-Link supports XEP-0298: Federated MUC for Constrained Environments (as above), federating the provision of MUC, just as the distribution of XMPP servers federates the provision of 1:1 chat. More information on Federated Multi-User Chat can be found on the page that discusses M-Link's multi-user chat capabilities and in the whitepaper [Federated Multi-User Chat: Efficient and Reliable Operation over Slow and Unreliable Networks].

Traffic Management

M-Link enables the modification of the service provided to the end-users by means of traffic management. A range of options are available enabling the administrator to make the trade-off between service and performance.

Filtering Message Types and Message Elements

Removing information of low value to a particular deployment can improve performance for high-value traffic. M-Link allows for filtering and removal of:

  • Message/Stanza Types: Such as the removal of chat state notifications orĀ filtering of IQ (information query) stanzas, which clients use to gather information and negotiation protocol features and extensions.
  • Message Elements (message folding): Such as the removal of extensions or the stripping of presence information.

Presence Folding and Stripping

Presence can be used to convey additional information beyond simple online/offline status, such as "extended away" or information on avatars. M-Link allows for presence folding in the same way that it does for message folding so that unnecessary information can be removed. An alternative approach is to completely strip presence information.

Stream Compression and Roster Versioning

M-Link supports both XEP-0138: Stream Compression and Roster Versioning (part of RFC 6121) so that when a client reconnects, the roster is only downloaded if it has changed.


The Isode Evaluation Guide "XMPP Instant Messaging for Constrained Link Environments" is available for those who wish to gain hands-on experience of M-Link's constrained link capabilities.