wss.clients does in fact know about broken connections??

Created on 4 Jun 2020  Â·  8Comments  Â·  Source: websockets/ws

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.)

Most helpful comment

See https://github.com/websockets/ws/blob/c02a4b77c2b257336400c7aed9ca7c222d87c6ff/lib/websocket-server.js#L326

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.

All 8 comments

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.

See https://github.com/websockets/ws/blob/c02a4b77c2b257336400c7aed9ca7c222d87c6ff/lib/websocket-server.js#L326

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.

Was this page helpful?
0 / 5 - 0 ratings