OSF DCE Application Development Guide--Core Components
RPC Fundamentals
The broadcast capabilities of RPC runtime have a number of distinct limitations:
• Not all systems and networks support broadcasting. In particular,
broadcasting is not supported by the RPC connection-oriented protocol.
• Broadcasts are limited to hosts on the local network.
• Broadcasts make inefficient use of network bandwidth and processor cycles.
• The RPC runtime library does not support at-most-once semantics for
broadcast operations; it applies idempotent semantics to all such operations.
• The input arguments for broadcast calls are limited to 944 bytes.
12.6 Communications Failures
If a server detects a communications failure during a remote procedure call, the
server runtime attempts to terminate the now orphaned call by sending a cancel to
the called procedure. A cancel is a mechanism by which a client thread of
execution notifies a server thread of execution (the to be canceled thread) to
terminate as soon as possible. A cancel sent by the RPC runtime after a
communications failure initiates orderly termination for a remote procedure call.
(For a brief discussion of how cancels work with remote procedure calls, see the
discussions with respect to Threads.)
Applications that use context handles to establish a client context require a
context rundown procedure to enable the server to clean up client context when it
is no longer needed. The name of the context rundown procedure is determined
from the type name of the context handle declared in the interface definition; this
ensures that the stub knows about the procedure in the server application code. If
a communications link with a client is lost while a server is maintaining context
for the client, the RPC runtime will inform the server to invoke the context
rundown procedure. For a more thorough discussion of context handles see
Chapter 16.
12.7 Scaling Applications
Unlike local applications, RPC applications require network resources, which are
possible bottlenecks to scaling an RPC application. RPC clients and servers
require network resources that are not required by local programs. The main
network resources to consider are network bandwidth, endpoints, network
descriptors (the identifiers of potential network channels such as UNIX sockets),
kernel buffers and, for a connection-oriented transport, the connections. Also,
RPC applications place extra demands on system resources such as memory
buffers, various quotas, and the CPU.
The number of remote procedure calls that a server can support depends on
various factors, such as the following:
124245 Tandem Computers Incorporated 12− 13