Name Resolution Model
A name space
refers to some capability to associate (as a minimum) the protocol and
addressing attributes of a network service with one or more human-friendly names.
Many name spaces are currently in wide use including the Internet's Domain Name
System(DNS), the bindery and Netware Directory Services (NDS) from Novell, X.500,
etc. These name spaces vary widely in how they are organized and implemented.
Some of their properties are particularly important to understand from the
perspective of Windows Sockets name resolution.
Types of Name Spaces
There are three different types of name spaces in which a service could be
Dynamic name spaces allow services to register with the name space on the fly,
and for clients to discover the available services at run-time. Dynamic name
spaces frequently rely on broadcasts to indicate the continued availability of a
network service. Examples of dynamic name spaces include the SAP name space
used within a Netware environment and the NBP name space used by Appletalk.
Static name spaces require all of the services to be registered ahead of time,
i.e. when the name space is created. The DNS is an example of a static name
space. Although there is a programmatic way to resolve names, there is no
programmatic way to register names.
Persistent name spaces allow services to register with the name space on the
fly. Unlike dynamic name spaces however, persistent name spaces retain the
registration information in non-volatile storage where it remains until such time as
the service requests that it be removed. Persistent name spaces are typified
by directory services such as X.500 and the NDS (Netware Directory Service).
These environments allow the adding, deleting, and modification of service
properties. In addition, the service object representing the service within the
directory service could have a variety of attributes associated with the service. The
most important attribute for client applications is the service's addressing
Name Space Organization
Many name spaces are arranged hierarchically. Some, such as X.500 and NDS,
allow unlimited nesting. Others allow services to be combined into a single level
of hierarchy or "group." This is typically referred to as a workgroup. When
constructing a query, it is often necessary to establish a context point within a
name space hierarchy from which the search will begin.
Name Space Provider Architecture
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 Windows
Sockets's name space SPI and some existing name space (which could be
implemented locally or be accessed via the network). This is illustrated as follows:
Name Space Provider Architecture
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 ID. The
class name does not necessarily need to be unique, but the class ID must be.
Globally Unique Identifiers (GUIDs) are used to represent service class IDs. For
well-known services, class names and class ID's (GUIDs) have been
pre-allocated, and macros are available to convert between, for example, TCP port numbers
and the corresponding class ID GUIDs. For other services, the developer chooses
the class name and uses the UUIDGEN.EXE
utility to generate a GUID for the class ID.
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 which 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 instantiation 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.
As noted above, 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 in 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). A query
that specifies SVCID_HOSTNAME as the service class and uses the host name the
service instance name will, if the query is successful, return host address
In Windows Sockets 2, applications that are protocol-independent wish to avoid
the need to comprehend the internal details of a transport address. Thus the
need to first get a host address and then add in 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/tcp". In this
case, a successful query will return a complete transport address for the
specified service on the indicated host, and the application will not be required to
"crack open" a sockaddr structure. This is described in more detail below.
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
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.
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages