Socket keep alive in Linux

[Requirement]
Checks whether the client program is forcibly terminated without affecting server processing.
[Status quo]
The keepalive attribute is set for both the server and client sockets.
The server sets parameters such as the number of probes. The client and server only enable the keepalive function.
The server starts a monitoring thread and uses select to check whether the socket is disabled...

Below is my superficial understanding.

1. About keep alive

Keepalive has three parameters, regardless of windows or Linux:

SK-> keepalive_probes: Number of probes
SK-> keepalive_time detection timeout
SK-> keepalive_intvl detection Interval

For a TCP connection that has been established. If no data packet is transmitted between the two parties within the keepalive_time period, the end of the keepalive feature will send the eepalive data packet. If no response is received, the data packet will be sent at intervals of keepalive_intvl, send keepalive_probes times. If no response is received, the RST packet is sent to close the connection. If a response is received, the timer is cleared. For example★:

SK-> keepalive_probes = 3;
SK-> keepalive_time = 30;
SK-> keepalive_intvl = 1;

The idea is that for TCP connections, keepalive will not be triggered if there is data exchange on the socket for a long time, but if there is no data exchange for 30 seconds, keep alive starts to work: Send the test package, if a response is received, the network is considered as a good one, and the detection is completed. If no response is received, the detection packet is sent every second, three times in total, and no response is returned after three times,
Close the connection, that is, it takes up to 33 seconds to disconnect your socket from the network and realize that the network is abnormal. However, if you do not set the keep alive, you may receive the Recv on your socket (Obstruction) until the peer closes the connection, because the Recv does not know that the socket is disconnected. Sending: depending on the amount of data, as long as the buffer of the underlying protocol station can put your sent data, application-level sending will always be successful. Until the buffer is full, or even the buffer is full, it will block a period of time and try to wait for the buffer to be idle. Therefore, your check on the return value of the send operation fails. Keep Enabled
Alive function, you can know whether the network is abnormal by sending and receiving the function return value. Setting Method (Application Layer ):

Int keepalive = 1; // enable the keepalive attribute
Int keepidle = 60; // if the connection does not have any data exchange within 60 seconds, the test is performed.
Int keepinterval = 5; // The packet interval during probe is 5 seconds.
Int keepcount = 3; // Number of probe attempts. If the response is received for the first probe packet, the next two attempts will not be sent again.
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 ));

2. Relationship between select and keep alive

Select is designed for a single thread to use multiple sockets and has nothing to do with the detection connection. If only one socket is detected, it is not necessary to use select. If the keepalive function is enabled, check the return value every time you call Recv or send to determine whether an error is returned or 0. if an error occurs, check errno for information and check which or which of the following error numbers indicate that the link is broken or does not exist.

In addition, if you want to regularly check the connection status, you can enable keep alive. The other end cannot afford it, but passively responds to the test package. Such a response is the basic requirement of the TCP protocol and has nothing to do with keep alive. You do not need to enable keep alive on both the client and server.

3. Test Results

Example★Enable the keep alive value on one end of the socket, and then block in a Recv or do not stop sending. In this case, unplug the network cable and test the time from unplugging the network cable to Recv/send.

Test in Linux kernel shows that for a blocked socket, if keep alive is not set during Recv, The Recv will not be returned for a long time even if the network cable is unplugged or ifdown, up to 17 minutes, although this time is much shorter than the default Linux timeout time. However, if keep alive is set, an error is basically returned within keepalive_time + keepalive_probes * keepalive_intvl = 33 seconds.

However, for a socket that is repeatedly sent, after the network cable is unplugged, it will be sent back for a period of time (0 ~ About 10 seconds, depending on the amount of data sent), and then the send blocking, because the protocol layer buffer is full, waiting for the buffer to be idle, about 90 seconds later will return an error. From this point of view, the keep alive does not seem to play a role when sending, and the reason is still unclear. Later, it was solved by setting timer before sending.