OSF DCE Application Development Guide--Introduction and Style Guide

Chapter 6. RPC Parameters
The RPC mechanism attempts to provide a data model as close as possible to the familiar
local call model. For example, you can pass data by reference—by passing a pointer to a
data item—despite the fact that client and server do not share an address space.
Nevertheless, there are significant differences in both the syntax and semantics of RPC
parameter data compared with C language local call data. For example, RPC provides
directional attributes, conformant arrays, discriminated unions, and pipes, constructs
which have no equivalents in C. Each requires an IDL specific syntax and has new
semantics. Also, familiar constructs, such as pointers, closely mimic their local C
language counterparts, but nevertheless must behave differently in some circumstances.
The DCE RPC programmer is thus confronted with a number of unfamiliar style and
policy issues. The policy issues have mainly to do with which data types to use in given
circumstances: for example, would you be better off using an array or a pipe to transfer a
large block of data? This chapter contains recommendations that should help you make
such choices. The style issues arise from the rich and unfamiliar syntax for RPC
parameters which can make the mechanics of using many of the RPC data types seem
rather daunting. This chapter contains numerous examples of basic data passing styles.
6.1 Execution Semantics
Before we begin to discuss the RPC data types themselves, a slight digression is
necessary. Whatever data you pass, all RPCs must deal with the unreliable nature of
remote network connections. A call may not complete due to a network failure, possibly
leaving the call operations in an indeterminate state. For this reason, the IDL provides
execution semantics attributes that applications can use to request certain (limited)
guarantees about call completness.
Ideally, in order for an application to behave in a determinate fashion, each operation
needs to be invoked exactly once each time it is invoked. This requirement can be
relaxed somewhat for idempotent operations: those which have the same effect when
they are invoked one or more times. In this case, an application can settle for at-least-
once semantics.
124246 Tandem Computers Incorporated 6−1