What happens if I use socket.setKeepAlive in Node.js server
I just want to ask in the net
Node.js module because I didn't quite understand in the docs. what happens if i implement setKeepAlive () ?. What is the behavior of this setKeepAlive ()?
var net = require('net');
var server = net.createServer(function(socket){
socket.setKeepAlive(true,60000); //1 min = 60000 milliseconds.
socket.on('data',function(data){
///receiving data here
});
socket.on('end',function(data){
});
});
server.listen(1333,'127.0.0.1', function () {
console.log("server is listening in port 1333!");
});
Thanks in advance.
source to share
This method .setKeepAlive()
enables / disables TCP. This is done at the TCP level in the OS, so it is included in the node.js socket library, but the keep-alive feature is actually implemented on the TCP stack in the host OS.
Here's a pretty good summary of what the keep alive function does: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html .
Here's the part of this article that should give you an overview:
The keepalive concept is very simple: when you set up a TCP connection, you bind a set of timers. Some of these timers are keepalive. When the keepalive timer reaches zero, you send your peer a control probe packet with no data in it, and the ACK flag is On. You can do this because of the TCP / IP specification, as a kind of duplicate ACK and the remote endpoint will have no arguments since TCP is a stream oriented protocol. On the other hand, you will receive a response from the remote host (which is not required to maintain keepalive at all, only TCP / IP), no data, and an ACK.
If you get a response to your control request, you can state that the connection is still up and not worried about at the user level. In fact, TCP allows you to process a stream, not packets, and therefore a zero-length data packet is not harmful to the user program.
This procedure is useful because if other peers lose (for example, by rebooting), you will notice that the connection is broken even if you have no traffic. If your peers are not responding to the control probes, you can argue that the connection cannot be considered valid and then take the correct action.
Since you are configuring inbound communication on your server, the effect of setting keep alive will depend entirely on what happens to those inbound sockets. If they are short-lived (for example, they are connected, exchange some data, and then disconnect like a normal HTTP connection without losing activity for any significant amount of time) then the keep-alive setting won't even go into play.
If, on the other hand, the client connects to the server and keeps that connection open for a long time, then the keep-alive setting is turned on and you will see various behaviors called in the article link above. Also, if the client is a battery powered device (phone, tablet, etc.) and it maintains a long connection, then it may consume more battery power and a little more bandwidth by responding to constant waiting for packets because the device needs to wake up to receive incoming packets and then transmit to send replies.
source to share