| ## Managing Client/Server Binding Information In a DCE environment, clients and their servers frequently reside on different hosts in a network so clients need a way to find servers. Clients need three pieces of information to communicate with a server: · The hostname (or network address) of the host where the server is running · The name of the network transport the server is using · The communication port (endpoint) the server is using for client communications Of course, an application programmer could simply hard-code a server's location information (also called binding information) into the client side of the application where it is immediately available for use. However, this approach requires that a programmer have advance knowledge of precise network details such as host names and available port numbers. Furthermore, servers with hard-coded binding information do not easily adapt to configuration changes. If you move a server to a different host, you need to recompile all of the clients with the server's new hostname. So DCE provides more flexible ways for clients to obtain server bindings. The standard way for clients to find servers is by using CDS and the server host's endpoint map. The following figure provides a high-level example of this method showing how a fictitious dictionary client application on host larry finds a dictionary server on host curly. Server Binding Information 1. When the dictionary server starts up, DCE host software assigns the server a communications port (endpoint), which clients will use to communicate with this server. Here, the endpoint is TCP/IP port 1015. The DCE host software also places the server identification information along with the current endpoint in the host's endpoint map. 2. The dictionary server then advertises its availability to clients by placing (exporting) its host name (usually it's the host address) and the transport it uses to a server entry in CDS. 3. When the dictionary client makes a call to a remote procedure provided by the server, the DCE software on the client queries the CDS server to find the dictionary server's host name and the transport. 4. The client system's host software then queries the endpoint map on host curly to find the dictionary server's endpoint (port 1015). 5. Equipped with all the necessary binding information, the host services on host larry transmit the remote procedure call directly to port 1015 on host curly. Although we have omitted some details in this high-level example, the figure still shows the major binding activities performed by clients and servers. That is, servers place their binding information in CDS and in the host endpoint map where clients look for it. There are other ways for clients to find servers and there are variations on the mechanism we've described. But these alternatives are generally controlled by the applications themselves rather than through conventional DCE administration facilities like dcecp. This topic discussed one basic client/server binding mechanism. The following topics examine the roles played by the endpoint map and by CDS. We will also discuss specific administration tasks for managing binding information in endpoint maps and in CDS. ##