XMPP Ping timeout and Google Talk

[Ethan Blanton]

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
    the client.

    [snip example]

    If the client supports the ping namespace, it MUST return an
    IQ-result, which functions as a "pong":

    [snip example]

    If the client does not support the ping namespace, it MUST return
    a <service-unavailable/> error:

    [snip example]

    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
vertical axis):

Client             Server
       |       * Normal Data Send
       |      /|
 ping  *     / | [1]
       |\   /  |
 [2]   | \ /   * Disconnect (server failure, etc.)
       |  X    :
       | / \   :
       |/   \  :
Alive! *     \ : [3]
       |      \:
       |       * Lost
       :       :


From [2] 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 [1], 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 [3].

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.  ;-)

Ethan

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080514/d1c5de4b/attachment.sig>