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

[Takeshi Yoshino <[e-mail]>]

On Thu, May 23, 2013 at 1:48 AM, Simone Bordet <[e-mail]> wrote:

> On Wed, May 22, 2013 at 6:26 PM, John A. Tamplin <[e-mail]> wrote:
> > 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 SPDY, the flow control had an initial window of 64k. This proved way
> too small for uploads/downloads, which resulted in a 3x or more slowdown.
> So there needs to be in ws a mechanism to configure this window (which
> SPDY has).
>

NewChannelSlot can do this. I don't think adding SETTINGS is simpler than
NewChannelSlot.

Instead of dropping NewChannelSlot, I'd rather suggest dropping "N mux
control in 1 message" format, "Handshake size" field in AddChannelRequest,
AddChannelResponse, "Reason size" in DropChannel.


> So "simple mux" looks like an oxymoron to me, and makes me wonder what
> useful could be a ws mux solution that does not do dynamic channel
> prioritization.
>
A typical use case Joakim presented to me was to tune video download rate
> in a websocket server: a big priority initially to download faster than the
> client video player plays, to make some buffer, and then reducing the
> priority to a steady state with the video player's speed, or reducing
> priority to almost zero if the user pauses the play.
>

Isn't it in-app priority? Can't script and server address that problem? If
only the client knows current priority, the client can tell the priority to
the peer servlet using a WebSocket message. If the server know priority for
each position, it can just control transmission speed.

Even if we need help by the server, the servlet would call some special
function to tell the server about priority.

Different from HTTP/2.0's case, we don't need to provide a special field in
mux protocol to pass priority, I think.