How to allow reconnects to a websocket after client disconnect?

[faassen]

I'm trying to figure out how to recover from disconnections from a websocket by the client. I have browser client that listens to incoming messages and can send them. I want to be able to close that client or reload it and then connect to the websocket again afterward and start receiving messages again.

But right now in my websocket handler I just bail out of the loop:

    loop {
        if let Some(value) = world_info_rx.lock().await.recv().await {
            let json = serde_json::to_string(&value).unwrap();

            if sender.send(Message::Text(json)).await.is_err() {
                println!("client disconnected");
                return;
            }
        }
    }

Removing the return doesn't work.

How do I allow the client to connect to this socket again, or establish a new websocket on the same port? Any pointers in the right direction?

[davidpdrsn]

I think you have to give the client some id that they send when making another websocket upgrade request, perhaps stored in a cookie. Then you can identify the client and know that you've heard from them before.

[faassen]

I think my question is more fundamental than that - I am not concerned with a persistent client connection so much as to allow any client to connect after the first one has been disconnected.

You talk about making another websocket upgrade request, but how do I do that?

Or perhaps something else is wrong and upgrade requests are happening but somehow failing? I will investigate this in a smaller sandbox to see whether I can replicate this behavior.

[davidpdrsn]

I think my question is more fundamental than that - I am not concerned with a persistent client connection so much as to allow any client to connect after the first one has been disconnected.

I mean you asked how to do reconnects 😅 since http is stateless you have to identify a client so know if they've been connected before. It's not about persisting the connections.

You talk about making another websocket upgrade request, but how do I do that?

Use WebSocketUpgrade like you're probably doing already.

[faassen]

My apologies for my vague question! For the purposes of this question clients have no state but only receive a continuous stream of new information through the web socket. But in my application a refresh of the browser would never reestablish any websocket after the initial one has been disconnected for some reason that I need to explore further. I thought this was inherent to websockets in axum but I was mistaken.

In a smaller sample application the websocket does get fully reconnected after a reload of the page (and thus a reload of the handler that upgrades to a websocket). So it appears something else is going on that breaks this in my application. I don't understand what yet, but I'll explore further.

Thank you for your help!

[faassen]

I have already learned from my testbed application that I should have used a broadcast channel and not an mpsc to talk to the websocket, otherwise a reload will only result in half the messages being received as messages are still also sent to the old client. So there are fundamental things wrong with the architecture of my larger application and I'm going to try to change it.

[davidpdrsn]

But in my application a refresh of the browser would never reestablish any websocket after the initial one has been disconnected for some reason that I need to explore further.

Yeah that sounds like a bug in your JavaScript code.

I thought this was inherent to websockets in axum but I was mistaken.

There is no automatic reconnect for WebSockets in the standard so there isn't a framework way to handle this and you gotta do it yourself.

[faassen]

There was no bug in my JS code, FYI.

It was a problem with the way I was using channels on the backend. Because I was using a mpsc channel to send information from my main simulation loop to the websocket server, information somehow got lost after the first client disconnect. Turning that channel into a broadcast channel resolved the issue - as a result information would also be sent to new clients (or multiple clients). It also made the code simpler; I can now share the broadcast Sender through a layer to the websocket and then subscribe to this. This doesn't require a mutex unlike the previous mpsc channel receiver I was passing in.

[faassen]

And the use of broadcast instead of mpsc seems to have resolved the problem!