This section summarises the content on this page (read on for the full tutorial):
The shutdown API request results in the TCPIP stack sending a shutdown request to the partner application’s system. The partner application will typically be notified by normal completion of a receive but with 0 length (referred to as EOF in the unix world). Note that if the local system simply closed the socket, without shutting down the connection, then the partner application may be notified with a connection reset error rather than EOF.
With some APIs the direction of shutdown can be specified e.g. shutdown for write notifies a partner app that no more data will arrive on this connection. In this case the local app should wait for data or an EOF response when the partner app issues shutdown.
Waiting for a partner app after issuing shutdown can lead to delayed connection clean-up, so typically app programmers will issue shutdown and then immediately close the socket. The idea being that shutdown reaches the partner before the connection reset and avoids error notifications at the partner app.
Close indicates that the app no longer requires use of the socket and that the TCPIP stack can clean up all resources used for that socket. After close completes the app can also clean up its socket related resources.
If you have this socket registered with an active select, don’t cancel and re-issue the select minus this socket. Simply turn off the socket in the socket maps/lists so that it will not be specified on subsequent select requests.