Re: [hybi] NAT reset recovery? Was: Extensibility mechanisms?

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
> [e-mail] wrote:
> 
> > Hmm... Even if the protocol as a whole is asynchronous (both ends
> > can generate frames at any time), isn't it still possible to exchange
> > requests and responses as well over the same transport connection?
> 
> Another niceness of having request/response KA's on the async connection is
> that it gives us a cheap and simple form of message acknowledgement.
> 
> If we receive a response to a KA, then we know that all messages
> sent prior to the KA request have been delivered to the other endpoint.

Nice, except for the cost when you don't need that acknowledgement...

This is a good reason to have a "ping" request, guaranteed to be fully
end-to-end, in addition to any other KA type.

"ping" is also useful for when you haven't received a KA for a little
while (less than the KA interval, but might still be minutes), and you
want to confirm that the connection is actually still alive right now.

Note that if KAs are handled by WebSocket itself, you only know the
message has been delivered to the endpoint's transport queue.  You
don't know that it will reach the endpoint's *application* unless it's
the application which will produce the response, and often that is
something you would like to know.

For these reasons I suggest that "ping" functionality be defined
separately from keepalive functionality, and its semantics made
explicit.

-- Jamie