OSF DCE Application Development Guide--Introduction and Style Guide

Introduction to DCE Application Programming

The usual practice is to pass NULL for login_context here, and thus use the default

context.

Note that it is the client who chooses whether or not to use authenticated RPC, as well as

the level of authentication, and how much authorization information about itself to send.

It is then up to the server to accept this arrangement or reject it, or to allow some limited

operation with the client, or whatever else it might decide. The server decides which

authentication to use. The client also speciﬁes an authentication service (in authn_svc),

but if this differs from what the server speciﬁed, the call to

rpc_binding_set_auth_info() will fail and an error will be returned to the client.

There is an important difference between the rationales of authentication and

authorization. Authentication is performed by the RPC runtime and is only indirectly felt

by client and server; authorization, however, is for the most part implemented explicitly

in the server code if it is implemented at all. This difference is the reason for the larger

number of authentication-related arguments that have to be speciﬁed in this step.

For further information about authenticated RPC, see the .

1.6.3 Invoking Remote Procedure Calls

This step is the culmination of all the foregoing steps; here the client makes its ﬁrst

remote call to the server. This call, which will obviously be application speciﬁc (its

deﬁnition was speciﬁed in the application’s .idl ﬁle, and possibly modiﬁed by the .acf

ﬁle), will look something like the following:

my_rpc_op( binding_handle, arg1, arg2, arg3);

Note that the presence of the binding handle as a parameter means that explicit binding

handles are being used.

Note also that after all the preceding talk about interfaces, no interface handle appears in

the parameter list. The RPC runtime takes care internally of making sure that the

interface offered by the server exactly matches what the client expects. The

my_rpc_op() routine was (or should have been) deﬁned as part of the application’s

interface. When the client calls my_rpc_op( ) in the present step, the client stub code

(which was generated during the IDL compilation step) will include the correct UUID for

the interface the routine is associated with in the data sent out on the network. The RPC

runtime uses the interface speciﬁcation included with each RPC as a ‘‘ﬁngerprint’’ to

ensure that the operation being requested of a server is in fact implemented by that

server. This ensures that interface compatibility is never dependent on the vagaries of

application code.

124246 Tandem Computers Incorporated 1− 29