Connection Shutdown

The following describes operations incident to shutting down an established socket connection.

Initiating Shutdown Sequence

A socket connection can be taken down in one of several ways. WSPShutdown (with how equal to SD_SEND or SD_BOTH), and WSPSendDisconnect may be used to initiate a graceful connection shutdown. WSPCloseSocket can be used to initiate either a graceful or abortive shutdown, depending on the linger options invoked by the closing a socket. See below for more information about graceful and abortive shutdowns, and linger options.

Indicating Remote Shutdown

Service providers indicate connection teardown that is initiated by the remote party through the FD_CLOSE network event. Graceful shutdown is also be indicated through WSPRecv when the number of bytes read is 0 for byte-stream protocols, or through a return error code of WSAEDISCON for message-oriented protocols. In any case, a WSPRecv return error code of WSAECONNRESET indicates an abortive shutdown.

Exchanging User Data at Shutdown Time

At connection teardown time, it is also possible (for protocols that support this) to exchange user data between the endpoints. The end that initiates the teardown can call WSPSendDisconnect to indicate that no more data is to be sent and cause the connection teardown sequence to be initiated. For certain protocols, part of this teardown sequence is the delivery of disconnect data from the teardown initiator. After receiving notice that the remote end has initiated the teardown sequence (typically through the FD_CLOSE indication), the WSPRecvDisconnect function may be called to receive the disconnect data (if any).

To illustrate how disconnect data might be used, consider the following scenario. The client half of a client/server application is responsible for terminating a socket connection. Coincident with the termination it provides (through disconnect data) the total number of transactions it processed with the server. The server in turn responds with the cumulative grand total of transactions that it has processed with all clients. The sequence of calls and indications might occur as shown in the following table.

Step (5') must follow step (5), but has no timing relationship with steps (6), (7), or (8).