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:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
