On 4/26/11 2:19 PM, Dave Cridland wrote: > The single sentance discussing > nick-sharing is, I think, being pulled from XEP-0045 because it doesn't > really describe what needs to happen.
Correct. Speaking of which, I need to finish entering my edits... > I hereby commit to working with Matt and/or Waqas on a proper > nick-sharing XEP, sometime after the beginning of June. Super. >> > >> > I think that only Prosody and (unreleased) versions of M-Link do >> this, but the same issue would apply in any case - follow the sequence >> that Kev gave (or various similar cases), and you end up with a client >> reconnecting quickly enough to receive the unavailable presence >> signifiying that it's left the room. >> > >> > 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. > > This problem would exist in TCP, if it weren't for an additional > safeguard there. > > 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. > > 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. Thanks for the analysis. I like #1. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
