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

[Ian Hickson <[e-mail]>]

On Mon, 12 Oct 2009, Greg Wilkins wrote:
> Ian Hickson wrote:
> 
> > FWIW, so far I've concluded (based on long discussions with a number 
> > of developers and implementors) that multiplexing would actually not 
> > be that great.
> 
> Which developers/implementors?

A number of people from various teams at Google and Mozilla in person, and 
also on IRC with people from other browser vendors and Web authors who 
participate in the WHATWG work.


> So far the majority of opinions I've seen on this list and the whatwg 
> list have been favourable to multiplexing.

I don't think that's entirely accurate. Don't forget, also, that since the 
spec doesn't have multiplexing, people who don't want multiplexing aren't 
likely to post... Just like you haven't been posting in favour of the spec 
not supporting DRM.


> Can you invite them to post their opinions here?

I do so, yes. That they don't is why I go and seek them out. :-)


> > However, WebSocket connections are long lived by design,
> 
> I do not believe you can anticipate websocket usage over the long term.  
> Just because you think now they will only be used for long lived 
> connections, that may not always be the case.

Well using Web Socket for a short request-response burst would be pretty 
stupid (given HTTP)... What other uses do you have in mind?

While we can't know what the protocol will be used for, we _can_ know what 
it is _intended_ to be used for, and that's what we should optimise for. 
We don't have to preclude other uses, but we also don't have to optimise 
for them... especially at the cost of the intended uses.


> It is short sighted to build such limitations into a once-in-a-decade 
> chance to upgrade the protocols we use on the web.

This is not a once-in-a-decade chance.


> > and the cost of setting up a connection therefore is insignificant 
> > compared to the cost of the protocol itself.
> 
> There is also a cost associated with maintaining and servicing a 
> connection.

This would be the same cost associated with maintaining and servicing a 
channel in a multiplexed connection.


> > There's also something to be said for relying on TCP's built in 
> > congestion control -- if you were to open two connections to a server, 
> > one sending vast amounts of data, and one sending just the occasional 
> > critically important notification, it would be best if the latter 
> > could avoid getting throttled along with the first.
> 
> Some would argue that is improperly bypassing TCP's congestion control.
> 
> I have often seen the horrid argument put that if you use 8 connections 
> instead of 1, then you are more likely to get better service from a 
> router that is fair sharing capacity among connections.  That path leads 
> to an irrational arms race as once everybody uses 8 connections, 
> somebody will use 16 to get better service etc etc.
> 
> Implementing connection policies is not something that should be left to 
> the application developer. It is far far better that the browsers 
> implement connection control policies.

I disagree. I think it's far better that the _server_ decide the 
connection control policies. That's the model Web Sockets follows (as an 
author you'll do whatever the server expects).


> > As with anything, though, there's always the option of changing this 
> > if strong arguments one way or the other are put forward. We can also 
> > introduce multiplexing as a new version of the protocol in a future 
> > version.
> 
> Protocol versions come once maybe twice a decade.  Please consider the 
> future and not just short term needs of one particular interest group.

I see no reason why we can't rev it more often. If you are basing this on 
the stagnation of 1998-2008, then I think you are misinterpreting the 
events.


On Tue, 13 Oct 2009, Greg Wilkins wrote:
> 
> 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.

Multiplexing at the per-path level would be of extremely limited use, 
IMHO. If there really are multiple widgets talking back to the same 
_server_, they certainly won't be talking back to the same _path_.


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

Sure. You just build a library on top of this. It's not a problem as far 
as I can tell.


> But even if the frameworks implemented to same wire protocol for 
> multiplexing, they would not be able to:
> 
>   + share connections between frameworks

Even with multiplexing we wouldn't be able to share connections between 
server-side frameworks -- why would someone use two client-side frameworks 
but the same server-side framework?


>   + share connections with code written directly to the websocket API.

That's basically just another framework.


>   + share connections with other iframes, tabs and/or windows.

This seems far too infrequent an occurrance to really optimise for.


>   + implement a strong origin policy for security

I don't understand what situation would lead to multiple channels having 
different origins but talking to the same server with the same 
authentication cookies and the same path.


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

This seems far too abstract, frankly.


At this stage my recommendation if you think multiplexing is important 
would be to propose an alternative protocol and get browser vendor buy-in 
for that protocol. Browsers haven't committed to implementing Web Sockets 
yet (though some are experimenting with it), so now would be the best time 
to see if you can convince them that it is preferable to have that support 
in the protocol rather than layered on top of it.

Personally the more I think about what one would have to do to implement 
multiplexing at the Web Sockets level the more I am convinced that it's 
simply not worth it. It would easily double or even triple the complexity 
of the wire protocol, and it would add very little for authors.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'