On 26 June 2010 01:04, Bruce Campbell <b+jab...@bruce-2010.zerlargal.org> wrote: > > On Fri, 25 Jun 2010, Matthew Wild wrote: > >> On 25 June 2010 10:02, Dave Cridland <d...@cridland.net> wrote: >>>
>>> 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. > > 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 happened). 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. Regards, Matthew
