On 25 June 2010 10:02, Dave Cridland <[email protected]> wrote: > On Thu Jun 24 21:52:22 2010, Matthew Wild wrote: >> >> On 24 June 2010 21:33, Justin Karneges >> <[email protected]> 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. >
That's not actually possible on its own, unless you know which domains are Google and which aren't. Our "workaround" was to detect this based on the SRV records for the domain - then we set a flag for that stream to say that it repeats presence, and our MUC component disables the rejoin logic for stanzas received over that stream. That is some workaround, though I don't see why it wouldn't work. > 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. > Yes, agreed. > There's actually a (3), which is "If you replay directed presence, then add > a delay". > This sounds like a good solution, if they really want to carry on doing this (does anyone know why they do?). > (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.) > You're good! ;) >> 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). > No, I don't think we have that either yet - likely for the next release though. I have a better idea though... http://matthewwild.co.uk/uploads/gc_pinger.html :) > 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. > Yes, good point - this would need clarification in XEP-0045 I think. Matthew
