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

[Hugh Winkler <[e-mail]>]

On Mon, Apr 19, 2010 at 4:36 PM, Vladimir Katardjiev <[e-mail]> wrote:

>
> Having said that, from a mobile perspective this is disastrous. In the worst-case scenario, if your keepalive interval is 5 minutes, you could end up sending a keepalive message every 2.5 minutes. This would wake up the radio twice as often, and, consequently, halve battery life. In a scenario where the server's keepalive is triggered by the client's, the message from the server would likely arrive within the timeframe that the radio is "awake" anyway (3-5 seconds on smartphones) and thus avoid waking it up again.
>

I'm unsure keep-alives are driven by requirements.

It's only necessary to keep the connection alive across long periods
of no activity if you require that applications can expect their
connections to be stateful.

One requirement of web sockets protocol is that it must support WSAPI.
So if WSAPI were to explicitly say that applications may not expect
the remote end of a connection to maintain state across send()s, then
a client implementation of WSP could just initiate a new TCP
connection, if it discovers upon sending that the underlying
connection has been closed.

WSAPI as written doesn't explicitly say whether applications can
expect the server to maintain state, and I think reasonable people can
assume that's implied by the semantics of "connection". But if the
WSAPI explicitly were to say that send() is idempotent, then WSP
wouldn't need to keep the TCP connection alive. An implementation
could open a new TCP connection under the hood for any send. And
handset manufacturers would thank you.

Hugh