On Tue Apr 26 20:14:11 2011, Curtis King wrote:
On 2011-04-26, at 9:28 AM, Dave Cridland wrote:
> On Tue Apr 26 17:22:37 2011, Curtis King wrote:
>> On 2011-04-26, at 8:00 AM, Waqas Hussain wrote:
>> > A session only gets its own unavailable presence, not
>> > another session's. Doing it otherwise would break completely.
>> So what happens when there are two live and valid sessions?
Sounds like one won't see the other leave the room.
>
> Waqas is talking about nick-sharing cases, though.
I know what Waqas and Kev were talking about, it was very easy
follow. What I was talking about and which Kim answered was the
success case, where two clients are sharing the same nick and one
sends an "unavailable". I think the xep could be clearer on sending
presence update in nick sharing case instead of making it
implementation defined. The xep should say, send presence only to
the full jid joining or leaving the room if there are duplicate
nicks for that same bare jid. It should look like just one session
for that nick to all other participants in the room even if there
more than one session.
Right - the Prosody guys did a reasonable amount of work ahead of any
specification on this, and I've shamelessly asked Matt for various
choices they made in order to copy them. The single sentance
discussing nick-sharing is, I think, being pulled from XEP-0045
because it doesn't really describe what needs to happen.
I hereby commit to working with Matt and/or Waqas on a proper
nick-sharing XEP, sometime after the beginning of June.
>
> 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.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
