Linux Network programming socket options SO_LINGER,SO_REUSEADDR

From http://blog.csdn.net/feiyinzilgd/article/details/5894300

In Linux network programming, there are many options for sockets. Several of the more important options are: So_linger (only for TCP,SCTP), so_reuseaddr.

• So_linger

By default, when you call close to close the use of Socke, close returns immediately, but if there is data in send buffer, the system will try to send the data in the send buffer first and then close to return.

The So_linger option is used to modify this default action. A struct associated with So_linger is as follows:

[CPP] view plain copy  print?

1. #include <sys/socket.h>
2. struct Linger {
3. int L_onoff //0=off, nonzero=on (switch)
4. int L_linger //linger time (delay)
5. }

When SetSockOpt is called, the effect of this option depends on the values of L_onoff and l_linger in the linger struct:

0 = L_onoff

When L_onoff is set to 0, the So_linger option is turned off, that is, TCP or SCTP remains the default action: Close immediately returns. The L_linger value is ignored.

L_lineoff value non-0,0 = L_linger

When Close is called, the TCP connection is immediately disconnected. Data that is not sent in send buffer is discarded and an RST message is sent to the other party. It is worth noting that due to this way, the TCP link is terminated in an abnormal 4 handshake mode, so the TCP connection will not enter the time _wait state, which can cause new and confusing data to be created. For specific reasons see my previous article "Linux Network programming time_wait status"

• L_onoff and L_linger are non-0.

In this case, the return of the close of the back gets delayed. When you call close to close the socket, the kernel will be delayed. That is, if the data in send buffer has not yet been sent, the process will be dormant until one of the following occurs:

1) All data in the send buffer is sent and received a response from the other TCP (this answer does not mean that the other application has received the data, in the following shutdown will be specific sermon)
2) The delay time is exhausted. After the delay time is exhausted, all data in the send buffer will be discarded.

Above 1), 2) in both cases, if the socket is set to the O_nonblock state, the program will not wait for close to return, and all data in the send buffer will be discarded. Therefore, we need to determine the return value of close. When all the data in send buffer is sent and the delay time is not exhausted, close returns a Ewouldblock error.

Here are a few examples to illustrate:

A. Close default action: return now

In this case, close returns immediately, and if there is data in send buffer, close will wait until all data has been sent and returned. Since we do not wait for the other side to send the ACK message, so we can only guarantee that the data has been sent to the other side, we do not know whether the other party has accepted the data. Due to this situation, the TCP connection termination is in accordance with the normal 4-time handshake, need to go through time_wait.

B. L_onoff not 0, and make it l_linger as an integer

In this case, close will not return until the ACK information of the other TCP is received (before the L_linger is exhausted). However, this ACK information only guarantees that the other party has received the data, and does not guarantee that the other application has read the data.

C. L_linger setting value is too small

In this case, because the L_linger value is too small, before the data in send buffer is sent out, close returns, in which case the TCP connection is terminated, and the TCP connection is similar to L_linger = 0, the termination is not in accordance with the normal 4-step handshake, so The TCP connection does not enter the TIME_WAIT state, then the client sends an RST message to the server.

D. Shutdown, waiting for the application to read the data

In contrast to the above B, call shutdown immediately after the call to read, at which time read is blocked until the other's fin is received, that is, read is returned after the server application calls close. When the server application reads data from the client and fin, the server enters a call close_wait, about close_wait, as described in my blog, "TCP state Transitions for Linux network programming." Then, if the server side wants to disconnect the TCP connection, the server application needs to call Close, which means that fin is sent to the client. At this point, the server-side application has read the data sent to the client and fin. Read returns after receiving the fin of the server. So, shutdown can ensure that the server-side application has read the data, not just the server has received the data.

The shutdown parameters are as follows:

SHUT_RD: Call shutdown one end of receive buffer will be discarded, unable to accept data, but can send data, send buffer data can be sent out

SHUT_WR: The end of the call to shutdown cannot send data, but it can accept data. This parameter indicates that send cannot be called. But if there is data in send buffer, the data will still be sent.

• SO_REUSEADDR and So_reuseport

Recently, seeing the Linux section of CSDN, someone asked why the server program could not be connected after it was restarted, and it would take a while to connect. I think there are two possibilities for this problem: one is that the server has been stuck in the time_wait state. This time, Need to wait 2MSL time to reconnect, specific details for reasons please see my other article "Linux Network programming time_wait State"

Another possibility is the SO_REUSEADDR parameter setting problem. About Time_wait I'm not here to repeat, here I speak of so_reuseaddr.

• SO_REUSEADDR allows a server program listen to listen and bind to a port, both of which are already in use by a running connection.

We typically encounter the following scenario:

1. A listener (Listen) server has started
2. When a client has a connection request, the server generates a child process to process the client's things.
3. The server master process is terminated, but the child process is still consuming the connection processing client. Although the child process is terminated, the reference count of the socket will not be 0 because the child process is not terminated, so the socket will not be closed.
4. The server program restarts.

By default, the server restarts, calls Socket,bind, and then listen, and fails. Because the port is in use. If you set the SO_REUSEADDR, the server restart will succeed. Therefore, all TCP servers must have this option set. Used to respond to server restarts.

• SO_REUSEADDR allows multiple IPs to be bound on the same port. As long as these IPs are different. In addition, you can also bind IP wildcard characters. However, it is best to bind the identified IP first, and finally bind the wildcard IP. One side of the system is rejected. In short, so_ REUSEADDR allows multiple servers to be bound to the same port, as long as these servers specify a different IP, but so_reuseaddr needs to be set before the bind call. In TCP, A connection to the same IP and port that already exists is not allowed. But in UDP, it is allowed.

Linux Network programming socket options SO_LINGER,SO_REUSEADDR