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

[Graham Klyne <[e-mail]>]

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.

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

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

#g
--

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?
> 
> 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
> 
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>