Add support for XEP-0198: Stream Management #166
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.
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.
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.
Prefix all ejabberd_c2s #state fields that are used for stream management with "mgmt_".
@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.