Servers must initialize some data and notify various DCE services about themselves prior to servicing RPC requests. At a minimum, servers must register with DCE and then go into a wait state listening for remote procedure calls. In addition to these minimum tasks, your application may first parse the input arguments, obtain information about how it was started using dced API calls, and establish the proper message tables and locale for internationalization.
DCE applications should be started in such a way that they can be controlled by dced. When the server is installed, the dcecp server create operation (or a custom made server management application) is commonly used to establish the server's configuration with its host dced. This configuration data includes among other things the program name and its arguments, the CDS entry name to use for exporting to the name service, and the valid starting methods. Installing your servers in this way does not compromise their security because dced operations are protected with ACLs, and the major advantages include the following:
· You do not have write any complex management code for each server
· Your servers are like other DCE servers in that they can all be managed consistently
Depending on how the server is configured, the dced can start it in the following ways:
· At boot time when the DCE daemon itself starts
· Explicitly via the dcecp server start operation (or from another application that called dced_server_start( ))
· Automatically when a remote procedure call comes in for the server
· After a failure of the server it can be restarted
If dced did not start the server, it cannot control it. Therefore, one of the first things your server should do is to verify that dced started it by obtaining the configuration information, as in the following:
server_t *server_conf;
.
.
.
dce_server_inq_server(&server_conf, &status);
if(status != error_status_ok) {
.
.
.
Additional routines, such as dce_server_inq_uuids( ) and dce_server_inq_attr( ), are also useful for obtaining information from dced about the running server.
Robust servers usually perform some or all of the following initialization tasks:
· Set up for serviceability which includes establishing message routing, debug levels, and internal message tables.
· Set up the server's objects. This includes creating and storing UUIDs for all necessary objects and object types, and grouping objects by type.
· Set up the security environment which includes setting authentication information, establishing the server's principal identity, and creating ACL managers for each type of ACL object.
· Define manager entry point vectors (EPVs) for each set of interface operations.
· Register the server with DCE. This includes the following: registering the interfaces and the associated EPVs for the operations, establishing the network protocol sequences and endpoints on which the server will listen, registering endpoints and other binding information in the endpoint mapper service, and exporting binding information to the CDS namespace.
· Specify how the server will be multithreaded.
· Listen for incoming requests for remote procedure calls.
· Clean up the program state and environment affected by the server prior to the server's termination.
More:
Setting Up the Server's Objects
Defining the Manager Entry Point Vectors for Each Set of Operations
Listening for Incoming Service Requests
Cleaning Up Code When the Server Terminates