Every one second, I simply do this:
console.log("count of wss.clients: " + wss.clients.size);
I connect say four clients, it correctly shows four.
I break one of the clients, I just kill that app on the PC.
In fact it does now show three.
How can this be? wss.clients seems to "know" that there has been a drop.
But wss.on('close' is not called.
Note that I am not using a ping system. (As in the example _"How to detect and close broken connections?".)
(Indeed if I try to use a ping system it doesn't work at all! Because, the broken connection simply no longer shows up in wss.clients !)
wss.clients seems to "know" that there has been a drop...
how can that be?
(If so - surely something is called on wss when that happens?? What is it? 'close' is not called.)
Every time a WebSocket is closed it is removed from the wss.clients set.
The 'close' event on the server is a completely unrelated event that is emitted when the WebSocket server is closed. See https://github.com/websockets/ws/blob/master/doc/ws.md#event-close and https://nodejs.org/api/http.html#http_event_close.
Thank you,
"Every time a WebSocket is closed it is removed from the wss.clients set."
Ah - but - what if the connection is broken ?
Is it still true?
It seems to be true, based on my tests??
thanks again ...
Yes, that is true.
When the 'close' event is emitted on the WebSocket it is removed from the clients set regardless of how the connection was closed (forcibly with ws.terminate() after a missing ping, or naturally if the closure/broken state is detected). Hope it makes sense.
AHHHHHH
Thank you so much!
The only thing I do not understand. Why would anyone bother with a ping system?
(Such as the example _"How to detect and close broken connections?" on the home page.)
There seems to be no reason to use a ping heartbeat: in all cases, the disconnection (broken, etc) is "seen" correctly.
There seems to be no case in which a ping system is needed?
thanks ..
There seems to be no case in which a ping system is needed?
It may be hard to reproduce locally but "zombie" connections are a common problem in production.
@lpinca , thanks again,
I understand.
But, we are testing w/ a number of separate servers and real distributed clients (both Mac builds and Windows builds) - and I can't find anything which is "missed" by ws.on#close !
(Which is great !!!!!! :) )
• Based on what you have said, I will leave in the anti-zombie heartbeat code
• (ie, just as in the example _"How to detect and close broken connections?" on the home page.
As you have said above..:
If I use .terminate in the case of a "heartbeat disconnect", in fact, that does indeed result in ws.on#close being called.
So that is great news.
In all cases, the code in ws.on#close will be called. (Even in the case of a "zombie detected by the heartbeat ping".)
That is great news.
Thanks! :) :)
Closing as answered.
Most helpful comment
See https://github.com/websockets/ws/blob/c02a4b77c2b257336400c7aed9ca7c222d87c6ff/lib/websocket-server.js#L326
When the
'close'event is emitted on theWebSocketit is removed from theclientsset regardless of how the connection was closed (forcibly withws.terminate()after a missing ping, or naturally if the closure/broken state is detected). Hope it makes sense.