How to check if a WS is in "closing state" (invalid access of closed uWS)

[Inateno]

Hello there,

We are working on a top-level implementation of uWebSockets for a server-side game-engine and we are facing a situation (using last version v16.4.0).

Sometimes, when making a "lobby" with several sockets involved, if multiple client disconnect at the same time it looks like we have conflicts on the "disconnect" implementation we made that call "ws.end".

I know it would be way preferable that the code never call 2 times "disconnect" at the same time but the thing is, if the client send "I'm leaving" (so the server will disconnect it) and leave at the same time, it ends pretty much the same.

As we are investigating on how to prevent this the best way even if a dev-team call it to much, the best would be to figure out a way to prevent server from crashing.

I could simply put a "try-catch" but I hate that and I prefer the "if" solution (or at least a promise solution).

Thanks (and btw thanks for the awesome job).

[ghost]

This is brought up in the user manual; WebSockets are valid from open event to close event. That exception you get, "Invalid access of closed uWS.WebSocket..." is not something you should try/catch - it's a hint that you are using the library wrong. Once you get the close event, you can no longer use the WebSocket whatsoever (it is dead).

This means if you have a data structure that holds sockets in a lobby you have to properly remove all references to the dead WebSocket from that data structure so that you don't access it by mistake.

There is no way to "check" if a WebSocket is dead or not, you have to properly make use the the open/close events to update whatever data structures you have.

Btw, if you're building a lobby you should make use of the pub/sub functions built-in to get that feature for free and with much better performance.

[Inateno]

Yeah, I'm using the close event to already clean the stuff out, that's the part I'm not sure why I have a redundancy of _ws but I'm gonna dig in then.

I also put flags to "destroyed" so my interface is broken somewhere lol.

Thanks for the hint.

[Inateno]

Just a up to show how it ended, could be useful for some folks maybe.

My lobby "destroy" function now take a setTimeout for each "force-disconnect".

And I have a flag security on the disconnect.close methods.
As the comments explain, I ends in a situation where I have a disconnect over an "already disconnected socket" because we want to wait the client to disconnect first, this avoid the error "Disconnected from server" or "Connection lost".

My stuff was good, just added this if (would be a poor fix without the "good practice" I know :D )

[ghost]

I really have no idea what you are doing but it sounds very wrong. You shouldn't have any setTimeout hacks or anything like that. It's really really simple; you have open and close and you may end or close the connection. The rest is handled for you.

[Inateno]

Ah lol no you don't get it, my first code screenshot is a "game-instance", when an instance is destroyed it is disconnecting sockets.
The thing is it's better if the client is disconnecting and not the server (this avoid the error "disconnected from server" as it is handled by the client).

But in case the client isn't sending the disconnect instruction, the server force the disconnection 250ms after.

Nothing wrong here, game logic.

The close/disconnect "home-made" functions are to prevent a dev doing mistakes with the socket and also being able to know which player instance has been disconnected.

Anyway, everything works fine since your first answer and my fix ^^

[ghost]

The server can disconnect with a message and code, so your client can differ between a graceful disconnect and a problematic disconnect. That way you don't need to introduce a bunch of JavaScript timeouts

[Inateno]

I tried that, message never end on client side.
Maybe I'm missing something ? (any code example, the doc isn't super clear about that).

[ghost]

Onclose is called with a CloseEvent holding code and reason:

https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent

Whatever you pass to ws.end(code, reason) server side ends up in that CloseEvent client side.

[Inateno]

Ok yeah I saw that there are some default codes like 1001 and 1006 but I tried custom stuff maybe I did it wrong.

Will try again this could indeed make things much more easier for me :)

[ghost]

Yes I think you are complicating things more than what you have to

[Inateno]

Ah honestly it's not that complex with what I sent, I just have to be careful when server disconnect someone for now, so it'll make future architectures easier, but now it's already setup it's fine x)

[cojmar]

https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent
4000–4999 |   | Available for use by applications.
So your disconnect code must be from 4000 to 4999 to work on client side.
Having a timeout that sends a disconnect event is just bad.
Now what u do there is even worst u have a loop and in loop u generate timeouts so is not just one time out is a bunch of them.
Maybe a better an optimal solution is with setInterval :

this.sockets_i_have_to_disconnect = [];
this.disconnect_interval = setInterval(()=>{
let ws;
while (ws = this.sockets_i_have_to_disconnect.shift()){
ws.disconnect()
}
},500);

this.players.forEach(pl => {
pl.ws.onDisconnect = () =>{
this.sockets_i_have_to_disconnect.push(pl.ws)
}
});

Also dunno exactly your logic but to close sockets when game ends doesn't look as strong logic, a better logic is to move them to another room a lobby something so they can start a new game, chat dunno.