shutdown Function (Windows)

shutdown Function

shutdown Function

The shutdown function disables sends or receives on a socket.

Syntax

C++

int shutdown(
  __in  SOCKET s,
  __in  int how
);

Parameters

s [in]

A descriptor identifying a socket.

how [in]

A flag that describes what types of operation will no longer be allowed. Possible values for this flag are listed in the Winsock2.h header file.

Value	Meaning
SD_SEND 0	Shutdown send operations.
SD_RECEIVE 1	Shutdown receive operations.
SD_BOTH 2	Shutdown both send and receive operations.

Return Value

If no error occurs, shutdown returns zero. Otherwise, a value of SOCKET_ERROR is returned, and a specific error code can be retrieved by calling WSAGetLastError.

Error code	Meaning
WSANOTINITIALISED	A successful WSAStartup call must occur before using this function.
WSAENETDOWN	The network subsystem has failed.
WSAEINVAL	The how parameter is not valid, or is not consistent with the socket type. For example, SD_SEND is used with a UNI_RECV socket type.
WSAEINPROGRESS	A blocking Windows Sockets 1.1 call is in progress, or the service provider is still processing a callback function.
WSAENOTCONN	The socket is not connected (connection-oriented sockets only).
WSAENOTSOCK	Note The descriptor is not a socket.

Remarks

The shutdown function is used on all types of sockets to disable reception, transmission, or both.

If the how parameter is SD_RECEIVE, subsequent calls to the recv function on the socket will be disallowed. This has no effect on the lower protocol layers. For TCP sockets, if there is still data queued on the socket waiting to be received, or data arrives subsequently, the connection is reset, since the data cannot be delivered to the user. For UDP sockets, incoming datagrams are accepted and queued. In no case will an ICMP error packet be generated.

If the how parameter is SD_SEND, subsequent calls to the send function are disallowed. For TCP sockets, a FIN will be sent after all data is sent and acknowledged by the receiver.

Setting how to SD_BOTH disables both sends and receives as described above.

The shutdown function does not close the socket. Any resources attached to the socket will not be freed until closesocket is invoked.

To assure that all data is sent and received on a connected socket before it is closed, an application should use shutdown to close connection before calling closesocket. For example, to initiate a graceful disconnect:

Call WSAAsyncSelect to register for FD_CLOSE notification.
Call shutdown with how=SD_SEND.
When FD_CLOSE received, call recv until zero returned, or SOCKET_ERROR.
Call closesocket.

Note The shutdown function does not block regardless of the SO_LINGER setting on the socket.

Once the shutdown function is called to disable send, receive, or both, there is no method to re-enable send or receive for the existing socket connection.

An application should not rely on being able to reuse a socket after it has been shut down. In particular, a Windows Sockets provider is not required to support the use of connect on a socket that has been shut down.

If an application wants to reuse a socket, then the DisconnectEx function should be called with the dwFlags parameter set to TF_REUSE_SOCKET to close a connection on a socket and prepare the socket handle to be reused. When the DisconnectEx request completes, the socket handle can be passed to the AcceptEx or ConnectEx function.

If an application wants to reuse a socket, the TransmitFile or TransmitPackets functions can be called with the dwFlags parameter set with TF_DISCONNECT and TF_REUSE_SOCKET to disconnect after all the data has been queued for transmission and prepare the socket handle to be reused. When the TransmitFile request completes, the socket handle can be passed to the function call previously used to establish the connection, such as AcceptEx or ConnectEx. When the TransmitPackets function completes, the socket handle can be passed to the AcceptEx function.

Note The socket level disconnect is subject to the behavior of the underlying transport. For example, a TCP socket may be subject to the TCP TIME_WAIT state, causing the DisconnectEx, TransmitFile, or TransmitPackets call to be delayed.

Notes for ATM

There are important issues associated with connection teardown when using Asynchronous Transfer Mode (ATM) and Windows Sockets 2. For more information about these important considerations, see the section titled Notes for ATM in the Remarks section of the closesocket function reference.

Requirements