Reposted from: http://jeffchen.cn/?p=776 During
game testing, it was found that some socket errors often appeared. The following are the cases that are usually considered when testing game servers. The
client fails, the server side:
1.
Case: Client When the client program is running normally, unplug the network cable and kill the client program.
Purpose: To simulate the client crash, the system restarts suddenly, the network cable is loose or the network
is unavailable, etc. Conclusion: In this case, the server program does not detect any abnormalities, and Finally wait for "timeout" before disconnecting the TCP connection
2.
Case: The client program normally closes the Socket and exits the process (or does not exit the process) after sending a lot of data packets.
Purpose: To simulate the situation where the client exits normally after sending the message.
Conclusion: In this case, the server program can successfully receive all Message, and finally received the "Peer Closed" (Recv returns zero) message
3.
Case: The client program does not close the Socket after sending a lot of data packets and directly
exits the process. Purpose: To simulate the situation where the client program exits and forgets to close the Socket (such as exiting the process through the close icon of the Windows window, but not capturing the corresponding closing event to do normal Exit processing, etc.)
Conclusion: In this case, the server program can receive some TCP messages, and then receive "104: Connection reset by peer" (under Linux) or "10054: An existing connection was forcibly closed by the remote host" ( Windows) error
4.
Case: Kill the process directly when the client program sends a lot of data packets.
Purpose: to simulate the crash of the client program or terminate the process in an abnormal way (such as "kill -9" under Linux or the task manager of Windows to kill the process) Situation
Conclusion: In this case, the server program quickly received the error "104: Connection reset by peer" (under Linux) or "10054: An existing connection was forcibly closed by the remote host" (under Windows)
5.
Case: The client program normally closes the Socket and exits the process (or does not exit the process) after sending a lot of data packets.
Purpose: To simulate that the client normally closes the Socket, the server sends a message to the client before checking that the TCP peer is closed. Situation
conclusion: In this case, after the server program receives and sends some TCP messages, it generates "32: Broken pipe" (under Linux) or "10053: An established connection was aborted by the software in your host machine" ( Windows) error
Summary:
When the TCP connection process exits after forgetting to close the Socket, the program crashes, or the process ends abnormally (Windows client), it will cause the opposite process of the TCP connection to generate "104: Connection reset by peer" ( Under Linux) or "10054: An existing connection was forcibly closed by the remote host" (under Windows) error
When the TCP connection process machine crashes, the system restarts suddenly, the network cable is loose, or the network is disconnected, the connected peer process may not detect any abnormalities, and finally waits for "timeout" before disconnecting the TCP connection
When the TCP connection process closes the Socket normally, the peer process still sends a message to the TCP before the TCP close event is checked, and the Send message will generate "32: Broken pipe" (under Linux) or "10053: An established connection" was aborted by the software in your host machine" (under Windows) error
The server fails, the client:
1. The
server has closed the Socket, and the client sends data.
Purpose: To test when the TCP peer process has closed the Socket, the local process has not detected that the connection is closed. The
conclusion of the message sent by the end : the first packet can be sent successfully, but the second packet failed. The error code is "10053: An established connection was aborted by the software in your host machine" (under Windows) or "32: Broken pipe," SIGPIPE signal received" (under Linux) error
2. The
server
closes the Socket after sending data to TCP, the client sends another packet of data, and then receives the message. Purpose: To test that the Socket is closed after the TCP peer process sends data, and the local process has not detected that the connection is closed. Send a packet of messages, and then receive the message.
Conclusion: The client can successfully send the first packet of data (this will cause the server to send an RST packet <packet verification>). When the client goes to Recv, it is for Windows and Linux programs. There are different manifestations as follows:
Windows client program: Recv failed, the error code is "10053: An established connection was aborted by the software in your host machine"
Linux client program: All message packets can be received normally, and finally received normally The peer closes the message (this is not the same as under Window)
3. The
server
closes the Socket when there is unreceived data in the TCP receive buffer, and the client receives the packet. Purpose: To test when the Socket is closed when there is unreceived data in the TCP receive buffer, Whether the opposite process is normal or not?
Conclusion: In this case, the server will send a RST packet to the opposite end instead of a normal FIN packet (which has been proved by capturing the packet), which will cause the client to be early (the RST packet is preceded by the normal data packet). Received) I received the error "10054: An existing connection was forcibly closed by the remote host" (under Windows) or "104: Connection reset by peer" (under Linux)
Summary:
When the peer process of the TCP connection has closed the Socket, when the local process sends data again, the first packet can be sent successfully (but it will cause the peer to send a RST packet):
If you continue to send data later Will fail, the error code is "10053: An established connection was aborted by the software in your host machine" (under Windows) or "32: Broken pipe, while receiving SIGPIPE signal" (under Linux) error;
afterwards, if you receive data, Under Windows, an error of 10053 will be reported, while under Linux, a normal shutdown message will be received
If there is still unreceived data in the local receiving buffer of the TCP connection and the Socket is closed, the local TCP will send a RST packet to the opposite end instead of the normal FIN packet, which will cause the opposite end to process early (RST The packet is received earlier than the normal data packet) and the error "10054: An existing connection was forcibly closed by the remote host" (under Windows) or "104: Connection reset by peer" (under Linux) is received.
Reposted from: http://jeffchen.cn/?p=776 During
game testing, it was found that some socket errors often appeared. The following are the cases that are usually considered when testing game servers. The
client fails, the server side:
1.
Case: Client When the client program is running normally, unplug the network cable and kill the client program.
Purpose: To simulate the client crash, the system restarts suddenly, the network cable is loose or the network
is unavailable, etc. Conclusion: In this case, the server program does not detect any abnormalities, and Finally wait for "timeout" before disconnecting the TCP connection
2.
Case: The client program normally closes the Socket and exits the process (or does not exit the process) after sending a lot of data packets.
Purpose: To simulate the situation where the client exits normally after sending the message.
Conclusion: In this case, the server program can successfully receive all Message, and finally received the "Peer Closed" (Recv returns zero) message
3.
Case: The client program does not close the Socket after sending a lot of data packets and directly
exits the process. Purpose: To simulate the situation where the client program exits and forgets to close the Socket (such as exiting the process through the close icon of the Windows window, but not capturing the corresponding closing event to do normal Exit processing, etc.)
Conclusion: In this case, the server program can receive some TCP messages, and then receive "104: Connection reset by peer" (under Linux) or "10054: An existing connection was forcibly closed by the remote host" ( Windows) error
4.
Case: Kill the process directly when the client program sends a lot of data packets.
Purpose: to simulate the crash of the client program or terminate the process in an abnormal way (such as "kill -9" under Linux or the task manager of Windows to kill the process) Situation
Conclusion: In this case, the server program quickly received the error "104: Connection reset by peer" (under Linux) or "10054: An existing connection was forcibly closed by the remote host" (under Windows)
5.
Case: The client program normally closes the Socket and exits the process (or does not exit the process) after sending a lot of data packets.
Purpose: To simulate that the client normally closes the Socket, the server sends a message to the client before checking that the TCP peer is closed. Situation
conclusion: In this case, after the server program receives and sends some TCP messages, it generates "32: Broken pipe" (under Linux) or "10053: An established connection was aborted by the software in your host machine" ( Windows) error
Summary:
When the TCP connection process exits after forgetting to close the Socket, the program crashes, or the process ends abnormally (Windows client), it will cause the opposite process of the TCP connection to generate "104: Connection reset by peer" ( Under Linux) or "10054: An existing connection was forcibly closed by the remote host" (under Windows) error
When the TCP connection process machine crashes, the system restarts suddenly, the network cable is loose, or the network is disconnected, the connected peer process may not detect any abnormalities, and finally waits for "timeout" before disconnecting the TCP connection
When the TCP connection process closes the Socket normally, the peer process still sends a message to the TCP before the TCP close event is checked, and the Send message will generate "32: Broken pipe" (under Linux) or "10053: An established connection" was aborted by the software in your host machine" (under Windows) error
The server fails, the client:
1. The
server has closed the Socket, and the client sends data.
Purpose: To test when the TCP peer process has closed the Socket, the local process has not detected that the connection is closed. The
conclusion of the message sent by the end : the first packet can be sent successfully, but the second packet failed. The error code is "10053: An established connection was aborted by the software in your host machine" (under Windows) or "32: Broken pipe," SIGPIPE signal received" (under Linux) error
2. The
server
closes the Socket after sending data to TCP, the client sends another packet of data, and then receives the message. Purpose: To test that the Socket is closed after the TCP peer process sends data, and the local process has not detected that the connection is closed. Send a packet of messages, and then receive the message.
Conclusion: The client can successfully send the first packet of data (this will cause the server to send an RST packet <packet verification>). When the client goes to Recv, it is for Windows and Linux programs. There are different manifestations as follows:
Windows client program: Recv failed, the error code is "10053: An established connection was aborted by the software in your host machine"
Linux client program: All message packets can be received normally, and finally received normally The peer closes the message (this is not the same as under Window)
3. The
server
closes the Socket when there is unreceived data in the TCP receive buffer, and the client receives the packet. Purpose: To test when the Socket is closed when there is unreceived data in the TCP receive buffer, Whether the opposite process is normal or not?
Conclusion: In this case, the server will send a RST packet to the opposite end instead of a normal FIN packet (which has been proved by capturing the packet), which will cause the client to be early (the RST packet is preceded by the normal data packet). Received) I received the error "10054: An existing connection was forcibly closed by the remote host" (under Windows) or "104: Connection reset by peer" (under Linux)
Summary:
When the peer process of the TCP connection has closed the Socket, when the local process sends data again, the first packet can be sent successfully (but it will cause the peer to send a RST packet):
If you continue to send data later Will fail, the error code is "10053: An established connection was aborted by the software in your host machine" (under Windows) or "32: Broken pipe, while receiving SIGPIPE signal" (under Linux) error;
afterwards, if you receive data, Under Windows, an error of 10053 will be reported, while under Linux, a normal shutdown message will be received
If there is still unreceived data in the local receiving buffer of the TCP connection and the Socket is closed, the local TCP will send a RST packet to the opposite end instead of the normal FIN packet, which will cause the opposite end to process early (RST The packet is received earlier than the normal data packet) and the error "10054: An existing connection was forcibly closed by the remote host" (under Windows) or "104: Connection reset by peer" (under Linux) is received.