Re: [hybi] Clarify the role of closing handshake

[[e-mail]]

Hi,

Joining this thread from another one in reply to Takeshi's message. Let me 
try to through my
thoughts...

> > o Section 4.5.1 - Close handshake 
> > 
> > It is no clear to me what 0x43 and 0x53 are trying to achieve. In 
> > TCP, there is FIN with no 
> > details of why/who is closing for graceful shutdown. 
> 
> Actually, it's not intended to indicate who's closing, but to make 
> sure what the close frame really means, i.e. it's close initiation 
> or close acknowledgement. Using an analogy of TCP, close S from 
> server is FIN, and close S from client is ACK for server's FIN.
> 
> Without this, each peer cannot know
> - the other peer just initiated close
> or
> - the other peer received close frame and acknowledged it
> 
> Imagine both peers send out close initiation at approximately same 
> time. They looks like acknowledgement but are not.
> 
> Once we can perfectly distinguish initiation and acknowledgement as 
> described above, we can assume "If A received close acknowledgement 
> from B, B has received all the data sent from A before close 
successfully".
> 
> If you have any idea about the usefulness of this closing handshake 
> design, please come to the thread "Clarify the role of closing 
> handshake" and speak out. We're discussing it now.

The current -05 as is seems good to me. Now I think it would be good to 
have 1-byte body
0x43 and 0x53, if it is important to know whether all data sent 
successfully reached the peer.
I just do not know how import that is from application's perspective.

I agree, if simultaneous Close occurs, then both ends cannot be sure if 
all the data is received
by the other peer.

Stepping back a bit, if we could assume that client always initiate Close 
in normal operation, 
then Client can tell, on receipt of Close with 0x53 after sending Close 
0x43, that something 
happened at the server. (e.g. cannot retain persistent connection due to 
excessive load, 
or some kind of failover operation at server side).  In such case, client 
should assume that 
not all data may have not reached the server, and take necessary action if 
that is important 
for the client application. As being discussed in this thread, the server 
could send some 
reason code, but I am not so sure if  that helps any, and I'm leaning 
toward more on not 
revealing any details of the situation for security reasons.

At TCP stack level, it think it is a good practice to have client initiate 
TCP-FIN always
(shutdown(socket, SHUT_WR)) after sending Close frame where possible. This 
can 
minimize the number of TCP control block in kernel memory sitting and 
waiting in either 
FIN_WAIT_1/2 or TIME_WAIT state, which could cause server resource 
exhaustion 
unexpectedly. 

After calling shutdown(soc, SHUT_WR), you can still read data from the 
peer to 
receive remaining data and lastly Close frame to close websocket 
_cleanly_.

- Yutaka





Takeshi Yoshino <[e-mail]> 
Sent by: [e-mail]
02/10/2011 11:18 AM

To
Greg Wilkins <[e-mail]>
cc
"[e-mail]" <[e-mail]>, Gabriel Montenegro 
<[e-mail]>
Subject
Re: [hybi] Clarify the role of closing handshake






Gabriel's idea is even simple. I don't object to that. I see the benefit 
of Greg's idea, too.

A while back, Yuta listed error cases can happen during frame processing, 
and suggested we define how we handle them. Maybe we would use abnormal 
close frame for them.
http://www.ietf.org/mail-archive/web/hybi/current/msg05131.html

I think abnormal close frame should indicate only protocol level error 
(frame parsing error, too large message, etc.). Any error inside 
application can be exchanged on application level. So we don't have to 
extend close() interface.

CloseEvent interface should be changed. _cleanly_ must be re-defined. We 
would define three type of close, _normal close_, _abnormal close_, 
_underlying channel terminated_, and replace "wasClean" with, say, 
"reason" or something. I'm not sure if we should invoke error event, too. 
I personally think it's redundant.

Then,
- close() called on WebSocket object -> send normal close frame -> 
"normal" close event regardless of whatever happen
- any protocol level error happened on client side and sent abnormal close 
frame -> "abnormal" close event
- received normal close frame -> "normal" close event
- received abnormal close frame -> "abnormal" close event
- underlying channel is closed without receiving close frame -> 
"underlying channel terminated" close event

I think this modification on CloseEvent doesn't violate the security model 
we now have to prevent WebSocket from being abused for port scanner. 
Abnormal close is just a new variant of closure information explicitly 
sent from the server. Thoughts?

So, by putting them together, like this?

----

4.5.1.  Close

The Close message contains an opcode of 0x01.

The Close message contains a body that is a single byte in length.  This 
byte carrys the reason for the close.  For normal close, the body MUST be 
a 0x00. For abnormal close, the body MUST be a 0x01.
 
The websocket is considered fully closed when an endpoint has either sent 
or received a Close message, or when the underlying channel is closed.

The application MUST NOT send any more data messages after sent or 
received a Close message.

7.1.1.  Client-initiated closure

<I'm not sure how much it's useful to have client send normal/abnormal. 
Server cannot retry by itself so, it's not the case Greg explained. But 
maybe we can just add it as well as server.>

7.1.2.  Server-initiated closure

<No change on *abort WebSocket connection* during opening handshake>

Certain algorithms require or recommend that the server *abort2 
the WebSocket connection* after WebSocket connection is established.  To 
do so, the server must send a Close message with a single byte body 0x01 
meaning abnormal closure and close the WebSocket connection.

<We need some verb to replace abort2>

7.2.  Normal closure of connections

To *close the WebSocket connection*, the user agent MUST send a Close 
control frame with a single byte body 0x00 meaning normal closure, as 
described in Section 4.5.1.  Once an endpoint has sent or received an 
Close control frame, that endpoint must close the TCP ...  If the 
connection was closed after the client sent or received normal close 
frame, then it's called _normal close_. If the connection was closed after 
the client send or received abnormal close frame, then it's called 
_abnormal close_. Otherwise, it's called _underlying connection 
terminated_.

The user agent can distinguish protocol failure notified by abnormal close 
frame from disconnection caused by network or intermediary to allow the 
application to determine if it should retry connection or not.

...

On Thu, Feb 10, 2011 at 18:44, Greg Wilkins <[e-mail]> wrote:
On 10 February 2011 20:25, Gabriel Montenegro
<[e-mail]> wrote:
> I think your simple reason would be enough (either normal or abnormal 
close for now).

cool

> To be clear: you're not arguing against the simplified semantics of 
considering the websocket closed (no further data or control) upon either 
sending or receiving a Close message, correct?

I'm not arguing either way.  I can see the benefits of half close and
flush through, but also the complexities, so I'm happy to follow herd
on this one.

cheers


>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
Greg
>> Wilkins
>> Sent: Wednesday, February 09, 2011 17:04
>> To: Takeshi Yoshino
>> Cc: [e-mail]
>> Subject: Re: [hybi] Clarify the role of closing handshake
>>
>> One of the other aims of the closing handshake was to better identify 
error
>> condition, so as to prevent a client repeating unacceptable operations.
>>
>> For example, if a client sends a frame that is too large for the server 
to handle,
>> the server needs to indicate that an error condition has occurred.  If 
the
>> connection is closed (orderly or otherwise) , then the client might 
assume that it
>> was an idle shutdown or transient condition on the server and thus open 
a new
>> connection and continue to send over large frames.
>>
>>
>> Currently -05 says:
>>
>> 7.1.2.  Server-initiated closure
>>    Certain algorithms require or recommend that the server *abort the
>>    WebSocket connection* during the opening handshake.  To do so, the
>>    server must simply close the WebSocket connection.
>>
>>
>> the problem with this is that for a client such a close of the 
websocket
>> connection cannot be distinguished from a
>> network/intermediary failure.   I think that typically an aborted
>> connection should not be retried, but a network/intermediary failure 
should be -
>> so it would be good to be able to signal to the client the difference.
>>
>> Thus I'd like to suggest that the close handshake carry a single byte 
of reason for
>> the close.
>> I think it would be sufficient to define just:
>>
>>   0x00 Normal close
>>   0x01 Abnormal close
>>
>> But I could see an argument for something a little richer:
>>
>>  0x00 Idle close
>>  0x01 close
>>  0x02 abnormal close
>>
>> but I concede that the danger here is trying to define too many close 
states
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
>
>
_______________________________________________
hybi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hybi