I remember thinking about something along the lines of #3 when I was doing muc modifications to Buddycloud (when it was using muc). I had planned to have the muc nickname actually include a uuid or similar, that just never got displayed in the client (custom client).
This was to handle rapid connection drops and reconnects on mobile networks. The uuid appended to the nickname would be pseudo random and include some timestamp part incase I needed to find an order to the connections. Just incase thats helpful to anyone :) Cheers Kirk Bateman On 26 Apr 2011, at 21:24, Peter Saint-Andre <[email protected]> wrote: > 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/ > > >
