[Standards] Resource conflict handling

Glenn Maynard glenn at zewt.org
Sat May 28 03:44:06 UTC 2011


RFC6120 7.7.2.2 discourages disconnecting other clients on a resource
conflict, instead encouraging servers to assign a different resource.
This can be inconvenient.

> 3.  Terminate the session of the currently connected client and allow the resource binding attempt of the newly connecting client.
>  ... that this behavior can be appropriate in some deployment scenarios or if the server knows that the currently connected client has a dead connection or broken stream as described under Section 4.6.

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

For example, the client may use an unambiguous resource, such as a
hash of a serial number, used only by that client and that device.  If
there's a conflict, the client knows that the conflict is stale and
should be disconnected (eg. the device was restarted), but the server
doesn't know that.  It's helpful to disconnect the conflicting client
immediately, rather than waiting for the server to detect it, which
may require a timeout--and if it's a paused BOSH connection, the
timeout period may be long.

I may use a small extension to hint the server; maybe there's a better way:

<iq id='id' type='set'>
    <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
         <jid>glenn at zewt.org/b0ae974a-6307-4acb-9933-63ff091a828e</jid>
         <resolution method="disconnect"
xmlns="http://zewt.org/xmpp/bind-conflict-resolution"/>
    </bind>
</iq>

-- 
Glenn Maynard



More information about the Standards mailing list