Re: [hybi] Multiplexing in WebSocket (Was: HyBi Design Space)

[Greg Wilkins <[e-mail]>]

Graham Klyne wrote:
> To add just one voice among many...
> 
> (1) in the use-cases that I've considered for pushing messages/requests
> to a browser, multiplexing is not a requirement.  Other's mileage may,
> of course, vary.

Graham, it would be great if you could briefly describe
your use-cases.

Are you sure that they will never be mashed up into a webapp made
of many parts that originally were not designed to work together?

Are you sure that they would never run behind a transparent proxy
that might aggregate multiple connections into a single connection?


> (2) Looking at a multiplexing protocol such as BEEP, multiplexing adds a
> *lot* of complexity to the protocol specification and implementation.  I
> would say that the case for multiplexing in the base protocol needs to
> be made to justify that added complexity.

I totally agree that the multiplexing of BEEP is too complex for
the level of protocol that we are considering.

But multiplexing can be much much simpler.  At it simplest,
it just needs a channel id in each frame and the channel creation
can be automatic.   In the BWTP protocol proposal, I've added
a little bit of channel creation exchange, so as to well match
the explicit life cycle events of the websocket API.

> (3) It seems to me that, if needed, a multiplexing layer could be
> specified and standardized over a non-multiplexing substrate.

Normally I do believe layering protocols like you describe would be
a good approach. But...

The difficulty is that with websocket protocol, it has a hard binding
to the application websocket API.  There is no scope provided to inject
another layer.   The API has explicit  open/close events (which I think
should be mapped to channels), but that are currently mapped to connections.
Thus applications and/or frameworks will be doing explicit connection
management.

This is analogous to the advent of XHR in the browser. Every Ajax
books then started with a chapter about how to write your own Ajax
code directly using XHR.  But XHR is a too low level API for
applications and it has taken many years to abstract the average
ajax developer away from direct XHR access.  So now we have
frameworks such as dojo, jquery, yahoo, ext etc that provide an
abstraction on top of XHR.

Probably these frameworks will be able to provide good abstractions
on top of websocket API, and this may well include multiplexing
support.   But even if the frameworks implemented to same wire
protocol for multiplexing, they would not be able to:

  + share connections between frameworks
  + share connections with code written directly to the websocket API.
  + share connections with other iframes, tabs and/or windows.
  + implement a strong origin policy for security


I believe that these desirable things can only be achieved if
it is the browser rather than the application that implements
the multi-plexing.

The fundamental problem with websocket API is that is both
a connection API (open/close) and a messaging API (send/onMessage).
The API needs to be abstracted away from any hard relationship
to TCP/IP connections.   This can be done with a simple rename
of s/connection/channel/.     Applications can then manage channels
and the browser/server can manage mapping those channels to
connections - perhaps with multiplexing or perhaps without.


cheers