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

[Greg Wilkins <[e-mail]>]

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?

So far the majority of opinions I've seen on this list and the whatwg list
have been favourable to multiplexing.   Can you invite them to post their
opinions here?


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

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


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


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



regards