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

[Jamie Lokier <[e-mail]>]

[e-mail] wrote:
> Hi Pieter,
> 
> Pieter Hintjens wrote:
> >
> >On Mon, Apr 19, 2010 at 10:17 PM,  <[e-mail]> wrote:
> >
> >> I'd prefer request-response pattern.
> >
> >Which works only if the protocol is fully synchronous.  I 
> >thought WebSockets was async...?
> >
> 
> 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?
> 
> I guess a special situation arises when a client sends out a keepalive request and before responding, the server starts to send a data frame in the other direction (since these two events can happen asynchronously). But then the server just has to put the keepalive response in its sending queue. (In that case such a response would seem a bit redundant, since the client can see that the connection is up when it receives the data frame). I assume it would still possible to match the response to the request. 
> 
> Or am I missing something obvious here? 

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.

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?

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).

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.

-- Jamie