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

[<[e-mail]>]

Hi,

Mike Belshe wrote:
On Mon, Apr 19, 2010 at 2:17 AM, Jamie Lokier <[e-mail]<mailto:[e-mail]>> wrote:


Less robust - I put together an alternative to Ian's "tic tac toe"
using long-GET HTTP.  It's a similar amount of code with a similar
structure, and as far as I can tell fails in all the exact same
scenarios, except for one: The HTTP version keeps working after a NAT
or SPI router times out in the middle.  The WebSocket version breaks
at that point, because it won't detect the broken TCP connection or
create a new one.

The NAT point is a great one.  I don't have any data on how often long-lived connections are broken by NAT.  We need this.  Unfortunately, I bet may NATs just drop the connection without notifying the endpoints (e.g. never sends a RST).   This could become problematic for websockets, I'm not sure.  Keepalives may help some, but I bet NATs are smart enough to break even there too.  Data is needed....

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.

Is this still an open issue or has it been discussed and resolved in some way already?

Markus