Re: [hybi] #1: HTTP Compliance

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
>    I can visibly tell when establishing a
>    chat room if I have the WS transport enabled in the client or not,
>    because I can see the extra delays as WS is tried and fails.
>    This will be a barrier to frameworks like cometd-2 including WS in
>    their transport negotiations.

(Aside: I think Ian's past responses suggest the following resolution:
When you're establishing a chat room connection, you *ought* to know
if you're connecting to a WS-aware chat service, in the same way that
you already must know in advance which WS subprotocol to request
if you do get a WS connection.)

As noted some time ago, even when WS negotation *succeeds*, it can be
slower than comet-style HTTP, both slower in sending the first
messages, and slower in receiving the first responses.

That situation is ridiculous.

It means latency-optimised apps may open *two* connections in
parallel: One comet-style HTTP, and one WebSocket.  They will
communicate initial messages over the HTTP connection, and switch to
the WebSocket connection when that is ready.  That's not kind on
low bandwidth links, nor easy to program, so it's an ugly compromise.

We can greatly improve the situation by avoiding some delays in the
negotiation sequence.

Unfortunately it seems each "waiting point" needs a different method
of avoidance, so TLS negotation round trip delay is reduced only by
using an ignorable TLS extension to carry initial messages; HTTP
handshake round trip delay is reduced only by encoding initial
messages in a HTTP-compatible manner, post-HTTP confirmation round
trip delay is removed only by encoding initial messages in a way that
is harmless to non-WS servers, and delays to messages originating
between those stages are reduced only by rather fiddly inter-stage
encodings.

(Ideally we'd avoid the TCP 3-way handshake round trip too by
including some data in the SYN, finally outperforming HTTP :-), but I
have the uncertain impression that's considered inadvisable.)

Fortunately there is a systematic approach possible, even though the
details are annoyingly technical, and fortunately each step could be
optionally implemented or not according to the implementer's
preference.  Simple implementations could ignore them entirely.

-- Jamie