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

[<[e-mail]>]

Hi,

Martin Thomson wrote:
>
>Furthermore, you don't need a response, TCP provides ACKs.  A 
>one-way exchange of as little as a single byte should be 
>enough to keep any bindings alive in (TCP) intermediaries.
>

This is true. 

I would say there are two options to do keepalives:
i) Define a keepalive frame that the client sends. There is no websocket level response but the TCP ACK is still enough to keep NATs, firewalls etc. open. 
Ii) Define a keepalive request frame that the client sends and keepalive response that the server uses to respond to it. The response is not really necessary for NATs etc., but might help the client to notice a broken connection faster. (I'm not sure if this is true but I remember this was an argument in another protocol, SIP, why keepalive over TCP was done in that way.) The response may make the protocol more complicated, though, as people have commented.

I would not want to make the keepalives peer-to-peer in a sense that also the server could send keepalives. I think the client should be in charge. The reason is that as a client developer for a mobile device I would like to be able to send keepalives as infrequently as possible. We have had some bad experiences with IMAP servers sending stuff frequently back to the client (presumably because not all clients are clever enough to do any keepalives themselves - this is a risk of course if we don't specify this at all in websocket spec), and the client has no way to affect their rate, which has been fixed.

If there really is a requirement for the server to see keepalives at a certain minimum rate (for instance so that it can abandon stale connections), I would then have that negotiated so that the server can tell that back to the client who would still do the sending. But I'm not sure if that's needed.

Markus