The
shutdown function disables sends or receives on a socket.
Syntax
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. One method to wait for notification that the remote end has sent all its data and initiated a graceful disconnect uses the WSAEventSelect function as follows :
- Call
WSAEventSelect to register for FD_CLOSE notification.
- Call
shutdown with how=SD_SEND.
- When FD_CLOSE received, call
the recv or WSARecv until the function completes with success and indicates that zero bytes were received. If SOCKET_ERROR is returned, then the graceful disconnect is not possible.
- Call
closesocket.
Another method to wait for notification that the remote end has sent all its data and initiated a graceful disconnect uses overlapped receive calls follows :
- Call
shutdown with how=SD_SEND.
- Call
recv or WSARecv until the function completes with success and indicates zero bytes were received. If SOCKET_ERROR is returned, then the graceful disconnect is not possible.
- Call
closesocket.
Note The
shutdown function does not block regardless of the SO_LINGER setting on the socket.
For more information, see the section on Graceful Shutdown, Linger Options, and Socket Closure.
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
| Minimum supported client | Windows 2000 Professional |
| Minimum supported server | Windows 2000 Server |
| Header | Winsock2.h |
| Library | Ws2_32.lib |
| DLL | Ws2_32.dll |
See Also
- Winsock Reference
- Winsock Functions
- AcceptEx
- connect
- ConnectEx
- DisconnectEx
- socket
- TransmitFile
- TransmitPackets
- WSAEventSelect
Send comments about this topic to Microsoft
Build date: 10/29/2009