[ejabberd] xep-0198 resume_timeout

Holger Weiß holger at zedat.fu-berlin.de
Wed Nov 26 11:27:17 MSK 2014

* Raoul Duke <rduke496 at gmail.com> [2014-11-26 03:44]:
> The scenario is (without xep-0198):
> * A sends message to B
> * however, B isn't really online.  B went offline 3 seconds ago but
> mod_ping hasn't noticed that yet (and so doesn't know it needs to put
> the message in B's offline store)
> * B is on a mobile network which just blindly accepts the message from ejabberd
> * ejabberd thinks the message was delivered
> * the message is lost
> I had thought xep-0198 might solve that case in that since B did not
> acknowledge the message (stanza acknowledgement), this would be
> identified and the message would be delivered eventually somehow.
> So my current understanding is that xep-0198 would solve the outlined
> message loss problem if B resumed the stream within the resumption
> timeout.  Does that seem like a true statement?


> However, what happens if B does not sign-on again for 2 hours (or 2
> days even).  Is the message lost?
> I guess the behaviour I would want/expect is that at the point that
> the resume timeout expires, then if there are still messages which are
> known to be undelivered they are copied to B's offline store (or some
> other mechanism to ensure the message is not lost).  Does anything
> like this happen?

This depends on the setting of the ejabberd_c2s listener variable
"resend_on_timeout".¹  The default is "false", which means ejabberd will
bounce an error back to the sender for each of those messages (which is
already a big improvement over the scenario without XEP-0198).

If you set it to "true", the messages are resent.  So, if no other
client of the recipient is online and mod_offline is enabled, they will
end up in offline storage, as you expected.  But if another client is
online, that client will receive those messages.  The problem is that
the same client might've *already* received copies of those messages
some minutes earlier (if they were sent to the bare JID and he had the
same priority as the now-offline client, or if carbon copies were
enabled).  That's definitely not what users would expect, so I'd only
recommend this setting to admins who *know* their server is not going to
be used that way.

The next ejabberd release will also support setting "resend_on_timeout"
to "if_offline", which means those messages are going to be resent (to
offline storage) only if no other client is online when the timeout
occurs; otherwise, error messages are bounced.  This does the right
thing most of the time, but not in all situations.


¹ http://www.process-one.net/docs/ejabberd/guide_en.html#listened-options

More information about the ejabberd mailing list