Re: [hybi] Multiplexing extension spec draft 03

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

Hello Takeshi,

 

Using both a DropChannel and a close frame to close a logical channel seems
like overkill. 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. 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.

 

With best regards,

Arman

 

 

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

 

The idea in my mind is that the DropChannel command works similar to TCP
FIN/RST when no mux is used. I.e., each logical channel still exchanges
close frames (with their channel ID in extension data portion) and uses
status code in them (e.g. CloseEvent's code attribute), and after handling
them, each side issues the DropChannel command as well as TCP shutdown.

 

So, there's no such problem with graceful shutdown for logical channels'
traffic. In terms of control traffic, we may receive some mux command for
logical channel X after sending DropChannel command for X, but for now we
can just ignore any of control commands safely:

- FlowControl X -> safe to ignore

- DropChannel X -> no problem. it's totally fine that both sides drop the
same channel at the same time.

- AddChannel X -> if we receive this, it just means the other peer is
misbehaving

 

That said, we can't distinguish this from invalid commands sent by broken
peers (e.g. logical channel Y never existed but received command for Y).
Maybe it's better to have endpoints respond to DropChannel as well as close
frame to sync active channel list.

 

Thanks
Takeshi



On Mon, Mar 19, 2012 at 23:37, Arman Djusupov <[e-mail]> wrote:

The procedure of closing the logical channel is not detailed enough. Closing
the logical channel should be performed in a way similar to closing the
websocket connection when no mux extension is used. We need a close control
frame to roundtrip in order to ensure the mutual agreement between the two
sides when a logical channel is closed. Currently the specification does not
require the side that receives a DropChannel control frame to reply to it
(unless I missed something), which does not ensure the graceful closure of
logical channels.

 

"When an endpoint received DropChannel, the endpoint MUST remove the logical
channel and the application instance that used the logical channel MUST
treat this as closure of underlying transport."
 
One side could be in the process of sending a message when it receives a
DropChannel frame, so it is important to ensure that the logical channel is
closed gracefully without dead channel frames left on the wire. The best way
to do it is to let the DropChannel frame roundtrip back to its sender. When
both sides have received the DropChannel frame they are in mutual agreement
to release the channel ID, being sure that no more frames with the same
channel ID are expected to arrive from the remote side.
 
With best regards,
Arman