共用方式為

名稱服務應用程式指導方針

  • 發行項

當您開發分散式應用程式時，您必須為應用程式使用者提供方法，以指定要在名稱服務資料庫中註冊應用程式的名稱。 這個方法可以包含資料檔案、命令列輸入或對話方塊。

雖然 RPC 名稱服務架構支援各種方法來組織應用程式的伺服器專案，但它已針對查閱進行優化。 因此，經常更新可能會阻礙名稱服務和應用程式的效能。 若要避免不必要地匯出資訊，請選擇可讓伺服器判斷其資訊是否在名稱服務資料庫中的設計。 此外，每個伺服器實例都應該匯出至自己的專案名稱。 否則，實例很難變更其支援的物件 UUID 或通訊協定序列，而不會干擾另一個實例的資訊。

無論網路使用的名稱為何，下列方法都會避免這些陷阱並提供良好的效能。

首先，請設計您的應用程式，以便第一次啟動指定的伺服器實例時，它會挑選唯一的伺服器專案名稱，並將此名稱儲存在登錄中，以及應用程式的其他組態資訊。 然後，將其系結控制碼和物件 UUID 匯出至其名稱服務專案。

伺服器實例的後續調用應該檢查名稱服務專案是否存在，並包含正確的物件 UUID 和系結控制碼集。 遺漏的專案可能表示系統管理員已將其移除，或電源中斷導致名稱服務資訊遺失。 請務必確認專案中的系結控制碼是否正確;如果系統管理員將 TCP/IP 支援新增至電腦，例如，RPC 伺服器會在呼叫 RpcServerUseAllProtseqs時接聽該通訊協定順序。 不過，如果伺服器未更新名稱服務專案，用戶端將不會收到支援 TCP 的通知。

當用戶端匯入時，它應該將 Null 指定為專案名稱。 指定 Null 會導致 Microsoft RPC 程式庫函式搜尋用戶端電腦網域或工作組中所有名稱服務專案中的介面，進而尋找每個實例的資訊。

如果您使用物件 UUID 來代表已知的物件，例如印表機，您可以使用此方法的變化。 不要將系結匯出至一個專案，而是設計您的應用程式，讓每個實例為每個支援的物件建立一個專案，例如 「/.：/printers/Laser1「 和 」/.：/印表機/雷射2。」然後，讓伺服器將其系結控制碼匯出至每個伺服器專案，以及與該專案相關的物件 UUID。

在此情況下，用戶端可以從相關的伺服器專案匯入，依名稱查閱資源;它不需要資源的物件 UUID。 如果資源為 UUID，但不是名稱，則可以從 Null 專案匯入。