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

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 01 Dec 2010 19:57:26 +0900

On 2010/11/30 23:53, Brodie Thiesfield wrote:
> On Mon, Nov 29, 2010 at 8:49 AM, Greg Wilkins<[email-masked]>  wrote:
>>
>> So tell me again why we don't just ask IANA for a websocket port?
>>
>> Browsers can try to port and if it fails to connect they can fall back to
>> something like BOSH over port 80.
>> This get's us through firewalls and keep port 80 for HTTP.
>>
>> I think that is the right technical solution (use ports for what ports were
>> designed for) and avoids the growing conflict over usage of port 80.
>
> +1
>
> If WS does become popular and necessary (like HTTPS) then over time
> the WS port will be opened up in more locations. Clients should prefer
> the dedicated port, and when not available, support fallback to an
> attempted upgrade/connect via port 80.

This also seems to be supported by http://websocketstest.com/ws/stats. 
There is a figure entitled "WebSockets Success Rate by Port Number". The 
numbers are 80 => 69.71, 8080 =>69.1, 443 => 72.45. The difference 
between the eighties and 443 may be statistically significant, but I 
doubt that the difference between 80 and 8080 is statistically significant.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 1 Dec 2010 10:59:39 +0000

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.

All the current WebSocket schemes break on port 80 for a signficant
fraction of users, so it's not like the port 80 problem is solved yet.

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.

Maybe the solution is to maintain a destination cache in the client,
use BOSH-like over port 80 immediately for destinations not known or
where previously it was needed, and attempt the other port for a few
seconds first when the destination cache says it worked before.  In
all cases, where port 80 is used, attempt the other port as well *in
parallel*, and transfer control to it if it succeeds in connecting.

Sounds a bit complicated, but browser and server implementors can
surely handle it.

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.

-- Jamie

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Dec 2010 14:03:00 +0100

> 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 is pretty poor success rate and any real world application is
going to have to have a fallback to some long polling like solution if
it is going to see wide deployment.

This long polling fallback could be part of a framework over
websockets (eg cometd) or we could make it part of the protocol
itself.   Eitherway, once we accept that a fallback will exist, then
success rate becomes less of a factor when picking how websockets
should work.

So just ask for a new port for ws and accept that only 70% of
connections will succeed.   It looks like if we go through all the
effort to use upgrade and/or connect, we are still looking at only
<80%.

> trying the other port, before deciding that it isn't working.  Latency

Indeed - but at least that would be a driver to motivate people to
advocate for opening the WS port.
Besides, I doubt we can give full service to the last 20% anyway
because of data density issues etc.

> 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.

cheers

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 1 Dec 2010 15:26:22 +0000

> use, we are looking at only a <80% success rate for websocket

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

> 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.

> 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.

> 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

---

From: Dave Cridland <[email-masked]>
Date: Wed, 01 Dec 2010 15:32:09 +0000

> dual-connection pipelined-POST/GET (one upstream, one downstream)?

The BOSH community might have done, so I've copied this over to their  
mailing list.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Jack Moffitt <[email-masked]>
Date: Wed, 1 Dec 2010 10:41:00 -0700

> dual-connection pipelined-POST/GET (one upstream, one downstream)?

I don't have any scientific measurements, but I did run a chess
community of about 400k users, and we experienced close to 100%
connection success rate as far as I could tell.  This was using XMPP
BOSH, which on a client typically uses the same two sockets for the
life of the page, and exchanges full HTTP requests and responses
containing XML.  Compression is even used almost always from server to
client, but only on certain browsers in the opposite direction.

My anecdotal experience was that except in the very rare cases were
intermediares have forced timeouts on connection length, everything
worked without a hitch (modulo temporary network failure).  In the
cases where connections were forced closed after N seconds (where N <
60 or so), things still worked, but latency was terrible.

Our success rate for direct XMPP connections with the desktop client
was not as good, since many places block everything but port 80 and
443.  It was always our intention to have the desktop client fall back
to BOSH since BOSH seemed the most reliable.

jack.

---

From: "Alakkad, Achuth (GE Healthcare)" <[email-masked]>
Date: Thu, 23 Dec 2010 17:49:14 +0530

Can we use bosh handshake protocol for websocket upgradation, some thing
like websocket handshake(upgradation) alone over bosh. Once upgraded no
more bosh is used.
Do we have to face any vulnarability in this case, if yes will it be to
bosh protocol as a whole. Embed what ever data we need to send inside
the bosh and then make the server read it from the body for handshaking.