On 2011-04-26, at 1:19 PM, Dave Cridland wrote: >> > The solution for this would be to give a unique identifier for the MUC >> > session in the "you have joined" message - possibly in lieu of the status >> > code we use to indicate your session now - and then it would no longer be >> > ambiguous. >> I agree, since the nick is no longer unique we should add something which is. > > That's not the problem. I don't think nick-sharing makes any difference here.
It does and you explain why below. Without nick sharing you avoid the "reconnect race condition" discussed in this thread. But, now you have a different problem where clients disconnected might not able to re-join a muc without using a different nick. If they use a different nick then the same person has multiple presences in the same MUC room. We need a way for clients to reconnect after a TCP session is dropped without delay and using the same nick. > > This problem would exist in TCP, if it weren't for an additional safeguard > there. I like the logic :-) > > The MUC session is essentially defined by three things - the client's full > jid, the MUC jid used (ie, room@service/nick), and the timespan. > > In TCP, a connection is defined by the endpoints and the timespan, too. If > you dropped and reopened a TCP session to the same remote port from the same > source port, then things will get confused too. TCP prevents this from > happening, though, by preventing you from using the same source address to > the same endpoint (and, more generally, at all) within a certain time period. So, TCP avoids reconnect race conditions by enforcing an unique key. > > But in XMPP, we allow the client to reuse a resource - the source port, in > effect - almost instantly, and indeed we rely on it in various cases, > including trying to seamlessly reconnect within XEP-0198 resumption. But this > means that the MUC sessions - from some ponts of view - can overlap in time, > but not in endpoint addresses. > > So we get the following: > > a) Client A is bound as [email protected]/foo is in MUC as room@service/nick > b) Client A drops the TCP session. > c) example.org sends unavailable to MUC. > d) Client A reconnects and rebinds. > e) Client A sends join to MUC. > f) MUC responds to (c) with unavailable. > g) Client A sees failed join. > h) Client A sees positive join. > > So in order to break this effect, we need to do one of three things: > > 1) Implement full XEP-0198 everywhere. This has the effect that a session > wouldn't truly end between TCP sessions, so a reconnect turns into a resume > and the issue doesn't arise. > > 2) Implement resource timers, and/or server-assigned resources. This would > remove any time overlap. It'd be pretty unpalatable, unless full XEP-0198 > becomes prevalent. > > 3) Include another identifier to identify the MUC session. For this to work, > both clients and servers need updating, and it's the most specific solution. > Obviously XEP-0198 on only "your" client and server obviate the need. Both #1 (XEP-0198) and #3 (fixes to XEP-0045) require changes to client and servers. XEP-0198 is harder to implement and requires more resources for both the client and server than a simple fix to XEP-0045. History has shown simple fixes are implemented much quicker than new features are. XEP-0198 does provide a good general solution to a number of nits in the usability of XMPP and should be implemented by all clients and servers. I wouldn't even mind seeing it folded into RFC6120bis. But, it doesn't solve a use case which would make XMPP much more usable in today's computing environment, the ability to move IM sessions between devices and different clients. You almost get there with shared nicks in mucs. Also, I'm not totally convinced xep-0198 will work in the remote user in a MUC room case where as #3 will. ck
