Re: [hybi] Extensibility mechanisms?

[Jamie Lokier <[e-mail]>]

Mike Belshe wrote:
> 
>    On Mon, Apr 19, 2010 at 2:17 AM, Jamie Lokier <[1][e-mail]>
>    wrote:
> 
>    Adam Barth wrote:
>    > On Sun, Apr 18, 2010 at 1:47 PM, Greg Wilkins <[2][e-mail]>
>    wrote:
>    > > Ian Hickson wrote:
> 
>    > > Intermediaries can know about websocket framing and so long as
>    > > all sub protocols and extensions are restricted to adhere to
>    > > websocket framing, then intermediaries can continue to work
>    > > regardless of sub protocols.
>    >
>    > I'm not sure I buy the premise that we want intermediaries to
>    > understand and/or interfere with the websocket protocol.  It seems
>    > more robust and more secure to establish a point-to-point encrypted
>    > tunnel between the user agent and the server.
> 
>      More secure, but higher latency and slower.
>      Going by the "each application on each open web page should open
>      its
>      own connection" approach, and encrypted tunnels enforcing that, as
>      well as enforcing TLS setup latency for each one, *much* slower
>      than
>      HTTP.  Not to mention the torrent of idle keepalives with so many
>      connections.
> 
>    A few notes:
>       - The bulk of the time goes to round trips.
>       - WebSockets has a round trip for the upgrade header too.
> 
>      Less robust - I put together an alternative to Ian's "tic tac toe"
>      using long-GET HTTP.  It's a similar amount of code with a similar
>      structure, and as far as I can tell fails in all the exact same
>      scenarios, except for one: The HTTP version keeps working after a
>      NAT
>      or SPI router times out in the middle.  The WebSocket version
>      breaks
>      at that point, because it won't detect the broken TCP connection or
>      create a new one.
> 
>    The NAT point is a great one.  I don't have any data on how often
>    long-lived connections are broken by NAT.

In my world, the long-lived ones are the ones broken most often :-)

I've seen a lot of NAT breakage in different situations: mobile
networks (30s timeout on some), home ADSL reboots, home NAT table
overloaded due to multiple users, corporate WANs daily at exactly 3pm
:-); it surprises me how much there is.

>      One of the not so obvious strengths of HTTP, which probably wasn't
>      deliberate design, is it recovers well from contemporary
>      TCP-breaking
>      routers.
> 
>    True true true!  Lots of short connections, although less efficient,
>    are self-healing and robust.

Even HTTP gets stuck, though, if the browser reuses a TCP connection
that has become black-holed.

The reason that isn't such a problem with Comet style is those
frameworks already have a timeout and reconnect on the client side to
deal with well-known brokenness :-) With some AJAXy apps, black-holed
persistent HTTP is still a problem, and it can take a while for the
apps to react and recover, if they recover at all.

I suspect a certain amount of "users knows the web is flaky and know
to reload the page if it's not working properly".  I certainly find
myself reloading Facebook from time to time because it's AJAXy
processing is reporting network errors, when on a mobile network.

-- Jamie