[Standards] Resource conflict handling

Dave Cridland 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>  
> wrote:
> > What M-Link does is ping the old session on a conflict, with a  
> short
> > 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  
> old
> > 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  
> session,
> which may not unpause the session to reply for arbitrary lengths of  
> time.
So it times out. No problem. Still works properly, everything's happy  
and jolly.

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  
> old
> > session blindly, it's very easy to get into ping-pong loops with  
> multiple
> > 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
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list