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

[Pieter Hintjens <[e-mail]>]

On Tue, Apr 20, 2010 at 3:40 AM, Jamie Lokier <[e-mail]> wrote:

> Perhaps the missing thing is that request-response is more complicated
> in this kind of protocol, because you also have to define a way to
> _associated_ each response with the request.  That means sequence
> numbers, or identifiers, or being careful with counting response
> messages distinct from non-response messages.

This is pretty much the problem we solved in AMQP by using async KAs.

> There are also subtleties: If the other end sends a graceful close
> message, and then receives a KA request, does it send a KA response,
> or does the graceful close mean that KA response is among the message
> types that won't be sent?

Indeed... having to respond to a KA request makes a graceful close
much more complex.

> Because it's more complicated, it's not necessarily a great pattern
> compared with async keepalive, which is quite simple, and doesn't even
> need to send a KA message from the server in your example.  (The data
> frame is enough by itself).

Yes.  A no-op frame is sufficient.

> However for packet efficiency, synchronising timing by using
> request-response, or another synchronisation method, may still be
> advantageous.  Even though it's more complicated than async keepalive.

Complexity is always worth removing unless the overhead is significant
and since KAs can be entirely switched off when there is traffic at
all, and then reduced to once per 5 or 10 or 30 seconds, packet
efficiency seems irrelevant here.

-Pieter