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

[Jamie Lokier <[e-mail]>]

Hugh Winkler wrote:
> 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.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^

It takes TCP a very long time to discover that the connection has gone
away after sending - depending on how it went away.

We're talking between 15 minutes and 2 hours, depending on platform.
(Max TCP retransmits, if platform doesn't use TCP-level keepalives.)

Nobody wants a web page showing their live inbox that is 2 hours out
of date because it didn't know to make a new connection.

> 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.

Letting send() messages be duplicated by the WS implementation (which
is what idempotent means here) is not reasonable.  Application writers
would routinely ignore that part of the spec because it doesn't happen
most of the time and it's hard to work with.  It *could* be hidden
from applications with unique message ids and a history buffer on the
server, however.

Disconnecting when idle breaks things like "online presence" and
"client receives event when something happens on server".

Those are big reasons for using WebSocket.

Handset manufacturers would not be happy, because your proposal would
force those kind of apps to send a request every few seconds, like
they do today over HTTP and we're trying to improve on.  (Think of
Facebook etc. using up your phone's battery despite no updates.)
(Multiply by 20 other background apps.)

-- Jamie