Layered Protocols and Provider Chains (Windows Embedded CE 6.0)
1/6/2010
Winsock supports layered protocols. A layered protocol implements only higher-level communications functions while relying on an underlying transport stack for the actual exchange of data with a remote endpoint. An example of this type of layered protocol is a security layer that adds a protocol to the socket connection process in order to perform authentication and establish an encryption scheme. Such a security protocol generally requires the services of an underlying and reliable transport protocol such as Transmission Control Protocol (TCP) or Sequenced Packed Exchange (SPX).
The term base protocol refers to a protocol, such as TCP or SPX, that is fully capable of performing data communications with a remote endpoint. A layered protocol is a protocol that cannot stand alone, and a provider chain is one or more layered protocols strung together and anchored by a base protocol.
The following illustration shows Winsock with only a base provider of TCP/IPv4 installed.
.gif "Ee493713.79bd0324-d09b-47c2-b852-5400808f5008(en-US,WinEmbedded.60).gif")
The base provider has a chain identifier, that is a Globally Unique Identifier (GUID).
Note
These illustrations show a simplified view of provider chains. This model is the same for each base provider.
You can create a provider chain if providers at both the upper and lower edges of the chain support the Winsock SPI.
The following illustration shows the provider chains when you install an Encryption LSP over the TCP/IPv4 base provider.
.gif "Ee493713.9dab2a35-1c43-4223-9bc3-0a1450ce560b(en-US,WinEmbedded.60).gif")
Each time an LSP is installed, the original base chain remains, and a new chain is created that has the added LSP and a unique identifier. When the provider chain 0xAAAA is used, TCP/IPv4 data is encrypted or decrypted between TCP/IP and Winsock.
Winsock uses the address family, socket type, and protocol that is passed into socket to determine which chain is best. Or, to use a specific chain, you can call WSASocket and pass the appropriate WSAPROTOCOL_INFO structure.
Note
Winsock verifies that all sockets that are passed to select are from the same provider. Sockets are considered to be from the same service provider if the WSAPROTOCOL_INFO structures describing their protocols have the same ProviderId value. If the ProviderId values do not match, the select call fails and the socket is not passed to any providers.
Note
Although you can not call select with sockets created by different provider chains, Winsock determines that TCP/IPv4, TCP/IPv6, UDP/IPv4, UDP/IPv6, and Bluetooth are from the same provider because they are all handled by the same base provider, wspm.dll.
The following illustration shows the provider chains when you install an Auth LSP over the TCP/IPv4 base provider.
.gif "Ee493713.3ec522b9-12e6-4194-90a5-11efcd60498b(en-US,WinEmbedded.60).gif")
The new provider chain is now available with the Auth LSP. When the provider chain 0xFFFF is used, TCP/IPv4 data is not only encrypted or decrypted between TCP/IP and Winsock, but it is also authenticated.
Note
An LSP should not modify an unrecognized handle. It should pass the handle to the next lower level.
This illustration shows the importance of the LSP installation order. The connection can be authenticated before it is encrypted, but might fail authentication if it is encrypted first. For information about installing an LSP and setting the installation order, see Installing an LSP.
The WSAPROTOCOL_INFO structure refers to the provider chain as a whole and describes the explicit order in which the layered protocols are joined. Because only base protocols and provider chains are directly usable by applications, they are the only ones listed when the installed protocols are enumerated with the WSAEnumProtocols function.
An application uses the WSAEnumProtocols function to determine which transport protocols and provider chains are present, and to obtain information about each one as that information is contained in the associated WSAPROTOCOL_INFO structure.
In most instances, there is a single WSAPROTOCOL_INFO structure for each protocol or provider chain. However, some protocols exhibit multiple behaviors. For example, the SPX protocol is message-oriented. That is, the network preserves the sender's message boundaries, but the receiving socket can ignore these message boundaries and treat them as a byte stream. Consequently, two different WSAPROTOCOL_INFO structure entries could exist for SPX, one for each behavior.
Applications that need to be protocol-independent are encouraged to select a protocol on the basis of its suitability rather than on the basis of the values assigned to their socket_type or protocol parameters. Protocol suitability is indicated by the communications attributes, such as message-versus-byte stream, and reliable-versus-unreliable, that are contained in the WSAPROTOCOL_INFO structure. Selecting protocols on the basis of suitability as opposed to on the basis of well-known protocol names and socket types lets protocol-independent applications take advantage of new transport protocols and their associated media types, as these become available.
The server half of a client/server application benefits by establishing listening sockets on all suitable transport protocols. Then, the client can establish its connection using any suitable protocol. For example, this lets a client application be unmodified whether it is running on a desktop system, connected through a Local Area Network (LAN), or on a laptop using a wireless network.