Closed mehaase closed 3 years ago
I am receiving cases of hung CLOSE_WAIT as well.
I suspect this bug correlates to the test suite failures reported in #147
So... if I add await self._close_stream()
following the channel aclose()
in _close_web_socket()
, then the example code in this issue works, it fixes all the client and server autobahn failures, and unit tests pass.
But I don't know if this change is correct.
I found that _close_web_socket()
is called on a few paths, but the only one seems to matter for the example in this issue and autobahn tests is via _handle_close_connection_event()
.
Furthermore, corroborating the RFC cited in the original comment, the tests only seem to require closing the TCP stream on connection closed for the server case.
I'm wondering if this early return in WebSocketConnection aclose()
is correct:
Because if I disable that, then the remainder of the function includes a finally
with a close of the TCP stream, which is what we want.
(The fact that the issue doesn't come up with the trio-websocket client, while it does with asyncio and autobahn clients, implies that our client is cheating and closing down its end right after sending a CloseConnection event.)
The RFC says:
This doesn't always happen. I noticed this while testing a trio-websocket server with an asyncio websockets client. After doing the WebSocket closing handshake, the client times out after 10 seconds waiting for the server to close the connection.
The server code:
The client code:
And a relevant section of the client's logs:
This is tangled up with #90 a bit but is a bit more urgent for me personally because I'm now using a trio websocket server with an asyncio client.