名称解析模型
命名空间是指将 (作为最低) 网络服务的协议和寻址属性与一个或多个友好名称相关联的功能。 目前广泛使用许多命名空间，包括 Internet 的域名系统 (DNS) 、Active Directory 域服务、bindery、NetWare 目录服务 (Novell) 的 NDS 和 X.500。 这些命名空间在组织和实现方式上差异很大。 从 Winsock 名称解析的角度来看，其某些属性尤其重要。
命名空间的类型
可在其中注册服务的三种不同类型的命名空间：
- 动态
- 静态
- 永久
动态命名空间允许服务动态注册到命名空间，并允许客户端在运行时发现可用的服务。 动态命名空间经常依赖于广播来指示网络服务是否持续可用。 动态命名空间的较旧示例包括 NetWare 环境中使用的 SAP) 命名空间 (服务广告协议，以及 AppleTalk 使用的 NBP) 命名空间 (名称绑定协议。 Windows 上使用的 PNRP) 命名空间 (对等名称解析协议是动态命名空间的最新示例。
静态命名空间要求提前注册所有服务，即创建命名空间时。 静态命名空间的一个示例是大多数 TCP/IP 实现使用的主机、协议和服务文件。 在 Windows 上，这些文件通常位于 C：\windows\system32\drivers\etc 文件夹中。
持久性命名空间允许服务动态注册到命名空间。 但是，与动态命名空间不同，永久性命名空间会将注册信息保留在非易失性存储中，直到服务请求将其删除为止。 永久性命名空间由目录服务（例如 X.500 和 NDS (NetWare 目录服务) ）表示。 这些环境允许添加、删除和修改服务属性。 此外，表示目录服务中的服务的服务对象可以具有与服务关联的各种属性。 客户端应用程序最重要的属性是服务的寻址信息。 DNS 是持久命名空间的另一个示例。 尽管可通过编程方式使用 Windows 套接字解析 DNS 名称，但 Windows 中的 DNS 命名空间提供程序不支持使用 Winsock 注册新的 DNS 名称。 必须直接使用 DNS 函数来注册 DNS 名称。 有关详细信息，请参阅 DNS 参考。
命名空间组织
许多命名空间按层次结构排列。 某些项（如 X.500 和 NDS）允许无限嵌套。 其他服务允许将服务合并为单一级别的层次结构或组。 这通常称为 工作组。 构造查询时，通常需要在将从中开始搜索的命名空间层次结构中建立上下文点。
命名空间提供程序体系结构
当然，用于查询各种类型的命名空间并在命名空间中注册信息的编程接口 (，如果支持的) 差异很大。 命名空间提供程序是一种本地驻留的软件，它知道如何在 Winsock 命名空间 SPI 和某些现有命名空间 (之间进行映射，这些命名空间可以在本地实现或通过网络) 访问。 命名空间提供程序体系结构说明如下：
请注意，给定命名空间（例如 DNS）可以在给定计算机上安装多个命名空间提供程序。
如上所述，泛型术语 “服务 ”是指客户端/服务器应用程序的服务器半部分。 在 Winsock 中，服务与 服务类相关联，特定服务的每个实例都有一个 服务名称 ，该名称在服务类中必须是唯一的。 服务类的示例包括 FTP 服务器、SQL Server、XYZ Corp. Employee Info Server 等。如示例所示，某些服务类是众所周知的，而其他服务类是唯一的，特定于特定的垂直应用程序。 在任一情况下，每个服务类都由类名和类标识符表示。 类名不一定是唯一的，但类标识符必须是唯一的。 全局唯一标识符 (GUID) 用于表示服务类标识符。 对于已知服务，类名和类标识符 (GUID) 已预先分配，宏可用于在主机字节顺序 () 和相应的类标识符 GUID 之间转换。 对于其他服务，开发人员选择类名并使用 Uuidgen.exe 实用工具为类标识符生成 GUID。
存在服务类的概念允许建立由特定服务的所有实例共同持有的一组属性。 在将服务类定义为 Winsock 时提供这组属性，称为服务类架构信息。 当服务在主计算机上安装并使其可用时，该服务被视为 实例化，并且其服务名称用于区分服务的特定实例与命名空间可能知道的其他实例。
请注意，服务类的安装仅在执行服务的计算机上进行，而不需要在可能使用该服务的所有客户端上进行。 在可能的情况下，Ws2_32.dll在注册服务实例化或启动服务查询时向命名空间提供程序提供服务类架构信息。 当然，Ws2_32.dll不会存储此信息本身，而是尝试从已指示其提供此数据的命名空间提供程序中检索此信息。 由于无法保证Ws2_32.dll可以提供服务类架构，因此需要此信息的命名空间提供程序必须具有回退机制才能通过特定于命名空间的方式获取该架构。
如上所述，Internet 采用了所谓的以主机为中心的服务模型。 需要查找服务的传输地址的应用程序通常必须先解析已知托管该服务的特定主机的地址。 向此地址添加已知端口号，从而创建完整的传输地址。 为了便于解析主机名， (SVCID_HOSTNAME) 预先分配了一个特殊的服务类标识符。 如果查询成功，将 SVCID_HOSTNAME 指定为服务类，并为服务实例名称指定主机名的查询将返回主机地址信息。
在 Windows 套接字 2 中，与协议无关的应用程序应避免理解传输地址的内部详细信息。 因此，需要先获取主机地址，然后添加端口是有问题的。 为避免这种情况，查询还可以包括特定服务的已知名称和运行该服务所基于的协议，例如 TCP 上的 FTP。 在这种情况下，成功的查询将返回指定主机上指定服务的完整传输地址，并且应用程序不需要检查 sockaddr 结构的内部。
Internet 的域名系统没有定义完善的方法来存储服务类架构信息。 因此，Winsock 的 DNS 命名空间提供程序只能容纳已预先分配服务类 GUID 的已知 TCP/IP 服务。
实际上，这不是一个严重的限制，因为服务类 GUID 已为整个 TCP 和 UDP 端口集预分配，并且宏可用于检索与任何 TCP 或 UDP 端口关联的 GUID，其端口以主机字节顺序表示。 因此，所有熟悉的服务，如 HTTP、FTP、Telnet、Whois 等。得到很好的支持。
继续以服务类为例，FTP 服务的实例名称可能是“alder.intel.com”或“ftp.microsoft.com”，而 XYZ Corp.Employee Info Server 的实例可能名为“XYZ 公司员工信息服务器版本 3.5”。
在前两种情况下，FTP 的服务类 GUID 与作为服务实例名称提供的计算机名称 (组合) 唯一标识所需的服务。 在第三种情况下，可以在服务查询时发现服务所在的主机名，因此服务实例名称不需要包含主机名。
相关主题