[ejabberd] xep-0198 resume_timeout
rduke496 at gmail.com
Wed Nov 26 06:44:03 MSK 2014
On Tue, Nov 25, 2014 at 11:04 PM, Holger Weiß <holger at zedat.fu-berlin.de> wrote:
> * Raoul Duke <rduke496 at gmail.com> [2014-11-25 21:26]:
>> When i set resume_timeout to 0 I get the desired behaviour and the
>> same behaviour I used to get on the old version i.e. that users are
>> marked as offline in a timely fashion as soon as mod_ping states that
>> they are offline.
>> However, with this resume_timeout value of 0 I lose the value-added I
>> was getting from xep-0198
>> I want both! Is there any configuration or other way to get the "as
>> soon as mod_ping notices the user is offline then mark them as such"
>> but still be able to leverage session resumption from xep-0198?
> No, you can't have both. XEP-0198 allows client sessions to survive
> short network outages (as they commonly happen on mobile or wireless
> networks) transparently. If the server marked the client as offline
> during that time, this would trigger actions such as the client being
> removed from conference rooms on remote servers, for example.
> I think the assumption is that if the client didn't close the stream
> cleanly, he *will* come back and resume the session more often than not.
> So XEP-0198 is optimized for this case, whereas it doesn't work that
> well when no resumption takes place.
I can follow that logic but I have a specific problem with message
loss I was hoping xep-0198 would solve and I'm now unclear if it will.
I'd appreciate your thoughts / suggestions.
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? Am I on the wrong track somehow in expecting this?
If nothing like this exists - then could I get this behavior somehow?
Perhaps by writing a plugin?
To add some context (which may be lacking) to the above question: I am
working on the understanding that in the scenario outlined: as soon as
A has received acknowledgement from ejabberd that the message reached
ejabberd, then A washes its hands of the situation and the
responsibility for reliably delivering the message (delivering and
waiting for an acknowledgement from B) moves to ejabberd. Is that a
>> Any input/suggestions/gotchas greatly appreciated.
> I was thinking about using XEP-0310 (Presence State Annotations) to mark
> sessions as "paused", but I'm not sure any clients support that (yet).
Sounds interesting. I did look for some client implementations just
now and apart from a ruby library I didn't find much.
More information about the ejabberd