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

["Thomson, Martin" <[e-mail]>]

Responses are of some use at the application layer, so the second option might make some sense.

However, negotiation seems like overkill for this sort of mechanism.  Each peer has some expectations and constraints that it knows best.  Let them each take whatever action they need to ensure that the connection stays alive.

If a keep-alive frame is defined, either peer could unilaterally initiate it.  There's no technical reason why this shouldn't be allowed.  If the server cares, and it doesn't see any activity from the client, it could use the keep-alive too.

As Jamie points out, the server frequently doesn't care.  More to the point - the server can't do little about it if the connection does go away.  (I can imagine use of other channels to prod the client into wakefulness, but that's not something inherent to WS.)  Rather than outright prohibition, I'd instead prefer to discourage server use of keep-alive (SHOULD NOT).

Servers might know better - we have a server that has a 5 minute TCP "go dead" interval on the load balancer in front of it.  That server should not be outright prevented from sending a 4:55 keep-alive if it sees nothing from a client.

--Martin

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, 20 April 2010 4:51 PM
> To: Thomson, Martin; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [hybi] NAT reset recovery? Was: Extensibility mechanisms?
> 
> 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