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

[Jamie Lokier <[e-mail]>]

Dave Cridland wrote:
> On Tue Apr 20 13:42:47 2010, [e-mail] wrote:
> >>Having the server send a SP on an idle session is
> >>useful for defeating NAT timeouts,
> >
> >Here I'd really prefer the client to do it, as it should know  
> >better. And the host can potentially optimize between different  
> >connections etc.

The client only knows about it's nearest hop, usually.  Upstream
knowledge is known to intermediaries and servers.  In a server farm,
reverse proxies usually have the best local knowledge.  With mobile
data, if a 3G router is used, the router knows better than the client
what to do - especially for optimising radio power.

What do you mean about optimizing between different connections?

> I'm open to suggestions.

I really want intermediaries to have an *optional* way to intercept
the keepalive function - so they can optimise with link/hop-level
knowledge.  For example mobile links using a different mechanism that
uses less radio power, proxies at specific locations extending the
keepalive interval for specific hops, timing synchronisation between
connections at a hop to minimise radio power, and multiplexers (not
necessarily using WebSocket, but carrying it) aggregating multiple
connection's keepalives into fewer.  Far fewer.

Aall that's needed is the keepalive message types are well known and
allowed to be adjusted by intermediaries.  And negotiation is also
well known.  Simple intermediaries will just pass them on.

> If the server sends a simple keepalive only on silent connections on
> a reasonably lengthy interval, this seems to be to cover most
> options - it in effect means that clients can do it sooner if they
> wish.

For the server to know when a connection is stale, why not tell the
client to send an SP after 29 minutes (like AMQP)?  Client
compatibility, or is there a technical reason to prefer ping if the
protocol were designed from scratch?

Isn't 30 minutes a rather long time to detect a user's presence is
lost?  I expect a lot of WebSocket applications to have a "presence"
pattern like XMPP's, but with different timing requirements.

Interactive web sites tracking online users may want an aggressive
timeout on the server side - as low as a few seconds in some cases,
more likely tens of seconds or a few minutes.

If the transport does KA at all, it's better if the application can
request specific KA timings from the transport, instead of sending a
second layer of "application KAs", which wouldn't be able to
participate in timing/power optimisations and hop/link-level substition.

-- Jamie