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

[Graham Klyne <[e-mail]>]

Greg Wilkins wrote:
> 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.

Primarily event delivery for real-time control and monitoring.  A few more notes 
are here: http://code.google.com/p/webbrick-events/wiki/EventModel.

Also, as noted there, providing notification that data has changed so that web 
pages can refresh themselves.

These applications are essentially channel-free, being more 
datagram/message/event oriented than session oriented, using some kind of global 
identifier space (e.g. URIs) for disambiguation where needed.

I'm also in conversation with the Wookie Widgets team 
(http://getwookie.org/Welcome.html) for another project I'm working on 
(http://code.google.com/p/shuffl/).

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

No, I'm not, but I'm also prepared to consider using multiple TCP connections in 
such circumstances.  Typically, I've seen requirements to put up to about 5 
different semi-independent widgets on a page.

I fully accept that your mileage may vary here.

Also, I seem to recall there was some IETF work on congestion control that could 
  reduce some of the problems with running multiple TCP channels ...

[Googling...]
http://tools.ietf.org/html/rfc2914
http://tools.ietf.org/html/rfc2481
http://tools.ietf.org/html/rfc4336
http://tools.ietf.org/html/rfc3124

I think the last one is the one I recall.

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

No I'm not, but any transparent proxy that does that must surely ensure that 
multiple connections still appear to the application as independent connections, 
or it's fundamentally broken.  I think that such multiple connection tunneling 
might be the right way to go.  I could imagine server-to-server BEEP being used 
to tunnel multiple WebSocket sessions over a single connection - and here, the 
complexity of BEEP might be justified.

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

I guess that I'm not convinced that you can make multiplexing much simpler than 
BEEP and not end up being broken.  When I reviewed BEEP a few years back, I 
thought about trying to avoid the complexities of per-channel flow control, but 
in the end I couldn't see any way of doing that without running the risk that 
one channel could starve all the others.  But with per-channel flow control 
comes the need for some quite complex buffering arrangements.

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

Hmmm... in principle, I understand that HTTP can be run over any full-duplex 
connection.  I see nothing in WebSockets that prevents similar behaviour.

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

While I can agree that the XHR interface is too low-level, and that there are 
better abstractions, and I could agree that the API makes it harder to multiplex 
on a connection, I don;t see anything in the API that actually makes such 
multiplexing impossible.

Also, I haven't really studied a WebSocket API as such - I have looked at a 
protocol spec.  I might agree that an API design should not make it hard to 
multiplex, but that's a different question to what I understood to be under 
discussion here.

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

These are reasonable points, but see above my comments of API vs protocols.

I can also see that there may be aspects of the protocol I've not noticed that 
make such abstraction harder, and which can be fixed relatively cheaply.  (I'm 
thinking of examples like the original FTP protocol being hard to run through 
NAT - not that I claim that's a good example of desirability).

#g