XEP-0198: Stream Management

XEP-0198:
Stream Management
MongooseIM is an Erlang-based
implementation of an XMPP server with
focus on performance and scalability.
MongooseIM offers a base platform for
building messaging systems. Specifically
designed for enterprise purposes, it is
fault-tolerant and can utilize resources of
multi-core CPUs. It provides support for
WebSockets, reliable message delivery in
mobile networks and multi-user chats. Its
modular architecture allows customizing
it to cater to specific needs like in-house
authentication or application-specific traffic
such as VoIP signalling.
Customized plugins can be easily built on
top of MongooseIM. The extension XEP0198 is designed to prevent message
loss. It guarantees that messages are
passed to offline storage in case of
discovering a faulty connection. It also
describes a fast reconnection mechanism,
which makes other parties on the
network not even notice the temporary
disconnection of a user.
It can be used on server-to-server
connection too, though it’s rare because
those connections are much more reliable.
RE-ESTABLISHING LOST CONNECTION WITH XEP-0198:
MongooseIM
Client
Send 1,2,3,4,5
This diagram shows that the server
acknowledges messages received before
the connection was lost, and the client
resends the remaining messages after
the connection is restored.
BUFFER 1,2,3,4,5
CONNECTION INTERRUPTED
[Interrupted] Send 6
BUFFER 1,2,3,4,5,6
BUFFER 5,6
XEP-0198: Stream management
in action
Resume session, handled = 4
Resend 5,6
Resumed
MongooseIM
Client
THE COMMUNICATION STEPS OF XEP-0198
XEP-0198 introduces two elements:
stanza acknowledgment and stream
resumption 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 between the client
and server 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.
The mechanism is that both the client and
server keep the sequence number in the
stanza acknowledgment of incoming and
outgoing messages.
• When a server wants to know whether
the server has received messages, it
requests acknowledgement from the
client.
ABOUT ERLANG
SOLUTIONS
• The client then sends a sequence
number with the acknowledgement.
• Founded in 1999 soon after Erlang
was released as open source
• All the sequence number stanzas which
aren’t acknowledged yet by the client
must be buffered on the server side.
• Only company of its kind totally
focused on Erlang and Erlang
community
• When the server receives an
acknowledgment, it takes the
number of HANDLED stanzas from
that acknowledgment and drops all
messages up to HANDLED from the
outgoing message buffer.
• With over 300 clients
• The same interaction works the other
way that is the client may request
acknowledgement from the server
and should remember which of its
sent stanzas the server did not
acknowledge yet.
www.erlang-solutions.com
• Headquartered in London, U.K.
• Offices in Aarhus, Amsterdam,
Budapest, Copenhagen, Krakow,
Seattle, Stockholm and Zurich

Download Report