Re: [hybi] Multiplexing extension spec draft 03

["Arman Djusupov" <[e-mail]>]

Hello Takeshi,

 

We are not implementing mux for providing video streams specifically, but
for general purpose mux support. I see the mux extension being useful not
only to the browser, but certainly to other types of software too which need
multiple channels in a single connection. It is applicable to all cases when
the client has to reduce the number of concurrent connections to the server
pool.

 

Client-mux intermediary-servers is just one specific use case, once which is
required by browsers. Consider for example a MMO game engine that also uses
mux between the client application and server poo, where the mux
intermediary does not simply bundle and unbundle channels but is designed
specifically for the game requirements and has specific logic on how to
forward each channel based on the channel ID or other criteria. We can
assume that in such cases an incompatible intermediary is not expected to
occur on the wire between the client and server. So the specification is not
required to prohibit the bundling/unbundling of the logical channel or the
change of channel ID.

 

BTW it still unclear which of the communicating sides assigns a channel ID
when an AddChannel request is sent. Since the Objective Channel ID can be
sent both ways, what should be the Objective Channel ID for an AddChannel
request message?

 

It's ok with me if the channel ID cannot be assigned by the client side,
since the application may identify the type of the channel by the first
message sent through the channel. This may cause an extra roundtrip, but it
is not a big deal if we implement some way of opening multiple logical
connections at once.

 

With best regards,

Arman

 

 

From: Takeshi Yoshino [mailto:[e-mail]] 
Sent: Friday, March 23, 2012 8:58 PM
To: Arman Djusupov
Cc: [e-mail]
Subject: Re: [hybi] Multiplexing extension spec draft 03

 

Hello Arman,

 

On Fri, Mar 23, 2012 at 18:38, Arman Djusupov <[e-mail]> wrote:

Currently the specification does not make it clear which side assigns a
channel ID when an AddChannel control message is sent. I think this could be
made flexible; for example if Objective Channel ID is set to 0 then this
means that the client prefers the server to select the channel ID, if it is
greater than 1 then the client requests a specific channel ID.

 

Giving the client the option to select the channel ID can facilitate the use
of application-specific channel IDs, where the predefined logical channel ID
is reserved for a specific role, e.g. 1 - Video channel, 2 - Voice channel,
3 - Control channel, 4 - Subtitles channel (optional).

Some people were discussing intermediaries with mux capacity which
bundle/unbundle logical channels. Here, your proposal seems to try to use
channel ID values as service identifier (like port number of TCP/UDP). It
doesn't go together with such intermediaries. To make this work, we need to
ensure in the spec that channel ID is preserved between endpoints.

 

IMO, channel IDs should be hidden to application level and resource or
Sec-WebSocket-Protocol should be used for such mapping instead as well as
WebSocket w/o mux.

 

Are you also going to use mux to provide multiple channels (e.g. video,
voice, ...) but keep them grouped for one session (e.g. video conference
session consists of them)? If so, we need to ensure in the spec that logical
channels must not be unbundled into separate physical channels.

 

These new restrictions enables the usage as you described, but also
complicates the spec. For me as one of browser developer, they're
unnecessary. The current mux extension's goal is to provide logical
equivalent of normal WebSocket connections in one TCP connection. Your
proposal is beyond that. I'd like to get more opinions on these points.

 

It is also worth mentioning in the spec that the protocol specified by the
Sec-WebSocket-Protocol header MAY define a default set of logical channels
that are considered as being implicitly established when the mux extension
is agreed. Some protocols, as mentioned above, may require a fixed set of
channels with predefined IDs. Negotiating the same set of channel IDs using
an AddChannel request<->response every time a new connection is established
would not be efficient.

Providing a way to open multiple logical connections at once is interesting.
As I said above, basically I prefer to realizing it by adding some way to
issue AddChannel commands (different resources may be used to tell which
service each logical channel wants to access) on handshake.

 

How about this, for example?

 

C->S Sec-WebSocket-Extensions: mux; preopen="vc-video, vc-voice, vc-control,
vc-subtitle"

(each comma-separated element in preopen parameter's value means value of
Sec-WebSocket-Protocol)

 

S->C Sec-WebSocket-Extensions: mux; preopen="vc-video=1, vc-voice=2,
vc-control=3, vc-subtitle=4"

and the server sends back 4 AddChannel responses.

 

We don't have to pay additional RTT though change on request headers is
limited to Sec-WebSocket-Protocol.

 

We may also add some grouping annotation.

 

(OT. I don't want core specs to say that Sec-WebSocket-Protocol has
capability to change WebSocket protocol's behavior. Such modification should
be made using extension framework. Also, for now, Sec-WebSocket-Protocol is
an attribute for each logical channel. I'm disinclined to invite headers
other than Sec-WebSocket-Extensions to determine physical channel (mux
extension)'s behavior.)

It should be permitted for the "protocol" to imply a default set of channels
that don't need to be negotiated (at least this should not be against the
specification).

 

I don't object to make it able to define/use such preset. Maybe useful.

As an example, when Sec-WebSocket-Protocol set to "smart-playback" would
mean then once the mux is negotiated the following logical channels are
considered already established: 1 - Video, 2 - Voice, 3 - Control,  4 -
Subtitles.

 

I think this would make the specification much more versatile.