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

[Jamie Lokier <[e-mail]>]

Gabriel Montenegro wrote:
> 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).

That's a good reason for a ping/pong body.

If the responder only has to respond to the last ping, the sender may
need to know which ping is being responded to make assertions about
when the responder was alive and estimate or bound the RTT.

> 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?

See Pieter Hintjens reply, and my reply to that.  If there is bulky
data being transmitted, it can delay a pong, potentially for a long
time (depending on how your queues work), but it doesn't mean the
connection is dead.  Quite the contrary.

I don't mean to advocate that ping/pong is always appropriate anyway.

(As Pieter points out, watching the data is better.  Another reason:
Asymmetric timeouts.  If you need keepalive just to stay "subscribed"
to a message source, then the keepalive bandwidth can greatly exceed
actual data!!  Dropping pongs, and using _different_ timings for
server and client can reduce keepalive bandwidth while maintaining a
required level of "subscriber up-to-dateness".)

But if you feel the need to use ping/pong (perhaps to feel like you're
making more use of the WS spec, and less wheel invention), when you
have short keepalive timing constraints, that would push towards
overlap sometimes.

-- Jamie