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

[Jamie Lokier <[e-mail]>]

Pieter Hintjens wrote:
> On Fri, May 20, 2011 at 1:28 AM, Jamie Lokier <[e-mail]> wrote:
> 
> > 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.
> 
> We had exactly this problem in AMQP and resolved it quite effectively
> by treating _any_ incoming data as a liveness indicator. Any reason
> you'd not do this?

(I was going to agree, but then I remembered complicated things from
coherent systems that had hoped to avoid here.  So yes and no!)

That's better, but it addresses a different issue than this thread.

That's a good way to keep a TCP connection alive.  Optimal seems to be
to decouple directions, and (for each direction) a one-way keepalive
when there hasn't been any transmission for a fixed time; all received
data indicates liveness.

But keeping a connection alive isn't quite the same as reliably
detecting a dead one!  (To reconnect, break a transaction, etc.)

With the example timings I gave, the client has to send keepalives
every 20 seconds _even if_ it treats any data from the server as
indicating liveness, otherwise the server will flag the client as
"offline" spuriously.

For "quiet" connections, explicit ping/pong work, but the the client
must send pings 20 seconds apart from _each other_, not wait 20
seconds after receiving a pong (an easy coding error).

If we discard the whole concept of ping/pong, I think you and I are
in sharp agreement.

But this sub-thread is about whether it's ever useful to overlap
ping/pong.  My reply is:

   If you insist on using ping/pong, perhaps feeling the need to use
   the features of WebSocket draft -07 instead of inventing your own,
   then yes sometimes they need to overlap.  But it's even better to
   abandon ping/pong and use a more robust keepalive method.

In a way, you have highlighted a problem with the explicit ping/pong
strategy implicitly advocated in draft -07.

Unfortunately, treating all data as liveness has a different set of
problems (good for keeping a connection alive, but unreliable at
detecting connection loss in a bounded time), which is often
ignorable, but breaks things that depend on "confirm the client was
definitely alive in the last 30 seconds".  Think about variable
network delays.  The only robust solution I've come up with combines
all-data-liveness and round-tripped sequence stamps.  Hence yes and no
to your question.

-- Jamie