Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

[Zhong Yu <[e-mail]>]

On Wed, May 22, 2013 at 11:26 AM, John A. Tamplin <[e-mail]> wrote:

> On Wed, May 22, 2013 at 11:12 AM, Tobias Oberstein <
> [e-mail]> wrote:
>
>> +1 for the simplest possible mux that does the core job.
>>
>> However, I currently think that having a per-logical channel flow control
>> is required to make it useful (cannot be dropped for the sake of
>> simplification). I might be wrong.
>>
>
> I agree -- without flow control, there is very little benefit, and almost
> nothing that an app couldn't easily do themselves by just adding a simple
> framing layer inside WS messages (perhaps just the first byte is a logical
> channel number).
>
>
In traditional socket programming model, the application chooses the time
and the speed to perform read(). If the application is not reading fast
enough, the receive buffer is full and more incoming data are not welcome.

Contrary to that, most WebSocket API are event based - all incoming message
data are buffered without any blocking, then the complete message is sent
to the application callback. In this model, per channel flow control
doesn't seems to exist.

If per channel flow control is removed from the spec, what use cases would
suffer?

--
And I have a stupid question - what's the motivation to do mux on
WebSocket? To save local port numbers? To avoid slow start? If we drop mux
all together, what use cases would suffer?

Zhong Yu