On Tue, Apr 26, 2011 at 4:00 PM, Waqas Hussain <[email protected]> wrote: > On Tue, Apr 26, 2011 at 1:50 AM, Peter Saint-Andre <[email protected]> wrote: >> Perhaps of interest here. I'm not yet convinced that this is a bug in >> the spec... >> >> -------- Original Message -------- >> Subject: Re: [ejabberd] another mod_muc question: duplicate nicks from >> same user >> Date: Mon, 25 Apr 2011 16:46:07 -0400 >> From: Armando Di Cianno <[email protected]> >> Reply-To: [email protected] >> To: [email protected] >> >> On Mon, Apr 25, 2011 at 2:34 PM, Daniel Dormont >> <[email protected]> wrote: >>> My question is: does Ejabberd permit this? If so, does it have to be >>> enabled in the config somewhere? I have done some brief experiments >>> and it doesn't seem to work: instead the new joinee receives <error >>> code='409' type='cancel'><conflict >>> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/><text >>> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>That nickname is already >>> in use by another occupant</text></error> >> >> If it permits it by config, I do not know. However, I wanted to chime in. >> >> You've touched upon a /really/ interesting misfeature in the MUC XEP, >> imho. I recently had to battle solving a client's requirement to >> correctly handle quick disconnects and reconnects. If the server >> notices the client disconnect, it'll disconnect the "old" client >> session (normally, or via mod_ping), however, the user may have >> already reconnected. A misinformed client program will happily get the >> "unavailable" stanza from the server, and think that it's its own, as >> the client is processing the message as if it received it with the >> bare jid, not including the resource. >> >> From my tests, ejabberd on the server side, and libpurple/pidgin and >> adium are okay. I'd bet a few dollars that every other client or >> library in the world is doing it wrong. >> >> So, just that caveat: beware of relying on any behavior in this realm >> all too much ... at least not without a lot of further testing. >> >> __armando >> _______________________________________________ >> ejabberd mailing list >> [email protected] >> http://lists.jabber.ru/mailman/listinfo/ejabberd >> >> > > I'm not clear on what's being said here. I'm guessing the assumption > is the unavailable presence of one session in a nick goes to all > sessions for the nick? If so, that's not true in e.g., Prosody's > implementation. A session only gets its own unavailable presence, not > another session's. Doing it otherwise would break completely.
I think what this is saying is that there's a race condition if you connect to login server A, and join a MUC on B, then you can disconnect from A. B sends message to A. A responds with error. Client reconnects to A. Client sends rejoin to B. B receives error and kicks occupant from room. B receives new join request. Client receives exit presence for old session and believes the join to have failed. /K
