[Standards] Resource conflict handling
dave at cridland.net
Mon Jun 13 08:04:23 UTC 2011
On Fri Jun 10 18:48:01 2011, Glenn Maynard wrote:
> On Fri, Jun 10, 2011 at 8:35 AM, Dave Cridland <dave at cridland.net>
> > What M-Link does is ping the old session on a conflict, with a
> > timeout (of, if I recall, 10 seconds).
> > So on a conflict, you get three cases:
> > 1) The act of sending the ping causes an error, in which case the
> > session is cleaned up and the new bind succeeds.
> > 2) The old client responds, in which case the new bind pauses for
> one RTT,
> > and then generates a new resource. (ie, #3).
> > 3) The old client does not respond, in which case it's terminated
> after the
> > timeout, and the new bind succeeds after the timeout.
> This won't work properly if the existing client is a paused BOSH
> which may not unpause the session to reply for arbitrary lengths of
So it times out. No problem. Still works properly, everything's happy
The trick here is that we assume it's likely that a resource conflict
means the old session is dead, but we'll check to ensure that's the
> The common case is actually #1, however if you simply terminate the
> > session blindly, it's very easy to get into ping-pong loops with
> > client instances both asking for the "Home" or "Gajim" resource.
> That's why clients should explicitly declare that they want the
> disconnection behavior. It's essentially a declaration by the
> client that
> it's designed to avoid this problem, probably by using a resource
> that it
> knows won't conflict.
I'm fair from convinced that that's how it'd be used.
It's not one client involved, but two, and any time the right
behaviour is dependent on more than one entity doing things right,
disaster lurks in the wings.
If one client does it right, and another does it wrong, there's some
nasty failure cases.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards