[Standards] XEP-0198 minor enhancement

Dave Cridland dave at cridland.net
Wed Jun 3 08:47:17 UTC 2015


On 3 June 2015 at 00:48, John Williams (johnwi3) <johnwi3 at cisco.com> wrote:

> Thanks for the clarification.
> Hum,.. not sure how useful this is, since a lot of stanzas are of little
> long term interest (eg: chatstates), but as you describe it seems pretty
> harmless.
>
>
So as things stand, if a TCP virtual circuit is lost (due to, for example,
wandering out of signal), then the choices are:

a) Drop the session (the only option without XEP-0198).
b) Keep the session live (with XEP-0198).

If a server keeps the session live, it's got to keep the state (things like
current presence broadcast, directed presence, and so on). In addition,
other users will see the session as live, and while PSA might help indicate
this by annotating the presence, it's still a bit weird. Fine for handover
periods, but not so good across a half-hour underground train journey. It's
worse if the client never resumes, of course.

So servers in effect have to timeout such zombie sessions, and it needs to
happen within a few minutes before the UX issues pile up.

Whether a session is dropped immediately or later, a server can essentially
redeliver the outstanding stanzas; risking duplication.

On the other hand, when the session is dropped, stanzas that are "in
flight" from the client are lost. Many of these may well be unimportant in
a non-resumption case, but it's useful for a client to know if that message
saying "I'm just jumping on the train, be there in 30" actually got as far
as the server.

What this minor addition does is allow the server to tell a client, "That
message got through, but I don't have the rest of your session state -
you'll have to start a new one". In principle it could also figure out
which of the pending offline messages the client already has and discard
them, too. The cost for this is storing one server-chosen string, plus one
or two integers - that volume of data can be persisted fairly cheaply, and
possibly even offline.

Think of it as a failure with benefits.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150603/61a87304/attachment.html>


More information about the Standards mailing list