Shared Sockets in the SPI

Socket sharing between processes in Windows Sockets is implemented as follows. A source process calls WSPDuplicateSocket to obtain a special WSAPROTOCOL_INFOW structure. It uses some interprocess communications (IPC) mechanism to pass the contents of this structure to a target process. The target process then uses the WSAPROTOCOL_INFOW structure in a call to WSPSocket. The socket descriptor returned by this function will be an additional socket descriptor to an underlying socket which thus becomes shared.

It is the service provider's responsibility to perform whatever operations are needed in the source process context and to create a WSAPROTOCOL_INFOW structure that will be recognized when it subsequently appears as a parameter to WSPSocket in the target processes' context. The dwProviderReserved parameter of the WSAPROTOCOL_INFOW structure is available for the service provider's use, and may be used to store any useful context information, including a duplicated handle.

This mechanism is designed to be appropriate for both single-threaded versions of Windows (such as Windows 3.1) and preemptive multithreaded versions of Windows (such as Windows 95 and Windows NT/Windows 2000). Note however, that sockets may be shared amongst threads in a given process without using the WSPDuplicateSocket function, since a socket descriptor is valid in all of a process' threads.

As is described in section Descriptor Allocation, when new socket descriptors are allocated IFS providers must call WPUModifyIFSHandle and nonIFS providers must call WPUCreateSocketHandle.

One possible scenario for establishing and using a shared socket in a handoff mode is illustrated below: