Re: [hybi] Multiplexing extension spec draft 03

[Takeshi Yoshino <[e-mail]>]

Hi,

On Tue, Mar 27, 2012 at 12:41, Arman Djusupov <[e-mail]> wrote:

> 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.
>
Yes, that's why I didn't object to use of mux ID but just showed concern
about intermediaries' bundle/unbundle.

>  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.****
>
> **
>
So, ... your point is that we should clarify which side assigns a channel
ID, and then you can divert WebSocket for such an application which gives
special meaning for each channel ID. Right?

My question is whether you're suggesting that we explicitly mention/allow
the use of channel IDs from application level or not.

> **
>
> 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?****
>
> **
>
Sorry. Yes, I'll do this clarification. My understanding is that the
AddChannel request specifies the channel ID for the new logical channel by
putting the ID in the Objective Channel ID part.


> **
>
> 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
>
We may allow clients to send some value meaning "undefined" in the
Objective Channel ID part to get ID assigned by the server with AddChannel
response. For now, I'm not going to put this in the spec because of
additional complexity.