[jdev] Server responses to resource conflicts

[Guus der Kinderen]

Hello,

On a side note: Openfire does indeed allow you to configure the server in
such a way that it will not accept an already-bound resource (#3, in various
flavours). This is not the default setting though. By default, it uses
option #2 from Wills list (kick the previous connection). You can find the
configuration page in Openfires Admin panel, under "Server" > "Server
Settings" > "Resource Policy"

Openfire doesn't currently allow you to do #1. I've created a new feature
issue for this in our bugtracker:
http://issues.igniterealtime.org/browse/OF-402

Regards,

  Guus

On 17 September 2010 19:52, Peter Saint-Andre <stpeter at stpeter.im> wrote:

> Will, you make some good points. I will add some stronger wording to
> rfc3920bis on this point after IETF Last Call.
>
> On 9/16/10 2:38 AM, Will Thompson wrote:
> > Hi,
> >
> > <http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-14#section-7.6.2.2>
> > specifies three legal server responses to a client trying to connect
> > with an already-connected resource:
> >
> > 1. Assign the new client a fresh resource;
> > 2. Boot the old connection, granting the resource to the new client;
> > 3. Refuse the new connection.
> >
> > It recommends 1, which is what (e.g.) Google Talk implements (well, they
> > always randomize, but it's equivalent in this case ;-)). I was under the
> > impression that no-one did 3, but I discovered that Openfire apparently
> > does. <https://bugzilla.gnome.org/show_bug.cgi?id=629768>
> >
> > I don't really think behaviour 3 is very useful. Maybe this is a
> > function of being interested in mobile stuff, but I believe that the
> > most common reason for trying to connect with an already-connected
> > resource is recovering from a loss of connectivity. As the above-linked
> > bug shows, behaviour 3 means you can't reconnect until the original
> > connection times out.
> >
> > So, I think the third behaviour should be strongly discouraged, with
> > this rationale. (I suspect making it illegal is not going to fly now.) I
> > guess the client can work around this behaviour by retrying with a
> > different resource, but this doesn't have the nice property of cleaning
> > up dead connections.
> >
> > (Obviously the One True Way to recover from a loss in connectivity is
> > XEP-0198, but deployed servers don't all implement this.)
> >
> > Regards,
> _______________________________________________
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20100920/616530ec/attachment-0001.htm>