search

facebookincubator / SocketRocket

A conforming Objective-C WebSocket client library.
Other
9.56k stars 2.01k forks source link

no close handshake #299

Closed jakobsa closed 8 years ago

jakobsa commented 9 years ago

I can't produce clean closes (callback calls). Not when close is client initiated and not when close is server initiated.

Here is my findings so far:

When calling close SR_CLOSING is set as the readyState. According to the close handshake protocol the server ACK's and sends Close OPCode in return. At this point (I strongly assume that) _innerPumpScanner needs to process the server sent close OPCode but can't since the check if (self.readyState >= SR_CLOSING) makes it return early.

Also Server initiated closes are not resulting in a clean shutdown.

In my project I need a reconnect mechanism. For that I need reliable information on what caused the connection to close. (Clean Shutdown, Error, Connection Interruption)

kommen commented 9 years ago

@jakobsa You might want to try the current master branch containing #294, see #268

linjianxiong commented 9 years ago

when the client call close or closeWithCode:reason，I have the same problem

jakobsa commented 9 years ago

I have looked into the code and the reason seems to be that a call to close changes the state to closing which in turn makes _handleFrameHeader and _innerPumpScanner return early.

RFC 6455 - 1.4. defines the Closing Handshake as non-normativ. That's why it's hard to say if this behavior is actually a bug.

It sends the close control frame correctly but doing a complete close handshake requires the webSocket to read data up until it has received the servers close response.

This again is optional: "[...]there is no guarantee that the endpoint that has already sent a Close frame will continue to process data.[...]" (specified in RFC 6455 - 5.5.1. Close)

Even if there are more bytes coming in on the socket (as indicated by the occurrence of the NSStreamEventHasBytesAvailable event) due to the early returns there is no further processing of the buffer and handling of control frames.

I think the delegates webSocket:didCloseWithCode:reason:wasClean: method suggests that the implementation can do a clean close (complete close handshake) which is the reason why I consider it a bug to not being able to do so.

jakobsa commented 9 years ago

300 fixes that issue for me

nlutsenko commented 8 years ago

Closing per no activity as well as it looks like it's fixed. Please re-open/comment or open a new issue if you guys still experience any problems.