[Standards] Resource conflict handling
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
> a dead connection. (If the server knows it's a dead connection,
> wouldn't be a resource conflict in the first place.) However,
> 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"
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 Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards