Socket should flush before closing #405
Comments
TroyKomodo
added a commit
to SevenTV/SevenTV
that referenced
this issue
Jan 31, 2024
Fix sending a close frame on websocket disconnect, bug was found due to dankchat's websocket library being very strict with closing frames. Upstream bug report snapview/tungstenite-rs#405 Tungstenite does not flush the frame buffer on close, so when it echo's back a close to the client it does not send that close unless we explicitly call flush on the buffer.
|
If I got you right, it sounds like a bug in a user code (incorrect usage) rather than in a library, because AFAIR the Autobahn suite does have a test that specifically checks this behavior. Autobahn tests are part of our CI pipeline. There is one specific usage scenario that would result in the behavior that you describe:
If this is the case, you must ensure that you're reading frames until the WebSocket connection is closed, not until you receive a close frame, otherwise, you don't give tungstenite a chance to flush the buffer. If this is not the case, could you provide a simple example that demonstrates/reproduces the bug? |
TroyKomodo
added a commit
to SevenTV/SevenTV
that referenced
this issue
Feb 2, 2024
Implements the event-api from https://github.com/SevenTV/eventapi in Rust. This implementation improves memory usage by 8x and CPU usage by 4x. Taking bytes per connection from around 300kb -> 40kb and CPU usage from 40 cores down to 10. This aims to be a 1:1 implementation of the existing event-api with improvements and optimizations around memory and cpu usage. With very few minor changes from the initial implementation. Notably: - Subscriptions cannot have a TTL. - Subscriptions which were automatically subscribed to get unsubscribed after a few minutes - Hash Deduping does not dedupe for the entire lifetime of the connection, but rather for the next 255 events. - Path subscriptions must be URL encoded values. - Added header subscriptions, (JSON array of Subscriptions). - Path subscriptions work on WebSockets. - Added query parameter subscription, (JSON array of Subscriptions). * bug: websocket close frame Fix sending a close frame on websocket disconnect, bug was found due to dankchat's websocket library being very strict with closing frames. Upstream bug report snapview/tungstenite-rs#405 Tungstenite does not flush the frame buffer on close, so when it echo's back a close to the client it does not send that close unless we explicitly call flush on the buffer.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I noticed some strange behavior in the way closes are handled when we are the server and a client initiates a close.
The server responds with a close frame, however this close frame is not sent unless we call flush one more time on the socket.
I think it should be the library's responsibility to flush the socket when a close frame is sent internally by the library.
No flush call
Explicit flush call
The text was updated successfully, but these errors were encountered: