Re: [hybi] WS port with BOSH-like fallback?

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
> On 1 December 2010 11:59, Jamie Lokier <[e-mail]> wrote:
> > Alakkad, Achuth (GE Healthcare) wrote:
> >>
> >>    To me the main advantage of websocket is that, it makes use of
> >>    exisiting accepted port (80). Thus not affecting any intermediatory
> >>    devices, such as firewal configuration. If we are going to go with an
> >>    independent port for websockets, then will it start of a monotonous
> >>    rework for those devices ( like firewall, proxy etc..).
> >
> > I think Greg's idea is that if the other port fails, then it will use
> > BOSH-like over port 80, which is real HTTP tunnelling the data, so
> > your WebSocket application will work fine over firewalls and proxies.
> 
> That's a correct paraphrasing.
> 
> Looking at the numbers, it appears that no matter what handshake we
> use, we are looking at only a <80% success rate for websocket
> connections.

That's quite interesting.  I hadn't expected it to be so bad for every
method equally.

> > The only problem I see with Greg's idea is how long to wait after
> > trying the other port, before deciding that it isn't working.  Latency
> > is poor.
> 
> Indeed - but at least that would be a driver to motivate people to
> advocate for opening the WS port.

Well, a reasonable timeout might be 20 seconds, which is rather a long
time for a page to become interactive - especially if it's every time
you load the page or follow a link.

A shorter timeout is likely to give lots of false negatives - on
exactly the connections where data/packet/connection density matters
the most.

> Besides, I doubt we can give full service to the last 20% anyway
> because of data density issues etc.

Do you have any measurements to support the intuition that WS has
better data density than HTTP?

Inuitively it ought to, but most modern networks measure data density
in moderately sized packets not bytes.  Also, when large numbers of
bytes are involved in a short time, HTTP methods can aggregate many
bytes into fewer HTTP requests, so amortising away the HTTP headers.

So I wonder if you have any measurements to support the idea of users
failing to get useful service due to WS data density differences or
other WS factors?

I suspect the variation in what type of network access users have is
so great, that a difference of data density, if there is one, won't
make a "full service or not" difference to the majority of users -
only those whose bandwidth on a particular day happens to be close to
a particular threshold.

> > Application writers won't care about the workings - they'll just use a
> > WebSocket object which magically works - and it'll work in all places
> > where BOSH-like works at the moment.
> >
> > By the way, that's currently possible in Javascript in some current
> > browsers, using WebSocket to another port in parallel with BOSH-like
> > HTTP using XHR, and wrapping it up in a "MyWebSocket" object.
> 
> Indeed - I've not yet convinced myself that a BOSH-like long poll
> should exist as part of a the protocol or as part of the framework.
> But I do think that the success rate of WS over 80 is not going to be
> significantly higher than WS over dedicated port, so I'm really
> wondering why we are putting ourselves through this pain.

Maybe we're doing it so that we actually get the necessary
measurements to confirm that the success rate is similar in both
cases, with a variety of handshake methods.

Has anyone tried measuring the connection success rate - and
messages/packets/data/latencies - of "valid" HTTP port 80 techniques:
such as single-connection bidirectional chunked POST, and various
dual-connection pipelined-POST/GET (one upstream, one downstream)?

-- Jamie