名稱解析模型
命名空間 是指將網路服務的通訊協議和尋址屬性與一或多個易記名稱產生關聯（最低）的一些功能。 許多命名空間目前都在廣泛使用中，包括 Internet 的 功能變數名稱系統（DNS）、Active Directory Domain Services、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 可以提供服務類別架構，因此需要此資訊的命名空間提供者必須有後援機制，才能透過命名空間特定方式取得它。
如上所述，因特網已採用可稱為主機為中心的服務模型。 需要找出服務傳輸位址的應用程式通常必須先解析已知裝載服務的特定主機位址。 在此位址中，他們會在已知的埠號碼中新增 ，從而建立完整的傳輸位址。 為了方便解析主機名，已預先配置特殊服務類別標識碼（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 公司資訊伺服器的實例可能會命名為 “XYZ Corp. Employee Info Server 3.5 版”。
在前兩種情況下，FTP 的服務類別 GUID 和計算機名稱的組合會唯一識別所需的服務。 第三個案例中，可以在服務查詢時間探索服務所在的主機名，因此服務實例名稱不需要包含主機名。
相關主題