Subject: Re: [hybi] Multiplexing: even/odd client/server channel open

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 10 Jul 2012 18:23:25 +0900

Hi Scott,

On Wed, Jun 27, 2012 at 7:41 AM, Scott Ferguson <[email-masked]> wrote:

> In the current draft, only the client can open channels and it can open
> any channel id.
>
> In http-ng (and spdy, I believe), half the channel ids (even) are reserved
> to the client and half the channel ids (odd) are reserved to the server.
>
> This splitting of the channel space allows either end to open a new
> channel without collision. Since spdy is already experimenting with the use
> of server-initiated channels, it's not unreasonable to suppose that some
> websocket applications may want similar capabilities. (Presumably
> non-browser apps or spdy-over-websocket.)
>
>
Alternatively, the odd channels could be reserved for future expansion
> without adding server-initiated channels now, allowing a later version of
> mux to add server-initiated channels.
>

Thanks for suggestion.

I think it's easy to take in your idea. The only loss is that we'll take
more overhead for channel ID field 2 times earlier.

But in practice, we need some more spec text, more error handling for when
an invalid channel ID is received. SPDY has real use case (server push).
WebSocket doesn't for now. We can define mux v2 with such a rule for ID
when server-initiated channel is necessary. Even if we reserve odd (or
even) numbers for future use, endpoints need to be re-implemented to
generate/understand server-initiated channel creation commands.

Anyone interested in this or objects to this?

If S+M adopts WebSocket multiplexing for its multiplexing method, and
adopts server push transactions idea, it would be one real use case, maybe.

> I didn't see a previous discussion on this topic, but I skimmed fairly
> quickly, so disregard if it's been discussed already.
>

You're right.

---

From: "John A. Tamplin" <[email-masked]>
Date: Tue, 10 Jul 2012 16:51:53 -0400

> adopts server push transactions idea, it would be one real use case, maybe.

WebSockets currently only has support for the client initiating a
connection, and it is hard to imagine that changing.  I don't see any
reason that muxing channels should change that.

-- 
John A. Tamplin

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 12 Jul 2012 22:30:11 +0200

On 10 July 2012 22:51, John A. Tamplin <[email-masked]> wrote:
> connection, and it is hard to imagine that changing.  I don't see any reason
> that muxing channels should change that.

There is already a proposal in front of HTTPbis working group that
uses websocket as the framing layer for HTTP/2.0 with a SPDY like
layer on top.    So it is not beyond the imagination that websockets
might one day need to support this.

Making the small investment now in saying client open channels are
odd/even might be a wise investment.  However I don't think we need to
fully specify server opened channels just yet.

cheers

-- 
Greg Wilkins <[email-masked]>
www.webtide.com
Developer advice, services and support
from the Jetty & CometD experts.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 19 Jul 2012 13:39:15 +0900

> fully specify server opened channels just yet.
I think it's not too late that the client decides to spare odd/even channel
ID for server-initiated stream after getting agreement on use of
server-initiated stream on the opening handshake for the physical
connection (e.g. exchanging "Sec-WebSocket-Extensions: mux;
server-initiated").

Reserving odd/even channel ID from now makes sense if we won't (can't) make
a change on extension negotiation like this, but just add new multiplex
control block types to enable server-initiated stream feature (old mux
implementations ignore them and maybe send some block to tell
NOT_IMPLEMENTED error). But I believe that this kind of feature negotiation
should be done on physical connection opening handshake, not when receiving
a multiplex control block.