On Fri Jun 10 18:48:01 2011, Glenn Maynard wrote:
On Fri, Jun 10, 2011 at 8:35 AM, Dave Cridland <[email protected]>
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
case.
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.
--
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
