Execution semantics identify the ability of a procedure to execute more than once during a given remote procedure call. The communications environment that underlies remote procedure calls affects their reliability. A communications link can break for a variety of reasons such as a server termination, a remote system crash, a network failure, and so forth; all invocations of remote procedures risk disruption due to communications failures. However, some procedures are more sensitive to such failures, and their impact depends partly on how reinvoking an operation affects its results.
To maximize valid outcomes for its operations, the operation declarations of an RPC interface definition indicate the effect of multiple invocations on the outcome of the operations.
The following table summarizes the execution semantics for DCE RPC calls.
Execution Semantics for DCE RPC Calls
Semantics | Meaning |
at-most-once | The operation must execute either once, partially, or not at all; for example, adding or deleting an appointment from a calendar can use at-most-once semantics. This is the default execution semantics for remote procedure calls. |
idempotent | The operation can execute more than once; executing more than once using the same input arguments produces identical outcomes without undesirable side effects; for example, an operation that reads a block of an immutable file is idempotent. DCE RPC supports maybe semantics and broadcast semantics as special forms of idempotent operations. |
Semantics | Meaning | |
maybe | The caller neither requires nor receives any response or fault indication for an operation, even though there is no guarantee that the operation completed. An operation with maybe semantics is implicitly idempotent and must lack output parameters. | |
broadcast | The operation is always broadcast to one server on each host system on the local network, rather than delivered to a specific server, and one reply is returned to the client. An operation with broadcast semantics is implicitly idempotent. |
· 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.