名称解析模型
命名空间 是指将协议（最低）与一个或多个友好名称的网络服务的属性相关联（最低）的功能。 许多命名空间目前广泛使用，包括 Internet 的 域名系统（DNS）、Active Directory 域服务、来自 Novell 的 bindery、NetWare Directory Services （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 Server、SQL Server、XYZ 公司员工信息服务器等。如示例所示，一些服务类是众所周知的，而另一些服务类是唯一的，特定于特定的垂直应用程序。 无论哪种情况，每个服务类都由类名和类标识符表示。 类名不一定是唯一的，但类标识符必须是唯一的。 全局唯一标识符（GUID）用于表示服务类标识符。 对于已知服务，已预先分配类名称和类标识符（GUID），并且宏可用于在 TCP 端口号（以主机字节顺序）和相应的类标识符 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 公司实例的员工信息服务器可能名为“XYZ 公司员工信息服务器版本 3.5”。
在前两种情况下，FTP 的服务类 GUID 与计算机名称（作为服务实例名称提供）的组合唯一标识所需的服务。 第三种情况下，可以在服务查询时发现服务所在的主机名，因此服务实例名称不需要包含主机名。
相关主题