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

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

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

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

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

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

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

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

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