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

[Jamie Lokier <[e-mail]>]

Thomson, Martin wrote:
> However, negotiation seems like overkill for this sort of mechanism.
> Each peer has some expectations and constraints that it knows best.
> Let them each take whatever action they need to ensure that the
> connection stays alive.

If they don't negotiate, the only option is both sides using ping requests.

That is the most expensive KA pattern.

Remember that KA is the *biggest* bandwidth cost in many applications.

It makes the biggest difference when client and server both need to
rapidly detect a stale connection.  (Depends on application - see below).

> If a keep-alive frame is defined, either peer could unilaterally
> initiate it.  There's no technical reason why this shouldn't be
> allowed.  If the server cares, and it doesn't see any activity from
> the client, it could use the keep-alive too.

I agree that a ping request should be defined, and allowed to be sent at
any time by either side.

It is important to treat it as a *request* with other attributes that
generic requests might use, such as matching requests with responses.

Otherwise you get a condition where you send a ping request, get a
ping response, but the response might be an *old* response from 30
seconds ago (queued somewhere) and that doesn't tell you the endpoint
is alive now.

> As Jamie points out, the server frequently doesn't care.  More to
> the point - the server can't do little about it if the connection does
> go away.

Quite untrue.  The server cares a lot.  It *usually* has a less
aggressive timing requirement than the client - but not always, if the
application running on top has "presence" needs or some kind of cloudy
write-back caching (let your imagination run wild ;-).

If it sees no activity, the server must close the connection to avoid
running out of memory in the long run.  It can't make a new connection
(as usual there are exceptions for some applications), but it may
still do something useful, for example deleting an entry from a
"user's online" list.

> (I can imagine use of other channels to prod the client into
> wakefulness, but that's not something inherent to WS.)

Mobile phones, SMS signalling...  I'm guessing a big power saver in
mostly-idle applications.  Not inherent to WS, but WS should be
designed to make those methods possible to use.

> Rather than outright prohibition, I'd instead prefer to discourage
> server use of keep-alive (SHOULD NOT).

I'd discourage the use of SHOULD NOT, because it will only encourage
widespread clients to fail to implement the KA response, and thus make
it impossible for any server to use the feature should the need arise.

Just let implementors decide what to use, and give them good advice.

> Servers might know better - we have a server that has a 5 minute TCP
> "go dead" interval on the load balancer in front of it.  That server
> should not be outright prevented from sending a 4:55 keep-alive if
> it sees nothing from a client.

There is no point in sending the 4:55 keepalive, if you *know* all
working clients send KAs at shorter intervals.  Or is there something
I've missed?

(4:55 is too late, btw, on a mobile network with 6s latency...)

-- Jamie