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

[Gabriel Montenegro <[e-mail]>]

This usage is supported in revision 07, which only has text on the responder (the "Pingee"?) allowing it to respond only to the latest Ping, but it has no constrain on the initiator (the "Pinger"), which is currently free to send more than one (which you indicate might actually make sense in your case). 

I'm curious, if a Pong has not been received in such long time, why is the course of action to Ping again versus declaring that node gone or down and unavailable? I thought your goal was to detect dead nodes. Wouldn't this constitute a dead node?

> -----Original Message-----
> From: Jamie Lokier [mailto:[e-mail]]
> Sent: Thursday, May 19, 2011 16:28
> To: Greg Wilkins
> Cc: Piotr Kulaga; [e-mail]; Gabriel Montenegro
> Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-
> hybi-thewebsocketprotocol-07)
> 
> 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