XMPP Ping timeout and Google Talk
evan.s at dreskin.net
Wed May 14 12:55:45 EDT 2008
On May 14, 2008, at 11:59 AM, Ethan Blanton wrote:
> Evan Schoenberg spake unto us the following wisdom:
>> I've received multiple reports of and seen at least once myself
>> instances in which talk.google.com simply doesn't reply to <iq
>> type='get' id='purpled097aa0c'><ping xmlns='urn:xmpp:ping'/></iq>.
>> Typically, it does reply, but with a service-unavailable error...
>> which probably means we should stop sending pings but does at least
>> serve as a notification the connection is still alive. When it's
>> in a
>> mood not to respond, though, libpurple disconnects every 2 minutes
>> with a ping timeout even though the connection is clearly live as
>> evidenced by other traffic.
> The service-unavailable response is a feature of the XMPP ping XEP; if
> the remote server doesn't support the ping extension, you still get
> effective ping responses in the form of the service message.
*nod* This is what I've previously seen on Google Talk's server.
> If Google Talk is really not returning anything, this is an error in
> its XMPP implementation.
It does return something (the service-unavailable error) in most cases
(the vast majority?) in my experience. Perhaps this was a temporary
server glitch... but it's hard to imagine how the rest of the
connection was working and this wasn't. The user's log shows sending
and receiving of messages, presence stanzas, etc. without incident.
>> Could we modify the ping timeout to reset whenever any traffic is
>> received, not just the response to our ping?
> That would not be an effective ping, unfortunately. A ping sent at
> time t serves to establish the viability of the connection at time t.
> If response of any data after time t is allowed, one can be
> effectively probing the viability of the connection at time t - k
> (where, for TCP, k is up to about 2MSL).
Oh! Excellent point - thanks for the diagram, which made it
exceedingly clear why use of 'any network activity' isn't a good
> If Google Talk is broken (I'd like to see some traces which were known
> to not have been munged by a firewall/anti-virus/etc.), we may indeed
> have to disable pings, but I'd prefer not to adulterate them. ;-)
I've asked that user about the firewall situation; nobody (well,
almost nobody) on Mac OS X uses anti-virus software, so that isn't a
More information about the Devel