Is there any way at all to send data between recieving a close frame and sending the reply close frame?

[Scripter17]

I'm making a thing that takes lines of tasks in Message::Text and returns lines of results in Message::Text.

For performance, I want to send response lines in fewer messages by accumulating them in a buffer and sending that buffer on some interval. This makes my code anywhere from 5 to 7 times faster.

Basically within a rocket_ws::WebSocket::channel (which uses tungstenite internally) I have

1. A tokio::spawn'd future that repeatedly waits 1ms, gets all available results, and if there's any to return, returns them all at once.
2. A loop that repeatedly gets the next message, then for each line of text parses the task, does it, and sends it over to the responding thread.

The problem is that the instant I read a Message::Close from the stream it is impossible to send any further responses because tungstenite immediately closes the connection with no consideration that I might actually have shit to do before closing the connection.

If I do it without the responding future, sending all the results from each message before getting the next message, it reliably sends all responses at the cost of taking 5 to 7 times as long.

If I were to manually reimplement the relevant parts of rocket_ws on top of tungstenite, is there any way at all for me to get the 5-7x performance boost without having a race condition forced upon me? I don't care how low level I have to go I just want this over with.

[agalakhov]

This is what RFC 6455 says:

If an endpoint receives a Close frame and did not previously send a
Close frame, the endpoint MUST send a Close frame in response. (When
sending a Close frame in response, the endpoint typically echos the
status code it received.) It SHOULD do so as soon as practical. An
endpoint MAY delay sending a Close frame until its current message is
sent (for instance, if the majority of a fragmented message is
already sent, an endpoint MAY send the remaining fragments before
sending a Close frame). However, there is no guarantee that the
endpoint that has already sent a Close frame will continue to process
data.

That's why we process the closing handshake immediately. There is no (documented) way to send anything after receiving a Close since the RFC explicitly states "there is no guarantee that [it will work]" and we don't want to introduce any potential non-working features.

[Scripter17]

So in the current slow implementation where socat sends a close frame after sending the file in like 0.1 seconds and Rocket only sends a close frame back after it finishes and returns all the tasks, that's somehow compliant, but doing the same thing manually isn't?

I get that letting me do this manually allows me to accidentally not comply with the RFC and I absolutely agree that the current auto-handling of Ping, Pong, and Close should be the default, but manually handling Close lets me intentionally get a 5-7x performance boost.

Edit: Either this is valid, or it is invalid. It is not both.

