Re: [hybi] Multiplexing extension spec draft 03

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

 

 

From: Takeshi Yoshino [mailto:[e-mail]] 
Sent: Tuesday, March 27, 2012 3:35 PM
To: Arman Djusupov
Cc: [e-mail]
Subject: Re: [hybi] Multiplexing extension spec draft 03

 

Hi,

 

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

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.

 

think we should and if there is an intermediary that messes up with channel
IDs or completely strips off the mux, it would be normal for such an
application to fail (so such an application would require that there is no
de-multiplexing intermediary in between). Using fixed channel IDs like
TCP/IP port numbers is optional, there are alternative ways to negotiate the
protocol used by the logical channel using the AddChannel request handshake.
But the general idea is that Yes the application layer should be permitted
to access a specific logical channel by ID, protocol or other criteria, at
least the specification should not require that logical channels are
completely abstracted from the application layer. 

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.

 

This is fine with me J

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.

 

Both options are OK with me.