[Standards] presence muc element
mwild1 at gmail.com
Sat Jun 26 01:14:04 UTC 2010
On 26 June 2010 01:04, Bruce Campbell <b+jabber at bruce-2010.zerlargal.org> wrote:
> On Fri, 25 Jun 2010, Matthew Wild wrote:
>> On 25 June 2010 10:02, Dave Cridland <dave at cridland.net> wrote:
>>> There is, in fact, a workaround in M-Link, too, in as much as it's
>>> to strip out the XEP-0045 control element on inbound presence from a
>>> before the processing code ever sees it. I'd be loathe to put that into
>> 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.
> You'd be better off detecting this based on behaviour, rather than
> particular strings appearing in the SRV records, as Google's implementation
> is probably not the only one doing this. Eg, if user(s) from domain foo
> consistently send a directed presence every X minutes over ~30 minutes,
> assume that the server hosting the domain is broken in this regard and
> trigger the workaround mentioned.
That's actually a lot worse. For a start, it would depend on users
experiencing the broken behaviour, before it would activate the
workaround. Secondly we have no way to detect that it is a server
repeating directed presence, and not a client from that domain
intentionally sending it (a rogue user could then use this to disable
our rejoin logic for non-Google domains at will).
Apart from these issues, it would require us to keep a list in memory
or on disk of which domains have been known to experience the bug,
since s2s connections can close and re-establish at any time (and we
wouldn't want to go through 30 minutes of brokenness each time that
And finally - yes, I'm quite sure Google's is the only server to do
this. It is also definitely their server, and not their client(s).
Since the only domains with this bug are delegated to
xmpp-server*.?.google.com, we're not just looking for particular
strings, we're looking at the actual addresses.
Implementing this solution would be really quite easy, just very "not
nice" - if not because of the method then because of the way it cuts
across internal layers it shouldn't.
More information about the Standards