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

[Jamie Lokier <[e-mail]>]

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