Subject: Re: [hybi] #4: handshake does not work properly with HTTP reverse proxy.

From: "Shelby Moore" <[email-masked]>
Date: Sun, 15 Aug 2010 05:59:26 -0400

Greg Wilkins wrote:
> This is already an issue with cometd-2, now that we support websocket
> as an optional transport.  When it is enabled, there is noticeable
> additional establishing a comet web page (eg logging into a chat
> room), while websocket hand shake is tried and fails, before the next
> handshake is tried.

Use the BOSH or Comet in parallel until WebSocket handshake is completed?

Seems that any application that wants to use WebSocket must have a backup
Comet or BOSH infrastructure, otherwise lose features depending on the
network state.

I understand the concensus to be that unless we use a separate port for
WebSockets (and lose the HTTP firewall tunneling), failure of incompatible
transparent proxies will occur non-deterministically as data is sent
through (minimized if we operate encrypted)?  So maybe WebSockets needs to
be married with Comet or BOSH not just for HTTP Upgrade handshake, but
also for backup infrastructure with per data frame handshaking and data
integrity hashes over the WebSocket? A keep-alive ping won't insure your
data hasn't been corrupted by the intermediary proxy. I think this is why
Ian Hickson was striving to force each proxy to declare that it had been
specifically coded to support WebSockets, so in theory we would have some
assurance that data transfers were not corrupted.  But in theory, any
proxy that correctly supports Upgrade should do that, no need the extra 8
characters proposal 76.  It is just that the extra 8 characters forces the
proxy to declare that it (fully?) supports WebSockets (but still there is
not guarantee about "fully").

Thus without using a separate port for WebSockets, I have started to
ponder the benefit as compared to BOSH:

http://xmpp.org/extensions/xep-0124.html#technique

I think I have started to understand why eliminating false positive was
such an important priority for Ian, but I still don't agree (for reasons
previous stated).

Seems for WebSocket to be robust over HTTP ports (at least 80), we are
going need to do handshaking on each data transfer, so am I correct that
would eliminate most of the theoretical bandwidth and latency advantages
over BOSH?

And BOSH has the advantage of being compliant HTTP, so it will work with
more networks with less timeout, corruption, and re-send scenarios.

Sorry to drop a Snicker bar in the swimming pool. Maybe someone can set me
straight.

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 16 Aug 2010 09:50:44 +1000

> Use the BOSH or Comet in parallel until WebSocket handshake is completed?

Using websocket in parallel would just increase the connection count
and complexity of applications as they try to deal with something that
is essentially a transport concern.

When a web page downloads, the browser will typically use 2-6 HTTP
connections to download all the content, css, images, script etc.   It
makes perfect sense to me that if the scripts then start a websocket
connection, then the browser should be able to take one of those 2-6
existing connections an try a websocket upgrade.  That is a single
round trip to check and establish websocket is supported.

Sure there are failure modes where a websocket connection is accepted,
but then does not actually work (or subsequently fails to work).  But
there are similar failure modes with BOSH/comet and implementations of
those protocols still need to implement timeouts etc to catch all
failures. Websocket is not a silver bullet that will suddenly make the
internet a truly error free reliable network.

For me, the attraction of websocket is mostly that it offers the
possibility of reducing the long term connection count per client from
2 to 1. That it promises some potential improvements in data density
and max latency is entirely secondary for me.

cheers

---

From: "Shelby Moore" <[email-masked]>
Date: Sun, 15 Aug 2010 21:20:12 -0400

> and max latency is entirely secondary for me.

Agreed, but won't there be cases where WS/HTTP will refuse to work and
thus you must have Comet/BOSH to fall back on as they always work.  Do not
conflate timeouts with unrecoverable failure, where for example a proxy
still won't allow some data to pass though in WS/HTTP.

WS/port+tunnel is another option that uses only 1 connection and it has
advantage that the hard failure (not the recoverable timeouts and network
instability) will occur at the handshake and only once per
client+server(+DCHP lease) pair.