WSAEventSelect Model

Question

Hi, I am using WSAEventSelect for notification of socket events. So far, everything is cool and works like a charm, but there is one problem.

The client is a .NET application, and the server is written in Winsock C ++. In a .NET application, I use the System.Net.Sockets.Socket class for TCP / IP. When I call the Socket.Shutdown () and Socket.Close () method, I get the FD_CLOSE event on the server, and I'm sure everything is fine. Well, the problem occurs when I check the iErrorCode WSANETWORKEVENTS, which I passed to WSAEnumNetworkEvents. I check it like

if (listenerNetworkEvents.lNetworkEvents & FD_CLOSE) { if (listenerNetworkEvents.iErrorCode[FD_CLOSE_BIT] != 0) { // it comes here // which means there is an error // and the ERROR I got is // WSAECONNABORTED printf("FD_CLOSE failed with error %d\n", listenerNetworkEvents.iErrorCode[FD_CLOSE_BIT]); break; } closesocket(socketArray[Index]); } 

But it fails with the WSAECONNABORTED error. Why is this so?

EDIT: By the way, am I running both the client and the server on the same computer, because of this? And I got the FD_CLOSE event when I do this:

 server.Shutdown(SocketShutdown.Both); // in .NET C#, client code 

Answer 1

I assume that you call Shutdown () and then Close () right after that. This will give the symptom that you see, because it is "shutting the connection closed." Shutdown () initiates a graceful shutdown (TCP FIN), but immediately after it closes () it interrupts this by sending a TCP RST packet to the remote peer. By the way, calling Shutdown (SocketShutdown.Both) also closes the connection, by the way.

The correct template is:

• Turning off the call () with the direction parameter set to “record”, which means that we will not send more data to the remote peer. This causes the stack to send a TCP FIN packet.

• Go back to waiting for Winsock events. When the remote peer will also record, it will also call “End” (“record”), causing its stack to send TCP FIN to your machine and your application will receive the FD_CLOSE event. While waiting, your code should be ready to continue reading from the socket, since the remote peer can still send data.

(Please excuse the pseudo-C # above. I am not saying .NET, only C ++.)

It is assumed that both peers use the same shutdown pattern: each tells the other when it is recording, and then waits for a notification that the remote peer has been written before it closes its socket.

It is important to understand that TCP is a bidirectional protocol: each side can send and receive independently of each other. Closing a socket for reading is a good thing. It is like a conversation with another person, but only conversation and unwillingness to listen. The graceful shutdown protocol says, "I am saying now, I will wait until you stop talking before I leave."