Transport Division of Responsibilities Between DLL and Service Providers

This section provides an overview of the division of responsibility between the WS2_32.DLL and transport service providers.

WS2_32.DLL Functionality for Transport

The major task of the data transport portion of the WS2_32.DLL is to serve as a sort of "traffic manager" between service providers and applications. Consider several different service providers interacting with the same application. Each service provider interacts strictly with the WS2_32.DLL. The WS2_32.DLL takes care of (1) selecting an appropriate service provider for creating sockets based on a protocol description and (2) forwarding application procedure calls involving a socket to the appropriate service provider that created or controls that socket. Service providers are unaware that any of this is happening. They do not need to be concerned about the details of cooperating with one another or even the existence of other service providers. By abstracting the service providers into a consistent DLL interface and performing this automatic traffic routing function, the WS2_32.DLL allows applications to interact with a variety of providers without requiring the applications to be aware of the divisions between providers, where different providers are installed.

The WS2_32.DLL relies on the parameters of the API socket creation functions (socket and WSASocket) to determine which service provider to utilize. The selected transport service provider will be invoked via the WSPSocket function. In the case of the socket function, the WS2_32.DLL finds the first entry in the set of installed WSAPROTOCOL_INFOW structures that matches the values supplied in the tuple formed by the (address family, socket type, protocol) parameters. To preserve backward compatibility, the WS2_32.DLL treats the value of zero for either address family or socket type as a wild card value. The value of zero for protocol is not considered a wild card value by the WS2_32.DLL unless such behavior is indicated for a particular protocol by having the PFL_MATCHES_PROTOCOL_ZERO flag set in the WSAPROTOCOL_INFOW structureure.

For the WSASocket function, if NULL is supplied for lpProtocolInfo, the behavior is exactly as just described for socket. If a WSAPROTOCOL_INFO structure is referenced, however, the WS2_32.DLL does not perform any matching function but immediately relays the socket creation request to the transport service provider associated with the indicated WSAPROTOCOL_INFO structure. The values for the (address family, socket type, protocol) tuple are supplied intact to the service provider in the WSPSocket function. Service providers are free to ignore or pay attention to the values of the (address family, socket type, protocol) parameters as is appropriate, but they must not indicate an error condition when the value of either address family or socket type is zero. In addition, service providers must not indicate an error condition when the manifest constant FROM_PROTOCOL_INFO is contained in any of the (address family, socket type, protocol) parameters. This value simply indicates that the application wishes to use the values found in the corresponding fields of the WSAPROTOCOL_INFO structure: (iAddressFamily, iSocketType, iProtocol).

As part of socket creation a service provider informs the WS2_32.DLL about the association between itself and the new socket by means of parameters passed to WPUCreateSocketHandle or WPUModifyIFSHandle. The WS2_32.DLL keeps track of this association between socket handles and particular service providers. Whenever an application interface function that refers to a socket handle is called, the WS2_32.DLL looks up the association and calls the corresponding service provider interface function of the appropriate service provider.

In addition to its major "traffic routing" service, the WS2_32.DLL provides a number of other services such as protocol enumeration, socket descriptor management (allocation, deallocation, and context value association) for non-file-system service providers, blocking hook management on a per-thread basis, byte swapping utilities, queuing of asynchronous procedure calls (APCs) to facilitate invocation of I/O completion routines, and version negotiation between applications and the WS2_32.DLL, as well as between the WS2_32.DLL and service providers.

Transport Service Provider Functionality

Service providers implement the actual transport protocol which includes such functions as setting up connections, transferring data, exercising flow control and error control, etc. The WS2_32.DLL has no knowledge about how requests to service providers are realized; this is up to the service provider implementation. The implementation of such functions may differ greatly from one provider to another. Service providers hide the implementation-specific details of how network operations are accomplished.

Transport service providers can be broadly divided into two categories: those whose socket descriptors are real file system handles are hereafter referred to as Installable File System (IFS) providers. The remainder are referred to as non-IFS providers. The WS2_32.DLL always passes the transport service provider's socket descriptor on up to the Windows Sockets application, so applications are free to take advantage of socket descriptors that are file system handles if they so choose.

To summarize: service providers implement the low-level network-specific protocols. The WS2_32.DLL provides the medium-level traffic management that interconnects these transport protocols with applications. Applications in turn provide the policy of how these traffic streams and network-specific operations are used to accomplish the functions desired by the user.