伺服器程式會監聽端點以接收來自用戶端的請求。 端點字串的語法取決於您所使用的通訊協議順序。 例如,TCP/IP 的端點是埠號碼,而命名管道的端點語法是有效的管道名稱。
端點有兩種類型:已知且動態。 您的程式選擇的端點類型決定分散式應用程式或運行時期程式庫是否指定端點。
本節討論端點,並提供有關如何尋找端點的資訊。 它會組織成下列主題:
- 使用 Well-Known 端點
- 使用動態端點
- 將 Well-Known 端點匯出至端點對應資料庫
注意
靜態端點 和 已知端點 是等同的,可以互換使用。
用戶端應用程式可以使用端點對應來判斷伺服器程式目前是否正在執行。 您的用戶端可以呼叫 RpcMgmtInqIfIds、RpcMgmtEpEltInqBegin,以及 RpcMgmtEpEltInqDone,以查看伺服器是否已在端點映射中註冊它所需的特定介面。
使用已知的端點
已知的端點是伺服器程式每次執行時所使用的預先指派端點。 因為伺服器一律會接聽該特定端點,所以用戶端一律會嘗試連線到該端點。 已知端點通常是由負責傳輸通訊協議的授權單位指派。 因為伺服器主計算機有有限數目的可用端點,因此強烈建議應用程式開發人員不要使用已知的端點。 動態端點的另一個優點是,其可簡化系統的長期管理和維護。
分散式應用程式可以在字串中指定已知的端點,並將該字串串當做參數傳遞至函式,RpcServerUseProtseqEp。 或者,端點字串可以出現在IDL檔案介面標頭中,做為 [ 端點] 介面屬性的一部分。
您可以使用兩種方法來實作已知的端點:
- 指定字串系結中的所有資訊
- 將已知的端點儲存在名稱服務資料庫中
您可以在開發系結時,將建立系結所需的所有資訊寫入分散式應用程式。 用戶端可以直接在字串中指定已知的端點、呼叫 RpcStringBindingCompose 來建立包含所有系結資訊的字串,並將此字串提供給函式 RpcBindingFromStringBinding 以取得句柄。 用戶端和伺服器可以硬式編碼來使用已知的端點,或寫入端點資訊,讓端點資訊來自命令行、數據檔、組態檔或IDL檔案。
用戶端應用程式也可以查詢名稱服務資料庫,以取得已知的端點資訊。
使用動態端點
特定伺服器和特定通訊協定序列的端點數目通常會受到限制。 例如,當您使用 ncacn_ip_tcp 通訊協定序列時,表示 RPC 網路通訊是使用 TCP/IP 進行,只有有限的埠數目可用(大部分系統只有 1025 到 5000 個開啟的範圍)。 RPC 執行時間連結庫可讓您視需要動態指派端點。 由於可能的介面 UUID 數目實際上不受限制,因此使用介面 UUID 來指示呼叫提供更多擴充空間和更大的彈性。
根據預設,RPC 運行時間連結庫函式會在查詢名稱服務資料庫時搜尋端點資訊。 如果端點是動態的,名稱服務資料庫將不會包含端點資訊。 不過,查詢會為您的用戶端程式提供伺服器的名稱。 然後,它可以搜尋伺服器的端點映射。
如果客戶端需要使用動態端點進行遠端程序呼叫,慣用的方法是在部分綁定的句柄上進行呼叫。 RPC 執行環境會以透明方式解析端點。 此方法優於使用 RpcEpResolveBinding 函式,因為它允許在 RPC 執行時期中使用進階快取機制。
如果需要更明確的端點選取控制權,用戶端可以呼叫 RpcMgmtEpEltInqBegin、RpcMgmtEpEltInqNext和 RpcMgmtEpEltInqDone 函式來一次搜尋端點地圖的條目。
將已知的端點匯出至端點對應資料庫
可以混合這兩種方法來尋找端點,特別是當分散式系統從已知的端點模型轉換為動態端點模型時。 在這類轉換中,伺服器的中繼版本會使用已知的端點,但它也會向端點對應資料庫註冊已知的端點。 此方法可讓使用已知端點及動態端點的用戶端進行連線。 升級所有伺服器之後,只能部署使用動態端點的新用戶端版本。 升級所有客戶端之後,最終伺服器版本就可以停止使用已知的端點,並只開始使用動態端點。
此方法允許從已知端點開始的應用程式轉換路徑,但想要移轉至動態端點,而不需要同時更新所有伺服器和用戶端。