-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
new public method setKeepAlive for WebSocket #459
Comments
It seems http://stackoverflow.com/questions/23238319/websockets-ping-pong-why-not-tcp-keepalive So I think we usually should use |
Great source for compare WebSocket ping/pong and TCP keepalive 👍 So it's clear WebSocket ping/pong could do much more than TCP keepalive, and even more reliable. But in controlled network (like no HTTP proxy), use TCP keepalive to do dead-pear-detection is much more efficient than WebSocket ping/pong. I used this method when I am developing a IoT project which need to show the online status of real device. Using TCP keepalive intead of WebSocket ping/pong adds no coding to exising project and reduces the workload on device side. |
@humingchun if you are feeling strongly about this you can create a pull request for it and I have no problem with accepting it (if it's properly tested and documented) |
Is it better to instantiate the Websocket with this keepAlive option instead of adding a new public method? For example: new ws.WebSocket(address, [protocols], [options])
|
@glennschler I think keepAlive is more useful at WebSocket Server side, and I don't find any method to pass options to ws instance returned by WebSocket server' |
I think it might be nice to implement keep-alive using websocket ping/pong instead of just setting tcp keep-alive. |
I'm going to close this, I also think that a ping/pong keep alive mechanism as the one suggested in the README is more powerful/flexible. If you want the feature suggested in the issue description please open a PR. |
If you're like me and prefer the lighter-weight TCP keep-alive for your use-case, ws provides some options for configuring the underlying network layer: // Create a custom HTTP agent that overrides createConnection so we can start our connection with keep-alive as early as possible.
class HttpsAgentWithTcpKeepAlive extends require('https').Agent {
// use the 'http' module instead of 'https' if this is a ws:// websocket.
createConnection(port, host, options) {
const socket = super.createConnection(port, host, options);
socket.setKeepAlive(true, 1000);
return socket;
}
}
const ws = new WebSocket(
'wss://…',
undefined,
{
agent: new HttpsAgentWithTcpKeepAlive()
}
); This solution assumes that ws is using the Node.js standard library for HTTP networking. If you want to be able to set probe counts and intervals, you might consider using the net-keepalive package to extend Node.js' very limited net library configurability. |
setKeepAlive is a great way to detect dead TCP connection and Node.js net module has a method called
socket.setKeepAlive([enable][, initialDelay])
.To set keepalive in ws, we have to use
ws._socket
which is OK but not elegant. I would suggest adding setKeepAlive to ws so it clearly shows ws has the way to maintain a connection or detect dead connection.The code could be
The text was updated successfully, but these errors were encountered: