SPI Basics

The Winsock 2 SPI allows you to develop two types of service providers—transport providers and name space providers. Transport providers (commonly referred to as protocol stacks, such as TCP/IP) are services that supply functions that set up communication, transfer data, exercise data-flow control and error control, and so on. Name space providers are services that associate the addressing attributes of a network protocol with one or more user-friendly names and thus enable protocol-independent name resolution. Service providers are nothing more than Win32 support DLLs that are hooked below Winsock 2's Ws2_32.dll module. They provide the inner workings of many of the calls defined in the Winsock 2 API.

Figure 14-1. Winsock 2's WOSA-compliant architecture

SPI Naming Conventions

The Winsock 2 SPI function prototypes use the following function prefix naming conventions:

• WSP (WinSock Provider) Identifies transport service provider functions
• NSP (name space provider) Identifies name space provider functions
• WPU (Winsock provider upcall) Identifies Ws2_32.dll support functions called by service providers
• WSC (Winsock configuration) Identifies functions for installing service providers in Winsock 2

For example, a function named WSCInstallProvider is simply an SPI configuration function.

Mapping Between Winsock 2 API and SPI Functions

In most cases, when an application calls a Winsock 2 function, Ws2_32.dll calls a corresponding Winsock 2 SPI function to carry out the requested functionality using a specific service provider. For example, select maps to WSPSelect, WSAConnect maps to WSPConnect, and WSAAccept maps to WSPAccept. However, not all Winsock functions have a corresponding SPI function. The following list details these exceptions.

• Support functions such as htonl, htons, ntohl, and ntohs are implemented within Ws2_32.dll and aren't passed down to a service provider. The same holds true for the WSA versions of these functions.
• IP conversion functions such as inet_addr and inet_ntoa are implemented only within Ws2_32.dll.
• All of the IP-specific name conversion and resolution functions in Winsock 1.1 such as getXbyY, WSAAsyncGetXByY, and WSACancelAsyncRequest, as well as gethostname, are implemented within Ws2_32.dll.
• Winsock service provider enumeration and the blocking hook_related functions are implemented within Ws2_32.dll. Thus WSAEnumProtocols, WSAIsBlocking, WSASetBlockingHook, and WSAUnhookBlockingHook do not appear as SPI functions.
• Winsock error codes are managed within Ws2_32.dll. WSAGetLastError and WSASetLastError aren't needed in the SPI.
• The event object manipulation and wait functions—including WSACreateEvent, WSACloseEvent, WSASetEvent, WSAResetEvent, and WSAWaitForMultipleEvents—are mapped directly to native Win32 operating system calls and aren't present in the SPI.

Now you're ready to learn which Winsock APIs are mapped to Winsock 2 service providers. When you develop a service provider, you will find all SPI function prototypes defined in the include file Ws2spi.h.