When you develop your distributed application, provide the application users with a method for specifying the name under which they can register the application in the name-service database. This method can consist of a data file, command-line input, or dialog box.
Though the RPC name-service architecture supports various methods for organizing an application's server entries, it is optimized for look-ups. As a result, frequent updates can hinder the performance of both the name service and the application. To avoid exporting information unnecessarily, choose a design that lets the server determine whether its information is in the name-service database. In addition, each server instance should export to its own entry name. Otherwise, it will be very difficult for an instance to change its supported object UUIDs or protocol sequences without disturbing another instance's information.
Following is a method that avoids these pitfalls and provides good performance, whether you use the Microsoft Locator or another name service.
To begin with, design your application so the first time a given server instance starts up, it picks a unique server-entry name and saves this name in an .INI file along with the application's other configuration information. Then, have it export its binding handles and object UUIDs, if any, to its name-service entry.
Subsequent invocations of the server instance should check that the name-service entry is present and contains the correct set of object UUIDs and binding handles. A missing entry may mean that an administrator removed it, or that a power outage caused the name-service information to be lost. It is important to verify that the binding handles in the entry are correct; if an administrator adds TCP/IP support to a computer, for example, RPC servers will listen on that protocol sequence when they call RpcServerUseAllProtseqs. However, if the server does not update the name-service entry, clients will not be informed that TCP is supported.
When the client imports, it should specify NULL as the entry name. Specifying NULL causes the Microsoft Locator to search for the interface in all name-service entries in the client machine's domain or workgroup, thus finding the information for every instance.
If you use object UUIDs to represent well-known objects such as printers, you can use a variation of this method. Instead of exporting bindings to one entry, design your application so each instance creates an entry for each supported object, such as "/.:/printers/Laser1" and "/.:/printers/Laser2." Then, have the server export its binding handles to each server entry, along with the object UUID relevant to that entry.
In this case, a client can look up a resource by name by importing from the relevant server entry; it does not require the object UUID of the resource. If it has the resource UUID but not the name, it can import from the null entry.