"Turn" Linux socket keep Alive explanation

Needs
Detects whether the client program is forced to end without affecting server processing.
Status
Both the server side and the client socket set the KeepAlive property.
Server-side set the number of probes and other parameters, the client, the server just opened the KeepAlive function
The server has a monitoring thread that uses Select to detect if the socket is closed ...

Below this is a little superficial understanding of me.

1. About Keep alive

Three parameters regardless of windows or linux,keepalive:

Sk->keepalive_probes: Number of probes
Timeout for sk->keepalive_time probing
SK->KEEPALIVE_INTVL detection Interval

For a TCP connection that has already been established. If the two parties do not have any packet transmission during the keepalive_time time, the KeepAlive function will be turned on one end of the eepalive packet, if not received, the packet is sent every KEEPALIVE_INTVL time, Send Keepalive_probes times. Has not received an answer, the Send RST package closes the connection. If an answer is received, the timer is zeroed. For example ★:

Sk->keepalive_probes = 3;
Sk->keepalive_time = 30;
SK->KEEPALIVE_INTVL = 1;

means that for a TCP connection, if there is data on the socket will not trigger keepalive, but if there is no data traffic for 30 seconds, then keep alive start to work: Send the probe packet, the response is that the network is good, the end of the probe , if there is no corresponding to every 1 seconds to send a probe packet, sent 3 times, 3 times still no corresponding,
Close the connection, that is, from the network began to disconnect your socket can realize network anomalies, up to 33 seconds. However, if you do not set keep alive, you may be on the top of your socket (blocking), receive: Recv will always block cannot return, unless the peer actively shut down the connection, because recv do not know that the socket is broken. Send: Depending on the size of the data, as long as the underlying protocol station buffer can drop your sending data, the application-level send will continue to successfully return. Until the buffer is full, even the buffer is full and will block for some time trying to wait for buffer to be idle. So your check on the return value of send does not detect a failure at all. The Keep Alive feature is turned on, and you can tell whether the network is abnormal by sending a return value directly from the Received function. Set method (Application layer):

int keepalive = 1; Turn on the KeepAlive property
int keepidle = 60; If the connection does not have any data in 60 seconds, the probe
int keepinterval = 5; The time interval for the packet to be detected is 5 seconds
int keepcount = 3; The number of attempts to probe. If the 1th probe packet receives a response, it will not be sent 2 times.
SetSockOpt (RS, Sol_socket, so_keepalive, (void *) &keepalive, sizeof (KEEPALIVE));
SetSockOpt (RS, Sol_tcp, Tcp_keepidle, (void*) &keepidle, sizeof (Keepidle));
SetSockOpt (RS, Sol_tcp, TCP_KEEPINTVL, (void *) &keepinterval, sizeof (Keepinterval));
SetSockOpt (RS, Sol_tcp, tcp_keepcnt, (void *) &keepcount, sizeof (Keepcount));

The relationship between 2.select and keep alive

Select is designed to use multiple sockets for a single thread, regardless of the connection detection, and if only one socket is detected, no need to use SELECT. If the KeepAlive function is opened, the return value is checked each time the recv or send is called, and the error or 0 is determined. If there is an error, then check the errno data to see which or which number of error numbers means that the link is broken or nonexistent.

In addition, who wants to check the connection status regularly, who will enable keep alive. The other end can not afford, just passively response to the probe packet, this response is the basic requirements of the TCP protocol, not related to keep alive. Keep Alive is not required on both the client and server sides.

3. Test results

In the case of the value of ★ on one end of the socket to open keep alive, and then blocked in a recv or non-stop send, this time to unplug the network cable, test from unplug the network cable to Recv/send return to the time of failure.

In the Linux kernel test found that for the blocked socket, when recv, if not set keep alive, even if the network cable unplugged or IFDOWN,RECV for a long time will not return, up to 17 minutes, Although this time is much shorter than the default time-out () of Linux. However, if keep alive is set, the basic is to return an error within keepalive_time +KEEPALIVE_PROBES*KEEPALIVE_INTVL = 33 seconds.

But for the loop to send the socket, when unplugging the network cable, will continue for a period of time send return success (about 0-10 seconds, depending on the amount of data sent), and then send blocking, because the protocol layer buffer is full, waiting for buffer to idle, The error will not be returned after about 90 seconds. From this point of view, when send, keep alive does not seem to play a role, this reason is not clear now. It was later resolved by setting the timer to send before.

"Turn" Linux socket keep Alive explanation