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

[Jamie Lokier <[e-mail]>]

[e-mail] wrote:
> 
> Pieter Hintjens wrote:
> >
> >On Mon, Apr 19, 2010 at 9:53 PM,  <[e-mail]> wrote:
> >
> >> I think the websocket spec should define two special frames 
> >explicitly 
> >> for keepalive purpose...
> >
> >For what it's worth, the keep alive design from AMQP used only 
> >one frame.  Senders are responsible for issuing KAs at regular 
> >intervals.
> >Receivers treat these as no-ops except to register "activity" 
> >on the connection.  Any other frame also acts as activity, 
> >obviously.  If no activity is received within X seconds, the 
> >connection can be killed.
> >There is no notion of request-response for KA in AMQP.
> >
> 
> This is another possibility, and it's even simpler. But how fast
> would the sender be able to detect that the keepalive did not go
> through and there's something wrong with the connection? Only after
> TCP has given up? Also an explicit response would tell something
> more about the liveliness of the server than a mere TCP ack.

An endpoint knows that the connection is down because it hasn't
*received* a keepalive after too long.

The speed of discovery depends on an agreed timing with the other end.

Which is actually the same as request-response:

> I'd prefer request-response pattern. 

You obviously don't want both ends sending requests, so at least one
of them has to passively timeout waiting to receive a keepalive, and
then decide the connection is down.

AMQP just does that at both ends, instead of one.

Request-response from one end only does not remove the need for a
passive timeout agreed between the endpoints.  (It can be negotiated,
or pre-agreed).

-- Jamie