| Platform SDK: Windows Sockets |
Naturally, the programmatic interfaces used to query the various types of name spaces and to register information within a name space (if supported) differ widely. A name space provider is a locally-resident piece of software that knows how to map between the Windows Sockets name space SPI and some existing name space (which could be implemented locally or accessed through the network). This is illustrated as follows:
Note Note that it is possible for a given name space, say DNS, to have more than one name space provider installed on a given machine.
As mentioned above, the generic term service refers to the server-half of a client/server application. In Windows Sockets, a service is associated with a service class, and each instance of a particular service has a service name which must be unique within the service class. Examples of service classes include FTP Server, SQL Server, XYZ Corp. Employee Info Server, etc.
As the example attempts to illustrate, some service classes are well known while others are very 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. Globally Unique Identifiers (GUIDs) are used to represent service class IDs. 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 and the corresponding class identifier GUIDs. For other services, the developer chooses the class name and uses 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 supplied to Windows Sockets at the time the service class is defined, and is referred to as the service class schema information. The Ws2_32.dll in turn relays this information to all active name space providers. When an instance of a service is installed and made available on a host machine, its service name is used to distinguish this particular instance from others that may be known to the name space.
Note that the installation of a service class only needs to occur on machines where the service executes, not on all of the clients which may utilize the service. Where possible, the Ws2_32.dll will provide service class schema information to a name space provider at the time an instance of a service is to be registered or a service query is initiated. The Ws2_32.dll does not, of course, store this information itself, but attempts to retrieve it from a name space provider that has indicated its ability to supply this data. Since there is no guarantee that the Ws2_32.dll will be able to supply the service class schema, name space providers that need this information must have a fallback mechanism to obtain it through name space-specific means.
The Internet's Domain Name System does not have a well-defined means to store service class schema information. As a result, DNS name space providers will only be able to accommodate well-known TCP/IP services for which a service class GUID has been preallocated. In practice, this is not a serious limitation since service class GUIDs have been preallocated for the entire set of TCP and UDP ports, and macros are available to retrieve the GUID associated with any TCP or UDP port. Thus, all of the familiar services such as ftp, telnet, whois, etc. are well supported. When querying for these services, by convention the host name of the target machine is the service instance name.
Continuing with our service class example, instance names of the ftp service may be "alder.intel.com" or "rhino.microsoft.com" while an instance of the XYZ Corp. Employee Info Server might be named "XYZ Corp. 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.