OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide

An incoming RPC always has an interface UUID associated with it; therefore, if a server

registers all of its endpoints with the interface it is offering, this will usually be sufﬁcient

for the endpoint mapper to send the incoming requests to one of the servers that offer the

desired interface, even if there is more than one such server active on the machine.

However, if the application is designed in such a way that the binding operation should

not be generalized to the interface but must be made more speciﬁc (in other words, this

server’s clients should always bind to this server and no other, even if some other server

happens to offer the same interface), then object UUIDs must be used to accomplish this.

Generic interfaces offered by an application (such as the remote ACL or the DCE

serviceability interface) require an object UUID in order to distinguish the application’s

instance of them; unique interfaces, however, do not require an object UUID.

Of course, the server’s interface UUID must also be included in each object

UUID/endpoint mapping, since no RPC will pass the endpoint mapper if it does not have

a matching interface UUID for its destination server. Therefore, the endpoint mapper

takes either two or three types of item to be registered, namely

• Endpoints

• Interface UUID

• Object UUIDs (optionally)

It then generates a cross-product table of all possible combinations of all values of the

items. This allows it to ﬁnd a valid endpoint for every possible valid object

UUID/interface UUID combination.

The endpoint mapper is the ﬁrst point of decision for an incoming RPC with a partial

binding. The mapper makes its decision solely on the basis of the contents of its

endpoint map. The object/type and manager EPV registrations that were done earlier

have no effect on the endpoint mapper. Only after a client request arrives at the server

does the server’s runtime routines dispatch the request among multiple managers, if type

managers have been registered by the server. The endpoint mapper knows nothing about

registered object types.

1.5.5.4 Exporting the Binding Information to the Namespace

The ﬁnal task of server registration (if the dce_server_c_ns_export ﬂag is set in the

dce_server_register( ) call) is to export the binding information to the namespace. In

the usual case, where the server’s endpoints have been dynamically allocated to it, the

endpoint information will not be included in the exported handles. Instead, this

information will be ﬁlled in by the host’s endpoint mapper as the partially bound handles

arrive at the host in incoming RPCs. However, if the endpoints are well-known, they will

be included in the exported binding handles, and clients will thus import fully bound

handles.

If you wish, you can use the lower level RPC routine rpc_ns_binding_export() to

export individual services to the namespace, but in this case you should ﬁrst be sure the

ﬂag dce_server_c_ns_export is not set in the dce_server_register() routine.

As a ﬁnal note, a client must have a binding handle in order to reach a server, but it does

not have to get the handle from the name service. However, the name service is the

1− 22 Tandem Computers Incorporated 124246