The Windows Sockets WSADuplicateSocket
function returns a WSAPROTOCOL_INFO structure that can be used to create a
new socket descriptor for a shared socket.
int WSADuplicateSocket (
| SOCKET s,
| DWORD dwProcessId,
| LPWSAPROTOCOL_INFO lpProtocolInfo
[in] Specifies the local socket descriptor.
[in] Specifies the ID of the target process for which the shared socket will
[out] A pointer to a buffer allocated by the client that is large enough to
contain a WSAPROTOCOL_INFO structure. The service provider copies the protocol
info structure contents to this buffer.
This function is used to enable socket sharing between processes. A source
process calls WSADuplicateSocket
to obtain a special WSAPROTOCOL_INFO structure. It uses some interprocess
communications (IPC) mechanism to pass the contents of this structure to a target
process, which in turn uses it in a call to WSASocket
to obtain a descriptor for the duplicated socket. Note that the special
WSAPROTOCOL_INFO structure may only be used once by the target process.
Sockets can be shared among threads in a given process without using the WSADuplicateSocket
function, since a socket descriptor is valid in all of a process's threads.
One possible scenario for establishing and using a shared socket in a handoff
mode is illustrated below:
- WSASocket, WSAConnect
- Request target process ID
- Receive process ID request and respond
- Receive process ID
- Call WSADuplicateSocket to get a special WSAPROTOCOL_INFO structure
- Send WSAPROTOCOL_INFO structure to target
- Receive WSAPROTOCOL_INFO structure
||8) Call WSASocket to create shared socket descriptor.
||9)Use shared socket for data exchange
If no error occurs, WSADuplicateSocket
returns zero. Otherwise, a value of SOCKET_ERROR is returned, and a specific
error code may be retrieved by calling WSAGetLastError
The descriptors that reference a shared socket may be used independently as
far as I/O is concerned. However, the Windows Sockets interface does not
implement any type of access control, so it is up to the processes involved to
coordinate their operations on a shared socket. A typical use for shared sockets is to
have one process that is responsible for creating sockets and establishing
connections, hand off sockets to other processes which are responsible for
Since what is duplicated are the socket descriptors and not the underlying
socket, all of the state associated with a socket is held in common across all the
descriptors. For example a setsockopt
operation performed using one descriptor is subsequently visible using a getsockopt
from any or all descriptors. A process may call closesocket
on a duplicated socket and the descriptor will become deallocated. The
underlying socket, however, will remain open until closesocket
is called by the last remaining descriptor.
Notification on shared sockets is subject to the usual constraints of WSAAsyncSelect
. Issuing either of these calls using any of the shared descriptors cancels
any previous event registration for the socket, regardless of which descriptor
was used to make that registration. Thus, for example, a shared socket cannot
deliver FD_READ events to process A and FD_WRITE events to process B. For
situations when such tight coordination is required, it is suggested that developers
use threads instead of separate processes.
||A successful WSAStartup must occur before using this function.
||The network subsystem has failed.
||Indicates that one of the specified parameters was invalid.
||A blocking Windows Sockets 1.1 call is in progress, or the service provider is
still processing a callback function.
||No more socket descriptors are available.
||No buffer space is available. The socket cannot be created.
||The descriptor is not a socket.
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages