The endpoint mapper service of dced maintains the local endpoint map. The endpoint map is composed of elements which contain fully bound server binding information for a potential binding and an associated interface identifier and object UUID (which may be nil). Optionally, a map element can also contain an annotation such as the interface name.
Servers use the local endpoint mapper service to register their binding information. Each interface for which a server must register binding information requires a separate call to an rpc_ep_register...( ) routine, which calls the endpoint map service. The endpoint map service uses a new map element for every combination of binding information specified by the server. The following figure shows the correspondence between server binding information specified by a server and a graphic representation of the resulting endpoint map elements.
Mapping Information and Corresponding Endpoint Map Elements
A remote procedure call made with server binding information that lacks an endpoint uses an endpoint from the endpoint map service. This endpoint must come from binding information of a compatible server. The map element of a compatible server contains the following:
· A compatible interface identifier
The requested interface UUID and compatible version numbers are necessary. For the version to be compatible, the major version number requested by the client and registered by the server must be identical, and the requested minor version number must be less than or equal to the registered minor version number.
· The requested object UUID, if registered for the interface
· A server binding handle that refers to compatible binding information that contains the following:
- A protocol sequence from the client's server binding information
- The same RPC protocol major version number that the client runtime supports
- At least one transfer syntax that matches one used by the client's system
To identify the endpoint of a compatible server, the endpoint service uses the following rules:
1. If the client requests a nonnil object UUID, the endpoint map service begins by looking for a map element that contains both the requested interface UUID and object UUID.
a. On finding an element containing both of the UUIDs, the endpoint map service selects the endpoint from that element for the server binding information used by the client.
b. If no element contains both UUIDs, the endpoint map service discards the object UUID and starts over (see rule 2).
2. If the client requests the nil object UUID (or if the requested nonnil object UUID is not registered), the endpoint map service looks for an element containing the requested interface UUID and the nil object UUID.
a. On finding that element, the endpoint map service selects the endpoint from the element for the client's server binding information.
b. If no such element exists, the lookup fails.
The RPC protocol service inserts the endpoint of the compatible server into the client's server binding information. The following figure illustrates the decisions the endpoint map service makes when looking up an endpoint for a client.
Decisions for Looking Up an Endpoint
You can design a server to allow the coexistence on a host system of multiple interchangeable instances of a server. Interchangeable server instances are identical, except for their endpoints; that is, they offer the same RPC interfaces and objects over the same network (host) address and protocol sequence pairs. For clients, identical server instances are fully interchangeable.
Usually, for each such combination of mapping information, the endpoint map service stores only one endpoint at a time. When a server registers a new endpoint for mapping information that is already registered, the endpoint map service replaces the old map element with the new one.
For interchangeable server instances to register their endpoints in the local endpoint map, they must instruct the endpoint map service not to replace any existing elements for the same interface identifier and object UUID. Each server instance can create new map elements for itself by calling the rpc_ep_register_no_replace( ) routine.
When a client uses a partially bound binding handle, load sharing among interchangeable server instances depends on the RPC protocol the client is using.
· Connectionless (datagram) protocol
The map service selects the first map element with compatible server binding information. If necessary, a client can achieve a random selection among all the map elements with compatible binding information. However, this requires that, before making a remote procedure call, the client needs to resolve the binding by calling the rpc_ep_resolve_binding( ) routine.
· Connection-oriented protocol
The client RPC runtime uses the rpc_ep_resolve_binding( ) routine, and the endpoint map service selects randomly among all the map elements of compatible servers.
For an alternative selection criteria, a client can call the rpc_mgmt_ep_elt_inq_{begin,next,done}( ) routines and use an application-specific routine to select from among the binding handles returned to the client.
When a server stops running, its map elements become outdated. Although the endpoint map service routinely removes any map element containing an outdated endpoint, a lag time exists when stale entries remain. If a remote procedure call uses an endpoint from an outdated map element, the call fails to find a server. To avoid clients getting stale data from the endpoint map, before a server stops, it should remove its own map elements.
A server also has the option of removing any of its own elements from the local endpoint map and continuing to run. In this case, an unregistered endpoint remains accessible to clients that know it.