Persistent connection and heartbeat Packet

First, set the keepalive attribute of the socket.
# Include "/usr/include/Linux/tcp. H"
# Include "/usr/include/Linux/socket. H"
//// Keepalive implementation, in seconds
// The following code requires an ace. If it does not contain an ace, change the ace function used to the corresponding Linux interface.
Int keepalive = 1; // set keepalive
Int keepidle = 5; // tcp null close time before the first keepalive test is started
Int keepinterval = 5; // interval between two keepalive probes
Int keepcount = 3; // determines the number of keepalive probes before disconnection
If (setsockopt (S, sol_socket, so_keepalive, (void *) & keepalive, sizeof (keepalive) =-1)
{
Ace_debug (lm_info,
Ace_text ("(% p | % t) setsockopt so_keepalive error! /N ")));
}

If (setsockopt (S, sol_tcp, tcp_keepidle, (void *) & keepidle, sizeof (keepidle) =-1)
{
Ace_debug (lm_info,
Ace_text ("(% p | % t) setsockopt tcp_keepidle error! /N ")));
}

If (setsockopt (S, sol_tcp, tcp_keepintvl, (void *) & keepinterval, sizeof (keepinterval) =-1)
{
Ace_debug (lm_info,
Ace_text ("(% p | % t) setsockopt tcp_keepintvl error! /N ")));
}

If (setsockopt (S, sol_tcp, tcp_keepcnt, (void *) & keepcount, sizeof (keepcount) =-1)
{
Ace_debug (lm_info,
Ace_text ("(% p | % t) setsockopt tcp_keepcnt error! /N ")));
}

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& & 7

The TCP protocol can be divided into persistent connections and short connections. The short connection will be disconnected after the packet is sent. After the long connection is sent, the connection will be maintained within a certain period of time, which is commonly referred to as the keepalive (Survival timer) function.
The default keepalive timeout requires 7,200,000 milliseconds, that is, 2 hours, and the number of probes is 5. Its functions are the same as the heartbeat Mechanism Implemented by users themselves. Enabling the keepalive function requires additional bandwidth and traffic. Although this is insignificant, the cost is increased in the paybytraffic environment. On the other hand, when keepalive settings are unreasonable, a healthy TCP connection may be disconnected due to transient network fluctuations.

Keepalive is not part of the TCP specification. The Host Requirements RFC lists three reasons for not using it: (1) during a short fault, they may cause a good connection to be released (dropped ), (2) they consume unnecessary bandwidth, and (3) They (extra) spend money on the Internet where data packets are billed. However, a survival timer is provided in many implementations.

Some server applications may occupy resources on the client. They need to know whether the client host crashes. The survival timer can provide probe services for these applications. Many versions of the Telnet server and rlogin server provide the survival option by default.

PC users use the TCP/IP protocol to log on to a host through Telnet. This is a common example of survival timer. If a user only turns off the power at the end of use and does not log off, then the user leaves a semi-open connection. If the client disappears, the server is left with a semi-open connection, and the server is waiting for the client data, the waiting will continue forever. The survival feature aims to detect this semi-open connection on the server side.

You can also set the alive option on the client, and there is no reason not to allow this, but it is usually set on the server. If both ends of the connection need to detect whether the other end disappears, you can set both ends (such as NFS ).

How keepalive works:

If no activity is performed within two hours on a given connection, the server sends a detection segment to the client. (We will see the probe section in the following example .) The client host must be in one of the following four States:

1) The client host is still active (UP) and can be reached from the server. From the normal response of the client TCP, the server knows that the other party is still active. The TCP of the server resets the active timer for the next two hours. If the application communication occurs before the expiration of the two hours, the timer resets the timer for the next two hours, and then exchange data.

2) The client has crashed, shut down, or is restarting. In both cases, TCP does not respond. The server does not receive a Detection Response and times out after 75 seconds. The server will send a total of 10 such probes, each of which is 75 seconds. If no response is received, the client host is considered closed and the connection is terminated.

