Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for XEP-0198: Stream Management #166
This is a complete implementation of XEP-0198 (Stream Management) for c2s connections. It adds four c2s options (all documented in
We've been using this patch in production for a while now, and it seems to work fine for us. I tested it against various clients and corner cases.
I've also tried to keep the patch as non-intrusive as possible. While it has to modify some of the existing code, a quick
If you decide to merge this and any bugs pop up, I'd be happy to look into them.
Implement partial support for XEP-0198: Stream Management. After successful negotiation of this feature, the server requests an ACK for each stanza transmitted to the client and responds to ACK requests issued by the client. On session termination, the server re-routes any unacknowledged stanzas. The length of the pending queue can be limited by setting the "max_ack_queue" option to some integer value (default: 500). XEP-0198 support can be disabled entirely by setting the "stream_management" option to false (default: true). So far, stream management is implemented only for c2s connections, and the optional stream resumption feature also described in XEP-0198 is not (yet) supported. This addition was originally based on a patch provided by Magnus Henoch and updated by Grzegorz Grasza. Their code implements an early draft of XEP-0198 for some previous version of ejabberd. It has since been rewritten almost entirely.
The code that had been commented out at some earlier point in time would now break XEP-0198.
Implement the optional session resumption feature described in XEP-0198. A client that supports this feature may now resume the previous session (within a configurable number of seconds) if the connection was lost. During resumption, ejabberd will retransmit any stanzas that hadn't been acknowledged by the client.
If the new "resend_on_timeout" option is set to false (which it is by default), bounce any unacknowledged stanzas instead of re-routing them.
On connection timeout, drop any messages that were forwarded by some encapsulating protocol, such as XEP-0280 carbon copies or XEP-0313 archive messages. Bouncing or resending them could easily lead to unexpected results.
This would happen, for example, if you tried to resume the stream either before authentication or after resource binding. Of course, I can't really tell without looking at the relevant parts of the stream.
Are you in the process of adding XEP-0198 support to some client yourself? If so, I'm happy to help if I can! But maybe we should discuss this elsewhere unless you suspect an issue with my patch.
A few comments won't hurt anyone, just wanted to make sure we don't start a longish discussion on a client implementation here.
Log an informational message when a session goes into the pending state (waiting for resumption) after the connection was lost. Administrators may well be interested in this state change when looking into issues.
Due to timing issues, ejabberd_c2s might receive stream elements from the client while the session is waiting for stream resumption. Those elements are now accepted.
There are corner cases where certain clients acknowledge more stanzas than they received. Nothing really bad will happen in those cases, and server administrators can't do anything about such issues anyway.
@nectarbits, I would give up the requirement of having the presence status of mobile devices updated instantly, as that's plain impossible with a TCP-based protocol. You could use a very short ping interval of course, but that will drain your users' batteries.
You might want to read a related FAQ entry.