OSF DCE Administration Guide--Core Components

DCE Application Administration
administrative authority. So most servers use dynamic endpoints. When a server starts
up, the RPC runtime library gets an available endpoint from the operating system and
registers it in the host endpoint map.
Because a server can be assigned a different endpoint each time it starts, the endpoint
information is stored in the endpoint map rather than CDS, which is a repository for more
stable information; namely, the server’s host address and the transports it uses. As long
as the server stays on the same machine, host and transport information need not be
updated, which tends to reduce bottlenecks at CDS.
This scheme makes application development and administration easier because it
reduces the need to manage endpoints. Servers needn’t worry about passing dynamic
endpoints to clients. Furthermore, unless a server moves to a new host, or removes or
adds a transport, it doesn’t even have to update the information in CDS.
10.3.1 Automatic Endpoint Map Administration
Each server that uses the endpoint map stores a set of information in the endpoint map
when it starts up. The information includes Universal Unique Identifiers (UUIDs) for
objects and interfaces offered by the server, an annotation string, and other fields.
The endpoint map resides on disk in dcelocal/var/dced/Ep.db and
dcelocal/var/dced/Srvrexec.db. After a system reboot, DCE-based servers restart and
reregister with the endpoint mapper service, so the database files need to be deleted
before the DCE daemon starts. This happens automatically on most systems.
DCE-based servers normally need to register with the endpoint mapper service on startup
and unregister on termination. If any servers exit without unregistering, the endpoint
map may contain stale entries.
DCE Version 1.1 provides server control facilities that help servers unregister and avoid
leaving stale entries in the endpoint map. Servers that don’t use these facilities (older
servers, for example) are more likely to leave stale entries if they exit unexpectedly. So
periodically, the DCE daemon (dced) purges stale entries by scanning the endpoint map,
‘‘pinging’’ each server that is registered, and deleting entries for servers that do not
respond.
The background process of removing stale entries is not intended to be highly
responsive. It is not intended to replace the need for servers to unregister themselves
from the endpoint map when they no longer service RPCs. Rather, this processing is
intended only to clean up after a server failure.
While the behavior of the pinging/purging mechanism is implementation dependent, in a
typical implementation the database is scanned (that is, servers are pinged and stale
entries removed) only infrequently; for example, a few times an hour. Once a ping to a
server fails, the server is pinged several times over a shorter interval; for example, every
5 minutes. If the server continues to not respond, the dced process determines that its
entry is ‘‘stale’’ and removes it from the database. Ultimately, the rate at which stale
server entries are detected and purged depends on the number of stale entries in the
database; the more stale entries, the longer it takes to detect and purge the stale entries.
124243 Tandem Computers Incorporated 10− 17