OSF DCE Application Development Guide--Core Components

OSF DCE Application Development Guide—Core Components
and decoding functions are just like marshalling and unmarshalling, except that the data
is stored locally and is not transmitted over the network; the IDL encoding services
separate the data marshalling and unmarshalling functions from interaction with the RPC
runtime.
Client and server applications can use the IDL encoding services to ‘‘flatten’’ (or
‘‘serialize’’) a data structure, even binary data, and then store it; for example, by writing
it to a file on disk. An RPC application on any DCE machine, regardless of its data type
size and byte endianess, is then able to use the IDL encoding services to decode
previously encoded data. Without the IDL encoding services, you cannot create a file of
data on one machine and then successfully read that data on another machine that has
different size data types and byte endianess.
The IDL encoding services can generate code that takes the input parameters to a
procedure and places them in a standard form in one or more buffers that are delivered to
user code. This process is called encoding. Encoded data can be written to a file or
forwarded by a messaging system. The IDL encoding services can also generate code
that delivers, as the output parameters of a procedure, data that has been converted into
the standard form by encoding. Delivery of data in this way is called decoding. Data to
be decoded can be read from a file or received by a messaging system.
Applications use the ACF attributes encode and decode as operation attributes or as
interface attributes to direct the IDL compiler to generate IDL encoding services stubs
for operations rather than generating RPC stubs. See Chapter 18 for usage information
on encode and decode.
16.7.1 Memory Management
IDL encoding services stubs handle memory management in the same way as RPC client
stubs: when you call an operation to which the encode and/or decode attributes have
been applied, the encoding services stub uses whatever client stub memory management
scheme is currently in effect. See Section 16.1 for further details on client stub memory
management defaults and setting up memory management schemes.
You can control which memory management scheme the stubs will use by calling the
rpc_ss_swap_client_alloc_free() and rpc_ss_set_client_alloc_free() routines. The
first routine sets the memory management routines used by both the encoding and
decoding stubs, and the second routine restores the previous memory management
scheme after encoding and decoding are complete.
Note that the memory management scheme established, whether explicitly or by default,
is on a per-thread basis.
16.7.2 Buffering Styles
There are a number of different ways in which buffers containing encoded data can be
passed betweeen the application code and the IDL encoding services. These are referred
16 − 46 Tandem Computers Incorporated 124245