名稱解析模型
命名空間是指一些將 (關聯為通訊協定和定址網路服務屬性與一或多個易記名稱的最低) 功能。 許多命名空間目前都廣泛使用，包括網際網路的網域名稱系統 (DNS) 、Active Directory 網域服務、bindery、NetWare Directory Services (NDS) ，以及 X.500。 這些命名空間在組織及實作的方式上有很大的差異。 從 Winsock 名稱解析的觀點瞭解其中一些屬性特別重要。
命名空間的類型
有三種不同類型的命名空間可以註冊服務：
- 動態
- 靜態
- 持續性
動態命名空間可讓服務即時向命名空間註冊，並讓用戶端在執行時間探索可用的服務。 動態命名空間經常依賴廣播來指出網路服務的持續可用性。 動態命名空間的舊範例包括 Service Advertising Protocol (NetWare 環境中所使用的 SAP) 命名空間，以及 AppleTalk 所使用的名稱系結通訊協定 (NBP) 命名空間。 Windows 上使用的對等名稱解析通訊協定 (PNRP) 命名空間是動態命名空間的最新範例。
靜態命名空間需要事先註冊所有服務，也就是建立命名空間時。 靜態命名空間的範例是大部分 TCP/IP 實作所使用的主機、通訊協定和服務檔案。 在 Windows 上，這些檔案通常位於 C：\windows\system32\drivers\etc 資料夾中。
持續性命名空間可讓服務即時向命名空間註冊。 不過，不同于動態命名空間，持續性命名空間會將註冊資訊保留在非volatile 儲存體中，直到服務要求移除為止。 持續性命名空間是由 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無法保證可以提供服務類別架構，因此需要這項資訊的命名空間提供者必須具有後援機制，才能透過命名空間特定方式取得它。
如上所述，網際網路已採用以主機為中心的服務模型。 需要尋找服務傳輸位址的應用程式通常必須先解析裝載服務的特定主機位址。 在此位址中，他們會在已知的通訊埠號碼中新增，進而建立完整的傳輸位址。 為了協助解析主機名稱，特殊服務類別識別碼已預先配置 (SVCID_HOSTNAME) 。 指定 SVCID_HOSTNAME 為服務類別的查詢，並在查詢成功時指定服務實例名稱的主機名稱會傳回主機位址資訊。
在 Windows Sockets 2 中，與通訊協定無關的應用程式應該避免需要理解傳輸位址的內部詳細資料。 因此，必須先取得主機位址，然後在埠中新增會造成問題。 為了避免這種情況，查詢也可能包含特定服務的已知名稱，以及服務運作的通訊協定，例如 FTP over TCP。 在此情況下，成功的查詢會傳回指定主機上指定服務的完整傳輸位址，而且不需要應用程式檢查 sockaddr 結構的內部。
網際網路的網域名稱系統沒有定義完善的方法來儲存服務類別架構資訊。 因此，Winsock 的 DNS 命名空間提供者只能容納預先佈建服務類別 GUID 的已知 TCP/IP 服務。
實際上，這不是嚴重的限制，因為服務類別 GUID 已針對整個 TCP 和 UDP 埠預先配置，而且宏可用來擷取與任何 TCP 或 UDP 埠相關聯的 GUID，其埠是以主機位元組順序表示。 因此，所有熟悉的服務，例如 HTTP、FTP、Telnet、Whois 等。受到妥善支援。
繼續我們的服務類別範例，FTP 服務的實例名稱可能是 「alder.intel.com」 或 「ftp.microsoft.com」，而 XYZ Corp 實例則員工資訊伺服器可能命名為 「XYZ Corp. Employee Info Server Version 3.5」。
在前兩種情況下，FTP 的服務類別 GUID 與電腦名稱稱的組合 (提供為服務實例名稱，) 唯一識別所需的服務。 在第三種情況下，可以在服務查詢時間探索服務所在的主機名稱，因此服務實例名稱不需要包含主機名稱。
相關主題