[ejabberd] xep-0198 resume_timeout
rduke496 at gmail.com
Thu Nov 27 18:04:14 MSK 2014
On Wed, Nov 26, 2014 at 8:27 AM, Holger Weiß <holger at zedat.fu-berlin.de> wrote:
> * 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.
Thanks so much. That was a big help.
More information about the ejabberd