Re: [hybi] Are keep-alives necessary? Was: Re: NAT reset recovery? Was: Extensibility mechanisms?

[Hugh Winkler <[e-mail]>]

On Tue, Apr 20, 2010 at 11:39 AM, Vladimir Katardjiev <[e-mail]> wrote:

> All technically correct, and completely accurate if we assume the only reason the WebSocket API would be used would be to send() data to a remote endpoint. But websocket is a bidirectional API, meaning it should both send and receive messages. Going back to the tic tac toe example, my side (client) is waiting for the other side (server) to make their turn, there will never come a point in time at which my side should send a message (it's not my turn). There's also no reasonable expectation of when the other side is going to make their move (=send me a message). And even if the remote side discovers the connection is dropped, it can't do anything because I'm behind a NAT.
> So either the WS realisation would need to open a new TCP connection every 5 minutes of no traffic (just in case the old one died, because there's no way to recognise that), or it would need some form of message that would trigger traffic on the channel thus making it clear it's still open. Otherwise the WSAPI won't be able to receive messages from the remote endpoint at arbitrary time points.


Yes, duh. I don't know what I was thinking. That's the most important
case: replacing hanging GET. Of course it's necessary to keep that TCP
connection alive so I can receive the message from the server, my
mistake.


Hugh