OSF DCE Application Development Guide--Core Components

Topics in RPC Application Development
or test_pipe.pull), and the server manager makes a cycle of calls to either
test_pipe.push or test_pipe.pull of the stub. The application code gives the illusion that
the server manager is calling the client-supplied callbacks. In fact, the manager is
actually calling stub-supplied callbacks, and the client callbacks are asynchronous: a
server manager call to one of the callback routines does not necessarily result in a call to
the corresponding client callback.
One result of this is that the client and server should not count on the chunk sizes being
the same at each end. For example, in the last directory reading example, the manager
calls the test_pipe.push routine once with each NULL-terminated filename. However,
the client test_push routine does not necessarily receive the data stream one filename at
at time. For example, if the test_push routine attempted to print the filenames using
printf("%s\n",buf);, it might fail. An interesting exercise would be to add printf( )
routines to the client callbacks and the server manager to show when each callback is
made.
Note also that the use of the pipe state field by the client is purely local and entirely at
the discretion of the client. The state is not marshalled between client and server, and
the server stubs use the local state field in a private manner. The server manager should
not alter the state field.
Pipes may also be [in,out], although the utility of this construct is somewhat limited.
Ideally, a client would like to be able to pass a stream of data to the server and have it
processed and returned asynchronously. In practice, the input and output streams must
be processed synchronously; that is, all input processing must be finished before any
output processing can be done. This means that [in, out] pipes, while they can reduce
latency within both the server and the client, cannot reduce latency between server and
client; the client must still wait for all server processing to finish before it can begin to
process the returned data stream.
For an in,out pipe, both the pull routine (for the in direction) and a push routine (for the
out direction) must be initialized, as well as the alloc routine and the state. During the
last pull call (when it will return a zero count to indicate that the pipe is ‘‘drained’’), the
application’s pull routine must reinitialize the pipe state so that the pipe can be used by
the push routine correctly.
16.5 Nested Calls and Callbacks
A called remote procedure can call another remote procedure. The call to the second
remote procedure is nested within the first call; that is, the second call is a nested remote
procedure call. A nested call involves the following general phases, as illustrated in
Figure 16-1:
1. A client makes an initial remote procedure call to the first remote procedure.
2. The first remote procedure makes a nested call to the second remote procedure.
3. The second remote procedure executes the nested call and returns it to the first
remote procedure.
124245 Tandem Computers Incorporated 16− 31