(From websocat using the log:ws://... thing on the server with a temporary (!) fix to appease tungstenite)

WRITE 13 "https://x.com"
WRITE 13 "https://x.com"
WRITE 13 "https://x.com"
WRITE 13 "https://x.com"
WRITE 13 "https://x.com"
WRITE 0 ""
READ 14 "https://x.com/"
https://x.com/
READ 14 "https://x.com/"
https://x.com/
READ 14 "https://x.com/"
https://x.com/
READ 14 "https://x.com/"
https://x.com/
READ 14 "https://x.com/"
https://x.com/
READ 0 ""

[daniel-abramov]

Let me explain: the RFC does not explicitly prohibit a peer from sending a data frame after receiving a close frame. What it says (simplified) is that:

• The peer who sent the close frame must not send any data frames.
• The peer who received the close frame must reply with a close frame and do so as soon as possible.
• Sending data frames after receiving the close frame (but before replying with the close frame) is not prohibited, but there is no guarantee that the other side (the peer who sent the close frame / initiated the close handshake) will process this data.

What it practically means is that you can send data frames before replying to a close frame with your close frame if you know that the other side processes them while waiting for the close confirmation (i.e., if you control both the server and the client and you know that it's the case).

Now to the tungstenite part: the current behavior is that we automatically reply to ping, and close messages. That's the default behavior that we decided to implement since we wanted it to be as high-level and easy-to-use as possible (and most usages of tungstenite stem from integrating tokio-tungstenite into other web frameworks). Unfortunately, we do not support turning off automatic replies for ping and close frames at the moment (turning off this behavior in a forked version is a pretty simple change, though).

Does this clarify things a bit?

[Scripter17]

That clarified the theoretical side quite nicely, thank you.

The fact remains that I am to choose between a 5-7x speed up (that in the process of writing this I realized probably isn't even real) and not having a race condition.

For my actual use case, which is getting URLs from a userscript on a webpage, cleaning them, and returning the cleaned URLs to that userscript to put back in the page, the race condition doesn't matter. The socket ends when the user is leaving the page, at which point the user is very unlikely to click on any URL that wasn't cleaned before it was even on screen.

My gripe, which ideally I have written to not come off as "I hate you personally" (but let's be honest, it did), is mainly that I am given access to valid behavior that I cannot in any way recreate manually without forking Tungstenite or reimplementing WebSockets. I have to magically know that the next message is a Close frame and then only handle it when I am done. A peek method would fix this, which is just embarrassing.

If a client disconnects the second they say they're done that is their problem. If I immediately say I have nothing left to send I am just incorrect, and any client that would want remaining results (such as anyone using websocat or, in my opinion, any sensibly designed WebSocket client) will be left with an incomplete list.

Again, technically not a problem for me because URL Cleaner has other frontends (including literally just a plain HTTP one in the same server) that aren't tuned for use in a userscript, but it's still maddening to have magic I can't turn off.

I quite like when APIs let me reach valid states, even if I have to enable "I'm not stupid" mode.

[Scripter17]

Actually, this will be an issue if I ever find a way to multithread this frontend, because then the speedup will be real and the default behaviour of not having a race condition being impossible to replicate will actually cause problems when using real WebSocket clients that exist.

Still niche and questionable, but only because I have the luxury of not needing to use WebSockets.

[Scripter17]

I'd like to apologize for my tone throughout this issue. As much as this personally annoys me and as much as I have tried to show the annoyance in somewhat not rude ways I am definitely coming off a lot angrier than I should to people with much more important concerns than letting me do library/protocol level UB for situations even I admit are questionable and performance even I doubt the existence of.

I maintain that Tungstenite should allow an "I'm not stupid" mode for people who do genuinely need this for compatibility or whatever, but I let myself pretend I was coming off as firm and direct when I was just coming off as an ass, and that's not a good way to request a feature.

If you are willing to accept such a feature, I am willing to have a go at adding fields to WebSocketConfig for disabling auto-pong and auto-confirm-close (with both defaulting to enabled). I probably won't do a great job on my first try and it'll probably take a while to even finish that first try, but it'd much more productive than what I've been doing above.

[daniel-abramov]

W.r.t. your use case: If I got it somewhat right, you developed a service that runs a websocket server that runs an RPC-like protocol that accepts requests ('tasks') and replies with 'results' once the tasks are completed. For the sake of optimization, you batch the processed replies. From what I read, you want to use the client's close frame as a prompt to "force flush" the completed tasks message in your protocol. Some of these clients, if I get it right, run in a browser environment, which means you don't have complete control over their websocket implementation (the browser can initiate a websocket close when the tab is closed, the browser is closed, etc.);

Note that it's generally a poor protocol design to rely on the WebSocket close frame as the primary (or only) signal to force-flush batched responses of the RPC protocol. I know it might be enticing at first, but using the internal peculiarities of the transfer protocol to alter/define the behavior of the higher-level protocol has significant downsides and would cause more harm/confusion than use in the long run. It's very uncommon for the peer to start closing the connection while expecting the other side to treat it as a signal to deliver more data.

W.r.t. tungstenite: Yes, giving the user the full control of the protocol compliance may be an advantage for the low-level libraries, and it's something that I considered adding at some point (I'd prefer adding these after completing a larger refactoring, see the last paragraph; in fact we do have two very similar issues open related to the auto-pong). Note that our current behavior (auto-pong, auto-close, etc) is pretty common in WebSocket libraries (even outside of the Rust ecosystem). However, if the particular behavior is essential for your use case and you want to get it done as quickly as possible, you may consider using a lower-level WebSocket library that transfers the protocol compliance part of the protocol to the user, e.g., crates like fastwebsockets might be a better fit for your use case! Unfortunately, it's not easy to design a library that fits everyone's use case equally well.

Disabling auto-close and auto-pong is not complicated, but this particular part of the implementation is already quite convoluted in my opinion. It would also need careful updates across the documentation, which mentions this behavior in multiple places. Also, if you're using Rocket Websockets, you'd probably also need to wait until the aforementioned changes propagate to the upstream crates (Rocket Websockets doesn't update its dependencies often, from what I can tell).

Hope this helps!

[Scripter17]

In the on chance I don't get around to this and/or can't figure it out, would I be allowed to add a bounty (probably about $30 usd) to this?

If yes then consider the bounty active immediately.