Re: [hybi] Clarify the role of closing handshake

[[e-mail]]

Hi,

> - Peer B assumes that no more data is coming from peer A when B 
> receives closing 
> initiation from A.

I agree - much simpler

As a side note, the other option (b) requires one extra state to wait 
for an acknowledgement upon sending Close frame. I was wondering who 
would be responsible for managing lifetime of the extra state, and 
yet it would be complicated.

Here is my comments to Takeshi's proposal in: 
http://www.ietf.org/mail-archive/web/hybi/current/msg06285.html 

> 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.

Looks good.

> 
> 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.>

I do not see the usefulness of the normal/abnormal at app level either.
But it may be helpful for counting such events to monitor for admin 
purposes or for trouble shooting.

> 
> 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>

I am ok this to be as is (besides '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

As long as we cannot rule out the case where there may be incoming
data in the TCP buffer at the time of Close frame send, the endpoint
should not close socket right away, otherwise TCP-RST is sent to the 
peer, and the Close frame that has just sent may not reach the 
remote app. So, WebSocket layer needs to take care of this cleanup
sequence:

[App]          [WS-layer]     [TCP socket]
  |    close()     |               |<--- data
  +--------------->|  send(Close)  |<--- data
  |<- - - - - - - -|-------------->|----> FIN
  |                |  * recv()     |<--- data
  |                |till EOS(0 rtn)|
  |                |-------------->|
  |                |    close(|    |
  |                |-------------->x
  |                |

This is an implementation issue, but worth mentioning.

> ...  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.

Sounds good.


Best.
--
Yutaka Takeda - US R&D Sony Computer Entertainment, Inc.
Office: 650 655 7484   Fax: [phone]


[e-mail] wrote on 02/11/2011 09:32:53 AM:

> 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. 
> 
> Hi Yutaka
> 
> People seems agree that this can be handled at application level,
> (the fact that you also say that it is difficult to know how important 
that is
> from an application's prospective seem that you agree on that, but then
> the rest of your message confuse me, can you clarify what you would 
like?)
> 
> People seems agree, withing this thread, that at protocol level it 
> is enough to go for the simplest scenario:
> 
> - Peer B assumes that no more data is coming from peer A when B 
> receives closing 
> initiation from A.
> 
> please read the text suggested from Takeshi in 
> http://www.ietf.org/mail-archive/web/hybi/current/msg06285.html
> and check if it works for you
> 
> cheers
> /Sal

> -- 
> Salvatore Loreto
> www.sloreto.com
> 
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi