A name space provider implements an interface mapping between the Windows Sockets 2 name space SPI and the native programmatic interface of an existing name service such as DNS, X.500, Netware Directory Services (NDS), etc. While a name space provider supports exactly one name space, it is possible for multiple providers for a given name space to be installed. It is also possible for a single DLL to instantiate multiple different name space providers. As name space providers are installed, a catalog of WSANAMESPACE_INFO structures is maintained. An application may use WSAEnumNameSpaceProviders to discover which name spaces are supported on a machine. Refer to Section Name Resolution Service Provider Requirements for detailed information.
Windows Sockets 2 fully supports the TCP/IP-specific name resolution facilities found in Windows Sockets version 1.1. It does this by including the set of GetXbyY functions in the SPI, however the treatment of this set of functions is somewhat different from the rest of the SPI functions. The GetXbyY functions appearing in the SPI are prefaced with GETXBYYSP_, and are summarized as follows:
Berkeley style functions
| SPI Function Name | Description |
|---|---|
| GETXBYYSP_gethostbyaddr | Supply a hostent structure for the specified host address |
| GETXBYYSP_gethostbyname | Supply a hostent structure for the specified host name |
| GETXBYYSP_getprotobyname | Supply a protoent structure for the specified protocol name |
| GETXBYYSP_getprotobynumber | Supply a protoent structure for the specified protocol number |
| GETXBYYSP_getservbyname | Supply a servent structure for the specified service name |
| GETXBYYSP_getservbyport | Supply a servent structure for the service at the specified port |
| GETXBYYSP_gethostname | Return the standard host name for the local machine |
Async style functions
| SPI Function Name | Description |
|---|---|
| GETXBYYSP_WSAAsyncGetHostByAddr | Supply a hostent structure for the specified host address |
| GETXBYYSP_WSAAsyncGetHostByName | Supply a hostent structure for the specified host name |
| GETXBYYSP_WSAAsyncGetProtoByName | Supply a protoent structure for the specified protocol name |
| GETXBYYSP_WSAAsyncGetProtoByNumber | Supply a protoent structure for the specified protocol number |
| GETXBYYSP_WSAAsyncGetServByName | Supply a servent structure for the specified service name |
| GETXBYYSP_WSAAsyncGetServByPort | Supply a servent structure for the service at the specified port |
| GETXBYYSP_WSACancelAsyncRequest | Cancel an asynchronous GetXbyY operation |
The syntax and semantics of these GetXbyY functions are exactly the same as is documented in the Windows Sockets 2 API Specification and are, therefore, not repeated in this document.
The Windows Sockets 2 DLL allows exactly one service provider to offer these services. Therefore, there is no need to include pointers to these functions in the proc table received from service providers at startup time. In 32 bit environments the path to the DLL which implements these functions is retrieved from the registry key named:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WinSock2\
Parameters\GetXByYLibraryPath
Warning How the path is obtained in 16 bit environments has not yet been determined.
A default GetXbyY service provider is integrated into the standard Windows Sockets 2 runtime components. This default provider implements all of the the above functions, thus it is not required for these functions to be implemented by any name space provider. However, a name space proivder is free to provide any or all of these functions (and thus override the defaults) by simply storing the string which is the path to the DLL which implements these functions in the indicated registry key. Any of the GetXbyY functions not exported by the named provider DLL will be supplied via the built-in defaults. Note, however, that if a provider elects to supply any of the async version of the GetXbyY functions, he should supply all of the async functions so that the cancel operation will work appropriately.
For 32 bit environments, the current implementation of the default GetXbyY service provider resides within Microsoft's WSOCK32.DLL. Depending on how the TCP/IP settings have been established via the control panel, name resolution will occur using either DNS or local host files. When DNS is used, the default GetXbyY service provider uses standard Windows Sockets 1.1 API calls to communicate with the DNS server. These transactions will occur using whatever TCP/IP stack is configured as the default TCP/IP stack. Two special cases occurs, however, deserve special mention.
The default implementation of GETXBYYSP_gethostname obtains the local host name from the registry. This will correspond to the name assigned to "my computer". The default implementation of GETXBYYSP_gethostbyname and GETXBYYSP_WSAAsyncGetHostByName always compares the supplied host name with the local host name. If they match, the default implementation uses a private interface to probe the Microsoft TCP/IP stack in order to discover its local IP address. Thus, in order to be completely independent of the Microsoft TCP/IP stack, a name space provider must implement both GETXBYYSP_gethostbyname and GETXBYYSP_WSAAsyncGetHostByName.