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

[Vladimir Katardjiev <[e-mail]>]

On 19 apr 2010, at 14.10, Jamie Lokier wrote:
> Keepalives have two roles, and they actually have *distinct* timing
> requirements:
> 
>    1. To tell NATs / SPIs / TCP relays / HTTP proxies (CONNECT)
>       not to drop the connection.
> 
>    2. To tell the client application that the connection is still
>       present so it knows when to abort and make a *new* connection.
> 
> The timeout needed for 1 is typically larger than the timeout for 2
> but it depends on the app.
> 
> 1 is network dependent; 2 is application dependent.

#2 is the key, at least to me, and #1 a happy coincidence. The keepalive can tell the application when the connection is NOT there. To put this in the context, I have a very simple expectation of the WebSocket (browser) API.

onconnect() should tell me when the connection is ready for use
onclose() should tell me when the connection is dead. I can't use it anymore so I need to make a new one.

This is because after onconnect() I should be able to assume a persistent connection (that's the point of WebSockets, no?) until the browser tells me otherwise. All applications that depend on user-generated inputs (or unpredictable inputs in general) need it. Unpredictable inputs are things that the application can't know are going to happen, so the general application code is silent waiting for an event to occur.

Take, for no particular reason, the case of a web-based Tic Tac Toe application. Suppose it is the opponent's turn to move, but he went afk. Meanwhile, some NAT on the path decided it wants to close the connection. Since it's not my turn to move, my client should not have any reason to send traffic over the connection. It also doesn't have any set time it expects a response (because the other party is human the application has no way to know when he'll move). 

Suppose instead we added some way for one point (for the purposes of this discussion, let's say client but I don't want to exclude server /or intermediary/) to send a keepalive message as part of the protocol. This would be propagated to the endpoint in the given direction where the specification just says "echo it back". The burden of implementation on the server end is minimal, but it opens up for a number of improvements.

- Browsers can opt to include an adaptive keepalive algorithm that automatically keeps tabs on connection idling and sends a keepalive after a certain amount of time of no traffic. Trivial JS implementation is a function that has setTimeout(sendkeepalive(), 30000) and thus unequivocally sends a keepalive every 30 seconds even if there's activity on the line. 

- Nodes that know their connections won't be interrupted can opt to drop the keepalives between themselves and just replicate them at the edges. This may not be sexy, but now apply it between a mobile phone client and its first-hop proxy. If it's a WS-aware proxy, and there's some form of keepalive negotiation, they can determine that keepalives are unnecessary, or have a longer timer than is usual (within a controlled network this is possible) and not send them. For a mobile phone, this can incur significant battery savings (or, rather, not doing it may kill a smartphone's battery in less than a day for only keepalives). The keepalives can be regenerated at the edges so the target server wouldn't see anything different.

- The client can actually be told when a connection is dropped by onclose(wasClean=false) being triggered, and thus reestablish the connection. I mean, if you open a connection, surely you want to know if it's no longer available...

- Our hypothetical amateur programmer, testing his websocket connection against localhost, won't see the need for keepalives, but the protocol requiring them will stop his application from failing on the Wild Web. All he needs to do is echo back the bytes the browser sent, and the expert browser programmer handles the rest.

So I'd rather say I am having trouble seeing what applications would _not_ want keepalive functionality as part of the base offering of WebSockets.

> 
>>   but I bet NATs are smart enough to break even there too.  Data is
>>   needed....
> 
> I can give you personal experience.  Yes: NATs do break connections
> with traffic on them.

Of course, that's not the only thing that can fail silently. Lost connections due to other issues than NATs are also prevalent, anything from a cord being cut to someone using a wireless connection and going into a tunnel.

(This only appears to contradict what I said above on mobile keepalives if you assume all mobile networks are equal. They're not. What I want to say though is that even though we assume a general case where the connection WILL fail if it's left on its own, we should make it possible to make the transfer more efficient)
> 
>>   I agree this is an important point. If I'm writing an application on
>>   top of the WebSocket API, is it my responsibility to deal with
>>   keepalives and connection failures due to NAT timer resets or reboots,
>>   or does the protocol do somethig for me in this regard? I suppose the
>>   current draft (-75) is pretty silent on this, which means it's all up
>>   to the application programmer. That sounds a bit unreasonable if we
>>   want the app development to be really simple. Probably, even if the
>>   app developers figured out how to do it, they probably would not do it
>>   in an optimal manner. So, I suppose it would be good to have either an
>>   extension (or a subprotocol) to deal with this. At least it's a piece
>>   of code that all client side apps will need anyway. I am not sure to
>>   which level it needs to be standardized, but there has to be some way
>>   to get it done.
[...]
> There is currently no consensus on whether the application should
> handle these network issues itself, or if the WebSocket implementation
> should play a role.
> 
> [...]
> 
> Proxy and server implementers seem to prefer that WebSockets handles
> it, so application programmers get a robust pipe without having to deal
> with these issues (and it might use the network a bit better).

This really depends on how you define "robust". I'm okay with WebSockets failing because the recovery conditions aren't necessarily easy to define, and for some values of robustness you need to do stuff like deferring messages on the server-side, and then you need to identify the connection that requested them, and then authenticate it (if needed) and then you need to determine when you're NOT waiting for the robustness recovery, and it just goes on and on forever, much like this sentence.

So, yeah. Failure is good. My preference, though, is that the protocol itself takes care of the failing part if the failure is due to the network conditions, so anything written on top of the protocol doesn't have to keep doing the same old networking traps every. single. time. Though it doesn't hurt if the protocol also minimises the risk of failure, and, go figure, keepalives do both. Keepalives for President!

Vladimir