Close_wait: after a party disconnects from the network, the peer does not detect this error (the other party disconnects) and does not call closesocket, resulting in this status; when disconnecting:
When a fin is sent from the left side of the active shutdown request, the passive shutdown on the right side will respond to an ACK. This Ack is a TCP response (at the same time, an error is submitted by the TCP upstream application, cause the above socket send or Recv to return socket_error), instead of the application sending. At this time, the party that passively closes is in the close_wait status. If the party that is passively closed does not call closesocket at this time, it will not send the next fin, so that it is always in close_wait. Only when the party that is passively closed calls closesocket will it send a fin to the party that is actively closed, and change its status to last_ack, the socket is set to closed only after the ACK sent by the active closing party is received. Int nret = Recv (sockconnected, szrecvbuffer, sizeof (szrecvbuffer), 0); <br/> /// <br/> // when the other party calls closesocket, my program is Recv. <br/> // at this time, the FIN packet sent by the other party may not be received, but an ACK packet is returned by TCP, <br/> // so the program on my side enters the close_wait status. <Br/> // It is recommended that you determine whether an error has occurred here. It is the active closesocket. <Br/> // because the Recv timeout time has been set to 30 seconds, <br/> // the error message returned here is wsaetimedout. In this case, you can disable the connection. <br/> If (nret = socket_error) <br/>{< br/> trace_info (_ T ("= socket error received with Recv ="); <br/> closesocket (sockconnected ); <br/> return false; <br/>}< br/>When socket_orror is detected, closesocket () is called to close the socket; **************************************** * ********************** first, we know that, if our client program is in the close_wait status, it indicates that the socket is
Passive ShutdownOf! If the server actively breaks the current connection, both parties need four packages to close the TCP connection:
Server ---> fin ---> Client
Server <--- ack <--- ClientAt this time, the server is in the fin_wait_2 state, and our program is in the close_wait state.
Server <--- fin <--- ClientWhen the client sends a fin to the server, the client is set to the last_ack state.
Server ---> ack ---> ClientThe server responds to ACK, so the client socket is truly set to closed.
Our program is in
Close_wait
Status, not
Last_ack
Status
Status
, Indicating that no message has been sent
Fin
To
Server
Before closing the connection, there may be a lot of data to be sent or other things to be done, resulting in the failure to send this
FIN packet
.The reason is clear. Why don't I release a fin package? Is there so much to do before I close my connection? Another question is, Why are thousands of connections in this status? During that time, did the Server Always take the initiative to remove our connections? In any case, we must prevent similar situations from happening again!
First, we need to prevent new
Port
, You can set
So_reuseaddr
Socket options:
Reuse local addresses and portsIn the past, I used to change to another port because thousands of Ports entered the close_wait status. If this happens again next time, I want to add a limit, but the current port is in the close_wait status! Before calling
Sockconnected = socket (af_inet, sock_stream, 0 );Then, we need to set the socket options for reuse:
| /// Allow reuse of the local address and port: // The advantage is that, even if the socket is disconnected, calling the preceding socket function will not occupy another one, instead, it is always a port // to prevent the socket from being connected at all times. In this way, the port will be continuously changed. Int nreuseaddr = 1; setsockopt (sockconnected, sol_socket, so_reuseaddr, (const char *) & nreuseaddr, sizeof (INT )); |
In textbooks, this is the case:
In this way, if the server is closed or exited, the local address and port are both in
Time_wait
Status, then
So_reuseaddr
It is very useful.We may not be able to avoid freezing in the close_wait state, but at least we can ensure that it will not occupy the new port. Next, we need to set so_linger socket options: (For details, refer to so_linger options)
Close it easily or forcibly?Linger means "delay. By default (Win2k), so_dontlinger socket options are 1; so_linger options are {l_onoff: 0, l_linger: 0 }. If closesocket () is called while sending data (sending () is not completed, and data is not sent), we usually take the following measures ": because before exiting the service or re-establishing a socket, I will first call // to disable two-way communication.
Shutdown (sockconnected, sd_both );/// For security, close the old connection before each socket connection is established.
Closesocket (sockconnected );We will do this time:
Set
So_linger
Zero (that is
Linger
Structure
L_onoff
The domain is set to non-zero,
Rochelle linger
Is
0
)You don't have to worry about the closesocket call going into the "locked" status (waiting for completion), whether or not there are queued data not sent or not confirmed. This method is called "force close" because the virtual circuit of the socket is reset immediately, and all data that has not been sent will be lost. All remote Recv () calls fail and the wsaeconnreset error is returned. Set this option after connect successfully establishes a connection:
| Linger m_slinger; m_slinger.l_onoff = 1; // (allowed when closesocket () is called, but data is not sent) m_slinger.l_linger = 0; // (the allowable stay time is 0 seconds) setsockopt (sockconnected, sol_socket, so_linger, (const char *) & m_slinger, sizeof (linger )); |
SummaryWe may not be able to avoid the recurrence of close_wait status freezing, but we will minimize the impact. We hope that the reuse socket option will enable close_wait to be kicked off during the next connection establishment.
