[Standards] presence muc element

Dave Cridland dave at cridland.net
Fri Jun 25 09:02:37 UTC 2010


On Thu Jun 24 21:52:22 2010, Matthew Wild wrote:
> On 24 June 2010 21:33, Justin Karneges
> <justin-keyword-jabber.093179 at affinix.com> wrote:
> > It's a common problem to join a muc that already thinks you are  
> joined, and
> > then the presence you send is interpretted as a mere status  
> change rather
> > than a full join.  Then you don't get the room roster, history,  
> etc.  Kev
> > informs me that the <x xmlns="http://jabber.org/protocol/muc">  
> element
> > (hereby referred to as "the muc element") is supposed to solve  
> this problem.
> > You include it only on join stanzas, but not on status change  
> stanzas.  This
> > way, if a muc sees the element but thought you were already  
> joined, it can do
> > a proper rejoin.
> >
> 
> Yes, Prosody has had this code since the early days, however we
> currently have it commented out due to Google Talk's issues. Gajim
> also included the element on nick changes, but we ensured this was
> fixed, and added a workaround for it.
> 
> But there's little way we can work around Google's oddity (well
> technically there is, but none I'd be happy with releasing).
> 
> 
There is, in fact, a workaround in M-Link, too, in as much as it's  
possible to strip out the XEP-0045 control element on inbound  
presence from a domain before the processing code ever sees it. I'd  
be loathe to put that into production.

But don't be coy about this - this is an interop bug, not a mere  
oddity. While I don't see anything in the spec suggesting that  
directed presence should be repeated, I admit there's nothing in the  
spec about it not being repeated either, so we either have a bug in  
the spec (if Google insist the spec allows them to do this) or a bug  
in GTalk (if they admit they shouldn't). Either way, it needs  
resolution.


> > However, this seems to break with servers that replay directed  
> presence.
> > Allegedly gtalk does this.  Every 5 minutes, the client's server  
> replays the
> > directed presence to the muc, which includes the muc element,  
> causing the
> > user to constantly rejoin the muc (at least, for those mucs that  
> respect the
> > muc element properly).
> >
> > Some solutions:
> >  1) Servers shouldn't replay directed presence.
> 
> I don't see that randomly re-sending join requests shouldn't result  
> in
> multiple joins to a room. Broadcasted presence is a different case,  
> it
> is more of a "state" than an instruction.
> 
> >  2) If presence is replayed, replay only the elements safe to  
> replay.
> >
> 
> That requires the server to know which elements those are - MUC
> obviously isn't, but what's to say more won't come along? (e.g.
> temporary presence subscriptions).
> 
> 
There's actually a (3), which is "If you replay directed presence,  
then add a delay".

We already add a delay element to other cases of repeated presence,  
after all, such as in response to probes.

In this particular case, this'd leave the following cases:

User		Not Joined		Joined
Delay		Join				Ignore
No Delay		Join				Rejoin

Of course, I'm not convinced that this solves nickname changes, which  
is another long-standing Google interop bug.

There's another issue caused by this bug - for every repeated  
presence, that causes a presence element to be resent by the MUC to  
every occupant, unless we also start to filter presence stanzas.

(Stanzas per sec from this is G*(G+N)/300, where G is Google users  
and N is non-Google users, kids. In jdev, as I write, that's G==3 and  
N==25, hence averaging 0.3 stanzas a second - nothing we can't  
handle, but add in another 6 Googlers and it's already reached 1/sec.)

> Agreed, but what's done is done, and without using presence for MUC  
> we
> wouldn't have the unavailable on disconnect.

Right - MUC is a presence-based system, so needs to operate over  
presence.

The only other solution would be to make distinct the history,  
current occupants, and current subject retrieval, which is also an  
option. Ideally, you'd also need to include nick changes here which  
starts to radically impinge on the design.



> > Kev additionally informs me that M-Link's muc service may be the  
> only one that
> > performs rejoins properly when receiving the muc element.
> 
> It wasn't the first, but it likely is the only one at the moment. I
> didn't consider it acceptable to release logic that is broken with  
> one
> of the largest XMPP deployments on the internet, so as I said, we
> removed it from Prosody with a view to re-adding it if/when Google
> finally cleaned up their act.
> 
> 
It's not clear to me why Google does this, I have attempted to  
contact them to resolve the interop issue, and I've yet to have a  
response, but I'd hope that they're keen to sort this out - it's  
entirely possible I'm using the wrong contact details or something,  
so if Google people are reading this, please, I'm keen to get a  
solution.

But aside from being rather spectacularly wasteful of bandwidth, a  
client should be able to tell that at least the history is just that  
- due again to the delay. In addition, it's only the last presence  
that Google replays, as far as I understand things, so clients can  
workaround this bug by sending an "update" presence after joining.  
They can even workaround the nickname changing bug, as Kev pointed  
out to me, by sending unavailable to the old nickname after  
successfully changing nickname. So if client developers find their  
users are suffering, there are workarounds they could deploy, which  
are much easier to do there.

The alternative is that either servers ignore Google, have special  
workaround for Google, or else avoid improvements across the board  
due to Google.

Personally, I'm willing to dig my heels in a bit on this. I can't  
think of any cases where repeating directed presence is a good idea,  
and in the absence of the specification mentioning this, I don't  
believe that implementations should be doing so. Unless I see a  
reason to change my mind, and/or unless customers start to complain,  
I see no reason to change our behaviour.


> > If indeed few mucs
> > are supporting this, then maybe we have an opportunity to amend  
> this problem
> > in XEP-0045.  That is, change the XEP to make it clear that the  
> muc element
> > does not cause rejoins, and possibly look for a different rejoin  
> solution
> > that does not break the presence model.
> >
> 
> That would be fine, we can update our code easily, and would be glad
> to see it back in action. However the issue can be solved more
> generally by implementing XEP-0198 for s2s, and logic to make
> unavailable any remote users when it's detected that their server  
> has
> crashed. This is my current goal.

Yes, also if we ensure servers respond correctly to probes when  
directed presence is involved we can probe in various cases - that  
said, I know M-Link doesn't respond correctly in this case, although  
we're working on that. (I'm curious as to whether other servers do,  
as well - this is a bis thing we've not caught up with yet, AFAIK).

As an aside, here, it may be required that clients send unavailable  
to their old nickname after a nick change, as suggested above as a  
workaround to Google, since the server has to track the directed  
presence in order to send unavailable and respond to pings - if the  
client never sends the unavailable to match the directed presence,  
then various state mismatches could occur.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list