Window Socket Application Failure with Connection Reset Event (152474)

CAUSE

Under certain circumstances, a condition exists with Microsoft TCP/IP where a TCP packet can be sent on a connection that has already closed causing a Reset packet to be issued. This causes the WinSock application to fail with a WSAECONNRESET event.

Detailed Explanation:

In a normal WinSock client-server TCP/IP communication sequence, the following type of conversation could be observed with a Network Monitor product.

   CLIENT               SERVER
   ======               ======
   SYN         -->
            <--      SYN - ACK
   ACK         -->

   TCP (Data - request) -->
            <--      ACK

            <--      TCP (Data - response)
   ACK         -->

      ... potentially many Data/Ack response packets ...

   FIN         -->
            <--      ACK
            <--      FIN
   ACK         -->
				

When the final FIN packet is sent by the server, and the ACK packet returns, the server is free to close the socket created for the client communication. In this instance, the client initiated the closing of communications, followed by the server.

In a WinSock client-server TCP/IP communication sequence that exposes the Connection Reset problem, the following type of conversation could be observed with a Network Monitor product.

   CLIENT               SERVER
   ======               ======
   SYN         -->
            <--      SYN - ACK
   ACK         -->

   TCP (Data - request) -->
            <--      ACK

   FIN         -->
            <--      ACK

            <--      TCP (Data - response)
   ACK         -->

      ... potentially many Data/Ack response packets ...

            <--      FIN
   ACK         -->

   ACK (this is bad) -->

            <--      RESET
   ACK         -->
				

In the problem scenario above, the following events transpired. The client issues a Shutdown on their local socket after they sent the request to the server, notifying the socket that it will not be sending any more data. This causes a FIN packet to be sent very early in the conversation (this is perfectly legitimate programming style). Later, the server issues a FIN to indicate it is done sending data, and the client acknowledges the FIN packet. Due to the way that Delayed Acknowledgments worked, it was possible for another ACK to be sent to the server after the ACK for the FIN packet. If the server has already closed the socket it was communicating with the client on, this will generate a RESET packet to the client.

If the client was still reading data, the RESET packet will cause the client read of data to return in error with a WSAECONNRESET, indicating that the connection was reset.