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

[Vladimir Katardjiev <[e-mail]>]

On 19 apr 2010, at 23.05, Pieter Hintjens wrote:

> On Mon, Apr 19, 2010 at 10:54 PM,  <[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?
> 
> Here is the logic we used when designing AMQP's KA mechanism.
> 
> Let's say we use a req-resp model over a symmetric async connection...
> 
> * if the other party is sending us stuff, KA responses are redundant
> * If we're sending stuff, KA requests are redundant
> * Since we're symmetric, both peers would send requests when idle
> * Thus a response is always redundant
> 
> And it boils down to sending NOOPs when otherwise idle, to ensure the
> other party knows we're still alive (as a process).
> 
> Incidentally this simplified async KA is also much easier to
> implement, requiring no state at the recipient.

Don't both sender and receiver need state? Each node needs to know:

- When it last sent an outgoing message (so it can send a noop when it's time)
- When it last received an incoming message (so it knows when to treat the connection as "dead")

Having said that, from a mobile perspective this is disastrous. In the worst-case scenario, if your keepalive interval is 5 minutes, you could end up sending a keepalive message every 2.5 minutes. This would wake up the radio twice as often, and, consequently, halve battery life. In a scenario where the server's keepalive is triggered by the client's, the message from the server would likely arrive within the timeframe that the radio is "awake" anyway (3-5 seconds on smartphones) and thus avoid waking it up again. 

The usage of keepalive as an ack was an interesting proposal, although I'm not sure if the websocket level can properly define an ack... It would only mean the message had been received, not necessarily processed, so I'm not sure what the benefit is. From a data integrity perspective, the interesting ack is "processing complete", not "delivery performed". The latter we have on some level via TCP already.

Vladimir