Linux Network Programming socket options so_linger, so_reuseaddr

Linux Network Programming socket options so_linger, so_reuseaddr

In Linux network programming, there are many socket options. Several of the most important options are: so_linger (only applicable to TCP and sctp), so_reuseaddr.

 

• So_linger

By default, when you call close to disable socke, close will return immediately. However, if there is still data in the send buffer, the system will try to send the data in the send buffer first, then close is returned.

 

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

# Include <sys/socket. h> <br/> struct linger {<br/> int l_onoff // 0 = OFF, nonzero = on (switch) <br/> int l_linger // linger time (Delay Time) <br/>}

 

After setsockopt is called, the impact 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 disabled, that is, TCP or sctp is maintained by default. Close is returned immediately. l_linger value is ignored.

The l_lineoff value is not 0, 0 = l_linger

When close is called, the TCP connection is closed immediately. unsent data in the send buffer will be discarded and an rst message will be sent to the other party. it is worth noting that due to this method, the TCP link is terminated by a non-normal 4-way handshake, so the TCP connection will not enter the time_wait status, this will lead to confusion between newly established data and connected data. For details, see my previous article "Linux Network Programming time_wait status".

 

• Both l_onoff and l_linger are non-0

In this case, the return of the close operation gets a delay. When you call close to close the socket, the kernel will be delayed. That is to say, if there is still data not sent in the send buffer, the process will be sleep until any of the following situations occurs:

 

1) all the data in the send buffer is sent and the peer TCP Response Message is obtained (this response does not mean that the peer application has received the data, and the shutdown will be detailed later)
2) the delay time is exhausted. After the delay time is consumed, all data in the send buffer will be discarded.

 

In the above 1), 2) Two cases, if the socket is set to the o_nonblock status, 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. Before all data in the send buffer is sent, and the delay time is not exhausted. If the return result is closed, an error of ewouldblock will be returned.

The following describes several instances:

A. Default close operation: return immediately

In this case, close returns immediately. If there is still data in the send buffer, close will return after all data is sent. Since we have not waited for the ACK message sent by the other party's TCP, we can only ensure that the data has been sent to the other party, and we do not know whether the other party has accepted the data. In this case, the TCP connection is terminated in the normal 4-way handshake mode and must go through time_wait.

 

B. l_onoff is not 0, and l_linger is an integer.

 

 

In this case, close will be returned only after receiving the ACK information from the peer TCP (before l_linger consumes ). However, this ack information can only ensure that the other party has received the data, but does not ensure that the other party's application has read the data.

 

 

C. The value of l_linger is too small.

 

 

 

In this case, because the l_linger value is too small, close will be returned before the data in the send buffer is sent. In this case, the TCP connection is terminated, which is similar to l_linger = 0, TCP connection termination does not follow the normal 4-step handshake. Therefore, the TCP connection does not enter the time_wait status. Therefore, the client sends an rst message to the server.

 

 

D. shutdown, waiting for the application to read data

 

 

 

Compare with B above. Call shutdown and then call read. At this time, read will be blocked until the other side's fin is received. That is to say, read is returned only after the server application calls close. When the server application reads data from the client and fin, the server will enter a close_wait. For details about close_wait, see my blog "TCP state conversion for Linux network programming". If the server needs to disconnect the TCP connection, the server application needs to call close once, which means to send fin to the client. At this time, the server application has read the data and fin sent by the client. Read will return after receiving the server's Fin. Therefore, shutdown ensures that the server application has read data, not just the server has received the data.

 

The shutdown parameters are as follows:

Shut_rd: The receive buffer at the end of the shutdown call will be discarded and unable to accept the data. However, data can be sent and data in the send buffer can be sent.

Shut_wr: the end that calls shutdown cannot send data, but can accept data. this parameter indicates that sending cannot be called. however, if there is data in the send buffer, the data will still be sent.

 

 

 

• So_reuseaddr and so_reuseport

Recently, I saw the csdn Linux section. Someone asked why the server program cannot be connected after it is restarted. It takes some time to connect. I think there are two possible reasons for this problem: one is that the server stays in the time_wait status. at this time, you need to wait for 2msl time to reconnect. For details, see my other article "time_wait status of Linux network programming".

Another possibility is the so_reuseaddr parameter setting. I will not repeat time_wait here. Here I will talk about so_reuseaddr.

 

• So_reuseaddr allows a server program listen to listen and bind to a port, which is used by a running connection.

We generally encounter the following problems:

 

1. A listener (Listen) server has been started
2. When a client has a connection request, the server generates a sub-process to process the client.
3. The master process of the server is terminated, but the sub-process still occupies the connection to process the client. although the sub-process is terminated, because the sub-process is not terminated, the reference count of the socket will not be 0, so the socket will not be closed.
4. Server Program Restart.

 

By default, the server restarts, calls socket, bind, and then listen, which will fail. because the port is being used. if so_reuseaddr is set, server restart will succeed. therefore, all TCP servers must set this option to cope with server restart.

 

 

• So_reuseaddr allows multiple IP addresses to be bound to the same port. as long as these IP addresses are different. in addition, you can bind an IP wildcard. however, it is best to bind the specified IP address first and then bind the wildcard IP address. one system rejects the request. in short, so_reuseaddr allows multiple servers to be bound to the same port. As long as the IP addresses specified by these servers are different, so_reuseaddr must be set before BIND is called. in TCP, a connection with the same IP address and port already exists. but in UDP, it is allowed.

 

Copyright statement:
Reprinted Article please indicate the original source http://blog.csdn.net/feiyinzilgd/archive/2010/09/19/5894300.aspx
Contact tan Haiyan or go to tan Haiyan's personal homepage to leave a message.