Check Abnormal TCP disconnection so_keepalive usage Defects

At present, I have a case study on the Xinbo function. I have some experiences in using sol_socket and so_keepalive. I 'd like to write it out and share it with you.

There is a detailed description of how to about the sol_socket option so_keepalive. You can see the detailed content on the following webpage.
Http://www.icewalkers.com/Linux/Howto/TCP-Keepalive-HOWTO/index.html

In the UNIX Network Programming 1st volume, it is also described in detail:

So_keepalive keeps the connection to check whether the host of the other party crashes, so as to avoid the (server) from blocking the input of the TCP connection forever. After this option is set, if no data is exchanged in any direction of this interface within two hours, TCP automatically sends a keepalive probe to the other side ). This is a TCP segment that the other party must respond to. It may cause the following three situations: the other party receives everything normally: The expected ack response. 2 hours later, TCP sends out another detection shard. The other party has crashed and restarted: respond with RST. The interface to be processed is set to econnreset, and the interface itself is closed. The other party has no response: TCP sent from the Berkeley sends an additional eight detection segments, one in 75 seconds, and tries to get a response. If no response is returned after the first probe is sent for 11 minutes and 15 seconds, give up. The unhandled error of the Set interface is set to etimeout, And the set interface itself is disabled. For example, if the ICMP error is "Host Unreachable (host inaccessible)", it indicates that the host of the other party has not crashed but is not reachable. In this case, the error to be handled is set to ehostunreach.

On the 158th page of the book, we will provide a more detailed description.

Based on the above introduction, we can know that when the peer is disconnected in an unelegant way, we can set the so_keepalive attribute so that we can find whether the TCP connection of the other party still exists after two hours.

Keepalive = 1;
Setsockopt (listenfd, sol_socket, so_keepalive, (void *) & keepalive, sizeof (keepalive ));

If we cannot accept such a long wait time, we can know from the TCP-keepalive-howto that there are two ways to set, one is to modify the kernel's network configuration parameters, the other options are tcp_keepidle, tcp_keepintvl, and tcp_keepcnt of the sol_tcp field.

The tcp_keepidle parameter specifies the interval of inactivity that causes TCP to generate a keepalive transmission for an application that requests them. tcp_keepidle defaults to 14400 (two hours ).

/* Tcp null close time before the first keepalive test */

 

The tcp_keepintvl parameter specifies the interval between the nine retries that are attempted if a keepalive transmission is not acknowledged. tcp_keepintvl defaults to 150 (75 seconds ).
/* Interval between two keepalive probes */

The tcp_keepcnt option specifies the maximum number of keepalive probes to be sent. The value of tcp_keepcnt is an integer value between 1 and N, where N is the value of the systemwide tcp_keepcnt parameter.

/* Determine the number of keepalive probes before disconnection */

So we can get
Int keepidle = 6;
Int keepinterval = 5;
Int keepcount = 3;

Setsockopt (listenfd, sol_tcp, tcp_keepidle, (void *) & keepidle, sizeof (keepidle ));

Setsockopt (listenfd, sol_tcp, tcp_keepintvl, (void *) & keepinterval, sizeof (keepinterval ));

Setsockopt (listenfd, sol_tcp, tcp_keepcnt, (void *) & keepcount, sizeof (keepcount ));

We need to pay attention to the TCP-keepalive-howto section:

Remember that keepalive is not program −related, but socket −related, so if you have multiple sockets, you can handle keepalive for each of them separately.

These attributes are inherited by sockt, not the wholeCodeAll sockets in the class inherits this attribute, because if you want to apply it to multiple sets of interfaces, you must use setsockopt. setsockopt is the wrapped function of setsockopt.

If the heartbeats function maintains the survival of the client, that is, the server must send a certain amount of data to the client segment at intervals, so_keepalive is insufficient. Because the so_keepalive option indicates "No data is exchanged in any direction of this interface", I don't know how you understand this implementation. In the Linux 2.6 series, the above understanding is that as long as the set of interfaces that enable the so_keepalive option detect data transmission or data acceptance, it is considered as data exchange.

Therefore, in this case, using the so_keepalive option to check whether the other party's abnormal connection is completely ineffective. When packets are sent at intervals, the keep-alive package cannot be sent. Upper LayerProgramNormally, packets can be sent to the buffer zone. An exception occurs when the server does not receive a "fin" or "rst" packet.

Of course, this situation is also better to determine whether the other party is alive. The main reason I proposed is to see how everyone understands "there is no data exchange in any direction of this interface.