Re: [hybi] Multiplexing extension spec draft 03

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

I think it's OK to disallow control frames with a channel ID other than 0.
Since WS control frames apply to a physical channel,  I'm not sure they
should apply to mux logical channels too (it will always confuse
intermediaries that are not mux aware). We could actually create a single
mux command for delivering all types of logical channel control frames,
including custom opCodes that might be assigned in future. In such a case we
need a general purpose mux control command to move control frames of logical
channels with their opCode, RSV bits and payload. 

 

The more I think about it the fewer other options I see. A mux-aware
intermediary will have to forward close frames and their payload, while a
mux-unaware intermediary might kill the connection when encountering such a
frame. This means that the control frames of a logical channel need to be
enveloped into a mux command message, unless we figure out a better
solution.

 

With best regards,

Arman

 

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

 

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

Hello Takeshi,

 

Using both a DropChannel and a close frame to close a logical channel seems
like overkill.

The original aim of addition of DropChannel was only to provide a way to
terminate logical channel which is behaving abnormally by some command out
of that logical channel.

 

To make abstraction simple, I gave it a role to terminate a logical channel
normally, too. But I'm ok with getting normal close done by only one command
(one close frame, one DropChannel command, etc.)

Exchanging DropChannel control messages should be enough for mutual shutdown
of a logical channel. A more important issue is that if a close frame is
sent through an intermediary that does not understand the mux extension, the
intermediary may simply drop the physical channel / connection.

I understand your concern. Actually, IIRC it was one of the motivation to
introduce close frame that a close frame tells intermediaries the end of
session instead of unreliable TCP FIN so that they can release resource for
the session more quickly.

 

John's original proposal was adding a new framing onto WebSocket framing to
implement multiplexing. There was some discussion about this and some
suggested  reuse of opcode in base framing. See this thread for example
http://www.ietf.org/mail-archive/web/hybi/current/msg07240.html.

It's easy to imagine a frame compression intermediary that would simply stop
reading from the network connection once it encounters a close frame (as per
WS spec no data is expected to follow the close frame). So probably the
sending of a close frame should be avoided (i.e. prohibited) for logical
channels.

I'd like to disallow any control frame with channel ID != 0 and have
corresponding mux commands for each of them if we take this approach rather
than just converting close frame into DropChannel ad-hoc.

 

Also we need to give DropChannel some field to hold the information close
frame has (status and reason).