Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
> On 19 May 2011 10:43, Piotr Kulaga <[e-mail]> wrote:
> > Personally I do not see any point of allowing multiple outstanding pings. If
> > a sender did not get a response to first of them, sending another one
> > probably will not increase its chances. To me, saying that only one ping is
> > allowed is a simplification of the protocol which does not limit protocol’s
> > functionality.
> 
> 
> I agree that multiple outstanding pings do not initially appear useful.
> 
> But then I don't see why we need to restrict it to only 1.    Either
> it will not have a use and thus nobody will send multiple pings,  or
> somebody will discover a use and we should let them.

Naturally I have a use, and it came up in my very first application
for WebSocket.  What follows is an example.

A server needs to know which clients are currently "online" for the
purpose of reporting this to other clients, detecting dead clients etc.

"Online" is defined (in this example) as "received something in the
last 30 seconds".  This ensures it's fairly up to date, which is
important in a number of applications.

No guarantees can be made about the network, but we choose to treat a
delay of up to 10 seconds in the client-to-server direction as acceptable.
(This is based on 3G experiences, which commonly delay for that long.)

Therefore the client sends 1 ping message every *20* seconds, if there
is no other client-to-server data.

The client must send another ping after 20 seconds even if it hasn't
had a pong for the previous ping yet.

Pongs can be delayed quite a lot due to queueing behind other
messages already queued from server-to-client, plus network delays.

If the client had to wait for pong before sending another ping, that
would cause spurious "offline" statuses whenever there was a lot of
data transiting in server-to-client direction.  Or we'd have to use a
custom keepalive protocol to avoid the restriction.  Or we couldn't
provide such an up to date measure.

(In reality we'll probably use a custom keepalive protocol anyway, to
reduce the amount of packets needed, but that's a separate issue.)

-- Jamie