Abnormal closure of the meaning of the exception close link in TCP

The normal way to terminate a connection is to send fin. Fin is sent after all queued data has been sent in the send buffer, and there is no data loss under normal circumstances.

But sometimes it is possible to send an RST message segment instead of F in to close a connection halfway. This is called an abnormal shutdown.

The default way for the process to close the socket is to shut down normally, and to control it with the SO_LINGER option if it needs to close unexpectedly.

Exception closing a connection has two advantages for an application:

(1) Discard any outgoing data that is meaningless and immediately send the RST message segment;

(2) The receiver of the RST uses the closing method to distinguish between an abnormal shutdown or a graceful shutdown at the other end.

It is important to note that the RST message segment does not cause any response at the other end, and the other end does not confirm at all. The party that receives the RST terminates the connection. The program behaves as follows:

Under the blocking model, the kernel cannot proactively notify the application layer of an error, and the kernel will use an error to notify the application tier-to-end RST only if the application layer invokes read () or write () as an IO system call.

In a non-blocking model, select or Epoll will return SOCKFD readable, and read () will error RST when the application layer reads it.

Some socket errors are found frequently during game testing, and the following are the cases typically considered when testing a game server.
server-side:
1.
Case: The client program is running normally, unplug the network cable, kill the client program
Objective: To simulate the client's death, sudden system restart, network cable loosening, etc.
Conclusion: In this scenario, the server program does not detect any exceptions and finally waits for a "timeout" to disconnect the TCP connection

2.
Case: The client program sends a lot of packets to gracefully close the socket and exit the process (or not quit the process)
Purpose: To simulate the normal exit when the client sends out a message
Conclusion: In this case, the server program can successfully receive all messages, and finally receive "peer-to-peer shutdown" (recv return 0) message

3.
Case: Client program sends many packets without shutting down the socket directly exit process
Purpose: To simulate the case where the client program exits and forgets to close the socket (such as exiting the process through the Windows window's close icon without capturing the corresponding shutdown event for normal exit processing, etc.)
Conclusion: In this case, the server program can receive a partial TCP message and then receive "104:connection Reset by Peer" (Linux) or "10054:an existing Connection was forcibly closed b Y The remote host "(under Windows) error

4.
Case: The client program sends a lot of packets in the process of the direct kill process
Purpose: Simulate client program crashes or abnormal end processes (such as "Kill-9″ or Windows Task Manager kill process" under Linux)
Conclusion: In this case the server program soon receives "104:connection Reset by Peer" (under Linux) or "10054:an existing Connection was forcibly closed by the remote Host "(under Windows) error

5.
Case: The client program sends a lot of packets to gracefully close the socket and exit the process (or not quit the process)
Purpose: Simulates a situation in which a client sends a message to a client before it checks to the end of a TCP peer shutdown after it has gracefully closed the socket
Conclusion: In this case, after the server program receives and sends a partial TCP message, the Send message produces "32:broken pipe" (under Linux) or "10053:an established connection is aborted by the Software in your host machine "(under Windows) error

Summarize:
When a TCP connected process forgets to close the socket and exits, the program crashes, or the process is terminated abnormally (the Windows client), the peer-to-peer process of the TCP connection is generated by the "104:connection Reset by Peers" (under Linux) or " 10054:an existing connection was forcibly closed by the remote host "(under Windows) error

The connected peer process may not detect any exceptions when the TCP connected process machine freezes, sudden system restarts, network cables are loose, or networks are out of order, and finally waits for a "timeout" to disconnect the TCP connection

When a TCP-connected process gracefully shuts down the socket, the peer process still sends a message to TCP before it checks to the TCP shutdown event, resulting in "32:broken pipe" (under Linux) or "10053:an established" on the Send Message Connection was aborted by the software under your host machine "(Windows) error

Client
1.
The server side has already close the socket, the client sends the data again
Purpose: Test to continue sending messages to the peer when the TCP peer process has closed the socket and the local process has not detected a connection shutdown
Conclusion: The first package can be sent successfully, but the second packet fails with the error code "10053:an established connection was aborted by the software in your host machine" (under Windows) or "3 2:broken pipe while receiving sigpipe signal "(Linux) error

2.
After the server sends the data to TCP close the socket, the client sends a packet of data, and then receives the message
Purpose: To test that the socket is closed after the TCP peer process sends the data, that the local process has not detected a connection shutdown and sends a packet message, and then receives the message
Conclusion: The client can successfully send the first packet of data (which causes the server to send an RST package < captured packet verification >), and when the client goes to recv, there are different performances for Windows and Linux programs:
Windows client program: Recv failed with error code "10053:an established connection was aborted by the software in your host machine"
Linux client program: Can receive all the message packets normally, and finally receive a normal peer-to-peer shutdown message (this is not the same as under window)

3.
Server side in the TCP receive buffer in the case of not receiving data, close the socket, the client again to receive packets
Purpose: To test whether the peer process is normal when the socket is closed with no data received in the TCP receive buffer
Conclusion: In this case, the server sends the RST packet to the peer instead of the normal fin packet (which has been captured), which causes the client to advance (the RST packet is received before the normal packet) and receives "10054:an existing connection was forcibly Closed by the remote host "(under Windows) or" 104:connection Reset by Peer "(under Linux) error

Summarize:
When the TCP connected peer process has closed the socket, the first packet can be sent successfully (but will cause a RST packet to be sent to the end) when the local process sends the data again:
After that, if the data continues to fail, the error code is "10053:an established connection is aborted by the software in your host machine" (under Windows) or "32:brok En pipe, while receiving the Sigpipe signal "(Linux) error;
If you receive data later, 10053 error is reported under Windows, while Linux receives a graceful shutdown message

In the case of a TCP connection where there is no data received in the local receive buffer and close the socket, this TCP sends the RST packet to the peer instead of the normal fin packet, which causes the peer-to-peer process to be received in advance (the RST packet is received first than the normal packet) "10054:an Existing connection was forcibly closed by the remote host "(under Windows) or" 104:connection Reset by Peer "(under Linux) error

Abnormal closure of the meaning of the exception close link in TCP