3) The client has crashed but has restarted. In this case, the server will receive a response to its survival detection, but the response is a reset, causing the server to terminate the connection.

4) The client host is active, but the slave server cannot be reached. This is similar to status 2 because TCP cannot distinguish the two. It can only indicate that no response has been received to it.

 

The server does not have to worry about the client host being shut down and then restarted (this refers to the normal shutdown by the operator, rather than the host crash ). When the system is shut down by the operator, all application processes (that is, client processes) will be terminated, and client TCP will send a fin over the connection. After receiving the fin, the server TCP reports the end of a file to the server process to allow the server to detect this state.

In the first State, the server application does not know whether the survival test has occurred. Everything is handled by the TCP layer, and the survival detection is transparent to the application until the following three States are 2, 3, and 4. In these three states, an error message is returned to the server application through TCP of the server. (Generally, the server sends a read request to the network, waiting for the client data. If the survival feature returns an error message, the message is returned to the server as the return value of the read operation .) In status 2, the error message is similar to "connection timeout ". Status 3 indicates that the connection is reset by the other party ". The fourth state may look like a connection timeout, or other error messages may be returned based on whether the ICMP error message related to the connection is received.

The Linux kernel supports keepalive. Three parameters are used: tcp_keepalive_time (idle time when keepalive is enabled) tcp_keepalive_intvl (sending interval of the keepalive test package) and tcp_keepalive_probes (the number of times the test package is sent if no response is sent ); in liunx, keepalive is a switch option that can be enabled through functions. Specifically, you can use the following code:
Setsockopt (RS, sol_socket, so_keepalive, (void *) & keepalive, sizeof (keepalive ));

 

When TCP detects that the Peer socket is no longer available (the detection package cannot be issued, or the detection package does not receive the ACK response package), select returns the socket readable, in addition,-1 is returned for Recv and errno is set to etimedout. In this case, the TCP status is disconnected.

The keepalive parameter setting code is as follows:

// Enable keepalive
Bool bkeepalive = true;
Int nret =: setsockopt (socket_handle, sol_socket, so_keepalive, (char *) & bkeepalive, sizeof (bkeepalive ));
If (nret = socket_error)
{
Return false;
}

// Set the keepalive Parameter
Tcp_keepalive alive_in = {0 };
Tcp_keepalive alive_out = {0 };
Alive_in.keepalivetime = 5000; // tcp null close time before the first keepalive test starts
Alive_in.keepaliveinterval = 1000; // interval between two keepalive probes
Alive_in.onoff = true;
Unsigned long ulbytesreturn = 0;
Nret = wsaioctl (socket_handle, sio_keepalive_vals, & alive_in, sizeof (alive_in ),
& Alive_out, sizeof (alive_out), & ulbytesreturn, null, null );
If (nret = socket_error)
{
Return false;
}

After the keepalive option is enabled, the getqueuedcompletionstatus function returns false immediately for server programs that use the iocp model once the connection is detected to be disconnected, this allows the server to promptly clear the connection and release resources related to the connection. For the client that uses the select model, when the connection is disconnected, the Select method blocked on the socket for Recv will immediately return socket_error, so that the connection is invalid, the client program will have the opportunity to promptly clear the work, remind the user or reconnect.

Keepalive Detection)

"Abnormal disconnection" indicates that TCP connections are not broken in an elegant way, such as the causes of network cable faults and other physical links, as well as sudden host power outages.

There are two methods to detect: 1. the TCP connection sends a handshake message at regular intervals. 2. Uses keepalive detection in the TCP protocol stack.

The second method is simple and reliable. You only need to set keepalive detection for two sockets connected to TCP.


In Windows, you must include the header file of mstcpip. h. Click the following link to download the file.
Mstcpip

Note: Although persistent connections are good, they are easy to use but occupy a large amount of system resources. We recommend that you use your own heartbeat packet mechanism if you do not have special requirements.

 

Transferred from:

Persistent connection and heartbeat Packet