Subject: [hybi] Multiplexing - closing a logical channel

From: Zhong Yu <[email-masked]>
Date: Thu, 14 Mar 2013 20:34:39 -0500

Hi,

A vanilla WebSocket connection can be half-closed, i.e.

    X sends a close frame to Y,
    then continues to read frames from Y.

    Y receives a close frame from X,
    but continues to send data frames to X.

However the multiplexing draft seems to require that a logical channel
cannot do that - a logical channel is either active or inactive, as
soon as it becomes inactive, by sending or receiving DropChannel, the
channel cannot be used further, on either direction.

If my understanding is correct, then I wonder what's the reason for
this behavior? Why don't we allow close frames exchanged on a logical
channel so that the closing process of a logical channel is consistent
with that of a vanilla WebSocket connection?

Thanks,
Zhong Yu

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 15 Mar 2013 17:50:40 +0900

Hi

> channel cannot be used further, on either direction.

Sending a DropChannel corresponds to TCP closure ("Close the WebSocket
Connection" operation in RFC 6455).

WebSocket endpoints can make their connections half-closed even on mux.

See
http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-09#section-19
.

> with that of a vanilla WebSocket connection?

Thanks
Takeshi

---

From: Zhong Yu <[email-masked]>
Date: Fri, 15 Mar 2013 10:42:19 -0500

Got it, thanks.

Another question,
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17#section-5.5.1

5.5.1. Close
   The application MUST NOT send any more data frames after sending a
   close frame.

doe it imply that more control frames may be sent after a close frame?

Zhong Yu

On Fri, Mar 15, 2013 at 3:50 AM, Takeshi Yoshino <[email-masked]> wrote:
> http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-09#section-19.
>
>>

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 18 Mar 2013 15:14:54 +0900

I don't remember if it was intentionally made to be "data ...".

But,

One of the reason why we exchange close frames is that
- some TCP stacks send an RST when a socket is closed without fully reading
received data from it
- some TCP stacks throw away received data when received an RST
- so, to close a socket without impeding the peer from reading all of
successfully received data, an endpoint needs to know that there's no data
left in its socket

If TCP FIN (EoF) works well, we can use it. But it's not always available
and reliable. So, closing frame was introduced as a reliable method to
signal the end of data on WebSocket layer.

To realize this goal, control frames also may not be sent.