XMPP Ping timeout and Google Talk
elb at pidgin.im
Wed May 14 11:59:48 EDT 2008
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.
From the XEP:
4.1 Server-To-Client Pings
One popular usage is for a server to test the viability of the
underlying stream connection by pinging a connected client. This
is done by sending an <iq/> get over the stream from the server to
If the client supports the ping namespace, it MUST return an
IQ-result, which functions as a "pong":
If the client does not support the ping namespace, it MUST return
a <service-unavailable/> error:
The other error conditions defined in RFC 3920 could also be
returned if appropriate.
If Google Talk is really not returning anything, this is an error in
its XMPP implementation.
> http://trac.adiumx.com/ticket/9569#comment:18 is a recent ticket in
> Adium trac submitted on the issue. I couldn't find a Pidgin trac
> ticket on it.
I don't believe we've ever heard it. This seems suspicious to me.
> 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). Consider (time is the
| * Normal Data Send
ping * / | 
|\ / |
 | \ / * Disconnect (server failure, etc.)
| X :
| / \ :
|/ \ :
Alive! * \ : 
| * Lost
From  forward, we have disagreement on the status of the
connection. With a proper PING/PONG pair, the client would consider
the connection suspicious from the emission of the ping at , and a
disconnect timer would proceed from that point. With a PING which
accepted any data as successful verification, the disconnect timer
would not restart until some time after .
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. ;-)
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Devel