Namespace Provider Architecture (Windows CE 5.0)
The programmatic interfaces used to query the various types of namespaces and to register information within a namespace, if registration is supported, differ widely. A namespace provider is a locally resident piece of software that knows how to map between the Winsock namespace Service Provider Interface (SPI) and some existing namespace, which could be implemented locally or be accessed through the network.
It is possible for a given namespace, such as DNS, to have more than one namespace provider installed on a given computer.
The generic term service refers to the server-half of a client/server application. In Winsock, a service is associated with a service class, and each instance of a particular service has a service name that must be unique within the service class. Examples of service classes include FTP Server, SQL Server, and Contoso, Ltd. Employee Info Server. As the examples of service classes illustrate, some service classes are well known while others are unique and specific to a particular vertical application. In either case, every service class is represented by both a class name and a class identifier. The class name does not necessarily need to be unique, but the class identifier must be unique. Globally Unique Identifiers (GUIDs) are used to represent service class identifiers. For well-known services, class names and class identifiers (GUIDs) have been pre-allocated, and macros are available to convert between, for example, TCP port numbers, in host-byte order, and the corresponding class identifier GUIDs. For other services, you need to choose the class name and use the Uuidgen.exe utility to generate a GUID for the class identifier.
The notion of a service class exists to allow a set of attributes to be established that are held in common by all instances of a particular service. This set of attributes is provided at the time the service class is defined to Windows Sockets, and is referred to as the service class schema information. When a service is installed and made available on a host machine, that service is considered instantiated, and its service name is used to distinguish a particular instance of the service from other instances that may be known to the namespace.
Note that the installation of a service class only needs to occur on machines where the service executes, not on all of the clients that may utilize the service. Where possible, Ws2.dll provides service class schema information to a namespace provider at the time an instantiation of a service is to be registered or a service query is initiated. Ws2.dll does not store this information, but attempts to retrieve it from a namespace provider that has indicated its ability to supply this data. Because there is no guarantee that Ws2.dll can supply the service class schema, namespace providers that need this information must have a fallback mechanism to obtain it through namespace-specific means.
The Internet has adopted what can be termed a host-centric service model. Applications needing to locate the transport address of a service generally must first resolve the address of a specific host known to host the service. To this address they add the well-known port number and thus create a complete transport address. To facilitate the resolution of host names, a special service class identifier has been pre-allocated, SVCID_HOSTNAME.
In Winsock, applications that are protocol-independent should avoid the need to comprehend the internal details of a transport address. Thus, the need to get a host address first and then add the port is problematic. To avoid this, queries may also include the well-known name of a particular service and the protocol over which the service operates, such as FTP or TCP. In this case, a successful query returns a complete transport address for the specified service on the indicated host, and the application is not required to open a sockaddr structure.
The Internet's Domain Name System does not have a well-defined means to store service class schema information. As a result, DNS namespace providers can only accommodate well-known TCP/IP services for which a service class GUID has been pre-allocated.
In practice, this is not a serious limitation because service class GUIDs have been pre-allocated for the entire set of TCP and UDP ports, and macros are available to retrieve the GUID associated with any TCP or UDP port with the port expressed in host-byte order. Thus, all familiar services, such as FTP and Telnet, are well supported.
Continuing the service class example, instance names of the FTP service may be venus.contoso.com or rhino.microsoft.com while an instance of the Contoso Ltd. Employee Info Server might be named Contoso, Ltd. Employee Info Server Version 3.5.
In the first two cases, the combination of the service class GUID for FTP and the machine name, supplied as the service instance name, uniquely identify the desired service. In the third case, the host name where the service resides can be discovered at service query time, so the service instance name does not need to include a host name.
See Also
Protocol-Independent Name Resolution
Send Feedback on this topic to the authors