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 <[email protected]> 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: [email protected] > _______________________________________________ >
_______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
