OSF DCE Application Development Guide--Core Components

OSF DCE Application Development Guide—Core Components
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.
16.6.2 Buffering Call Requests
Call requests for RPC servers come into the RPC runtime over the network. For each
endpoint that a server registers (for a given protocol sequence), the runtime sets up a
separate request buffer. A request buffer is a first-in, first-out queue where an RPC
system temporarily stores call requests that arrive at an endpoint of an RPC server. The
request buffers allow the runtime to continue to accept requests during heavy activity.
However, a request buffer may fill up temporarily, causing the system to reject incoming
requests until the server fetches the next request from the buffer. In this case, the calling
client can try again, with the same server or a different server. The client does not know
why the call is rejected, nor does the client know when a server is available again.
Each server process regularly dequeues requests, one by one, from all of its request
buffers. At this point, the server process recognizes them as incoming calls. The
interval for removing requests from the buffers depends on the activities of the system
and of the server process.
16 − 40 Tandem Computers Incorporated 124245