what will happen if I use socket.setKeepAlive in Node.js server - node.js

Question

I just want to ask in net module of Node.js because I did not fully understand in the docs. what will happen if I implement the 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!");
});
Thank you in advance.

Answer 1

The .setKeepAlive() method enables/disables TCP keep alive. This is done at the TCP level in the OS, so it is enabled by the node.js socket library, but the keep-alive functionality is actually implemented in the TCP stack in the host OS.
Here's a pretty good summary of what the keep alive feature does: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html.
Here's a piece of that article that should give you an overview:
The keepalive concept is very simple: when you set up a TCP
connection, you associate a set of timers. Some of these timers deal
with the keepalive procedure. When the keepalive timer reaches zero,
you send your peer a keepalive probe packet with no data in it and the
ACK flag turned on. You can do this because of the TCP/IP
specifications, as a sort of duplicate ACK, and the remote endpoint
will have no arguments, as TCP is a stream-oriented protocol. On the
other hand, you will receive a reply from the remote host (which
doesn't need to support keepalive at all, just TCP/IP), with no data
and the ACK set.
If you receive a reply to your keepalive probe, you can assert that
the connection is still up and running without worrying about the
user-level implementation. In fact, TCP permits you to handle a
stream, not packets, and so a zero-length data packet is not dangerous
for the user program.
This procedure is useful because if the other peers lose their
connection (for example by rebooting) you will notice that the
connection is broken, even if you don't have traffic on it. If the
keepalive probes are not replied to by your peer, you can assert that
the connection cannot be considered valid and then take the correct
action.
Since you are setting keep alive on incoming connections to your server, the effect of the keep alive setting will depend entirely upon what happens with these incoming sockets. If they are short lived (e.g. they connected, exchange some data and then disconnect like a typical HTTP connection without going inactive for any significant amount of time), then the keep-alive setting will not even come into play.
If, on the other hand, the client connects to the server and holds that connection open for a long time, then the keep-alive setting will come into play and you will see the different behaviors that are called out in the above referenced article. In addition, if the client is a battery-powered device (phone, tablet, etc...) and it holds a long running connection, then it may consume more battery power and a small bit more bandwidth responding to the regular keep-alive packets because the device has to wake up to receive incoming packets and then has to transmit to send responses.