[Standards] Resource conflict handling

Dave Cridland dave at cridland.net
Fri Jun 10 12:35:37 UTC 2011


On Sat May 28 04:44:06 2011, Glenn Maynard wrote:
> More often it's the *client* that knows that the conflicting client  
> is
> a dead connection.  (If the server knows it's a dead connection,  
> there
> wouldn't be a resource conflict in the first place.)  However,  
> there's
> no way for the client to communicate that to the server, to suggest
> that it terminate the conflicting resource (method #3).

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.

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.

Rejecting the bind with an error - which we originally tried - simply  
failed to be understood by clients.

This left assignment of a new resource as the safest option without  
introducing the probes.

Dave.
-- 
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