HPlogo Communicator e3000 MPE/iX Express 1 Based on Release 7.0 > Chapter 5 Technical Articles

DCE to RPC 1.2.1

MPE documents

Complete PDF
Table of Contents
Index

Commercial Systems Division

DCE RPC is the software to implement the communication between the client and server of an application through the Remote Procedure call (RPC). RPC gives the users the ability to express an interaction between client and server of a distributed application as if it were a procedure call. RPC provides a high-level programming model to the distributed applications and hides networking communication details from the users.

DCE RPC consists of several RPC components that work together to provide the communication between client and server under the distributed computing environment. The major components of RPC include:

  • The interface definition language (IDL) and its compiler

  • RPC Daemon (an RPC specific name server manages the mapping between RPC server to the transport endpoints)

  • the RPC runtime library, which implements the communication between the client and server sides

Deliverables

The deliverables for RPC 1.2.1 are:

  • /lib/libdce.sl

  • IDL - Compiler

  • The catalog files

The applications developed in the MPE/iX environment and linking to the DCEXL.HPDCE.SYS library will be using 1.0.2 APIs. The 1.2.1 version of DCE library is delivered in POSIX environment as /usr/lib/libdce.sl. So any application linking to this library will use 1.2.1 APIs.

Threads Changes

One of the major changes during the porting of RPC 1.2.1 is that of the thread functionality. From RPC 1.2.1 onwards threads library components are separated from DCEXL (the DCE executable library). It means that the end-user can write thread related application without linking to DCEXL. The thread library now is delivered and supported by the Process Management Group in CSY as /usr/lib/libpthread.sl. The new library for threads support only POSIX threads standard, also known as Draft10 standard.

To use the new thread library, the RPC 1.2.1 component is also moved to POSIX threads standard. RPC 1.2.1 uses POSIX thread implementations. RPCD and RPCCP are not delivered with RPC 1.2.1; they are part of 1.0.2 version only, using the DCE thread APIs.

System Environment Requirement

The RPC 1.2.1 software can be used from MPE/iX release 6.0 onwards. RPC 1.2.1 software was released as patches for MPE/iX 6.0 version. To use RPC 1.2.1, the system should be running MPE/iX version 6.0 or later. RPC 1.2.1 comes with some dependent patches. These patches include a loader patch, a libc patch and the threads patch. The patch ID for the current release of RPC 1.2.1 on MPE/iX is FRIKXN7C.

New Features in RPC/IDL 1.2.1

The following section lists the various new features in the RPC runtime library and IDL of RPC 1.2.1 that are available. Both runtime library and IDL compiler have been implemented to provide the new features in RPC/IDL 1.2.1.

Runtime Library:

Private client sockets:

Previously a common pool of sockets was shared by concurrent RPC requests. Making this concurrency work requires that there be a "helper" thread created to read from all of the open sockets, passing received data onto the call thread for which it is intended. Now with "Private client sockets" there are a couple of sockets (2/3) which will be used only for individual requests (private to the request thread). This reduces the overhead of "helper" thread in case of small applications. However, when we run out of private sockets the sharing of sockets comes into effect.

Serviceability

This is another new feature, which has been added to RPC runtime. This feature logs messages during the runtime to a specified log file. The level of the messages and the components can be configured using the routing file (/opt/dcelocal/var/svc/routing).

This feature will be helpful during analysis of a problem.

By default the routing file is picked from "/opt/dcelocal/var/svc/routing". The DCE_SVC_ROUTING_FILE environment variable can be used to name an alternate location for the file.

The various switches that can be used are as below: 

"general"  "mutex"  "xmit"  "recv"  "dg_state"  "cancel"  "orphan"
"cn_state"  "cn_pkt"  "pkt_quotas"  "auth"  "source"  "stats"
"mem"  "mem_type"  "dg_pktlog"  "thread_id"  "timestamp"
"cn_errors"  "conv_thread"  "pid"  "atfork"  "inherit"  "dg_sockets"
"timer"  "threads"  "server_call"  "nsi"  "dg_pkt"  "libidl".
The level of messaging ranges from 0-9, where level 9 is the highest level and gives the maximum details. The file to which the logs should be redirected can also be configured. For example, for the RPC, if we want to generate log files with "general" and "cn_pkt" switch enabled at level 9 with the logs to be written to a file named after the process-id of the process, then the line would be something like

rpc:general.9,cn_pkt,9:FILE:/tmp/%ld.log

Exception Handling

The new version RPC 1.2.1 supports the exception-handling feature of RPC. So now the application developer can use the exception handling routines (TRY, CATCH, CATCH-ALL etc.,).

DCE-IDL Compiler for RPC1.2.1

Out-of-line marshalling (library based marshalling)

Out-of-line marshalling causes constructed data types such as unions, pipes or large structures to be marshalled or unmarshalled by auxiliary routines, thus reducing the stub size. The out_of_line attribute directs the IDL compiler to place the marshalling and unmarshalling code in IDL auxiliary stub files, rather than in the direct flow of the stub code.

The in_line and out_of_line attributes affect the stub code generated for marshaling and unmarshlling non-scalar parameters (non-scalar types include int, float, char and pointers in C). Normally IDL compiler generates marshalling and unmarshalling code for all parameters in_line. This means that if the same data type is used repeatedly, the identical code will appear in multiple places. If out_of_line is specified, the marshaling and unmarshalling code will be provided as a subroutine, which is called from wherever it is needed.

Enhancing IDL data types

IDL support for arrays in previous version was limited to:

  • Arrays with a lower bound of zero.

  • Arrays with conformance or varying dimensions only in the first (major) dimension.

The current version of IDL will remove these restrictions by supporting fully general arrays as described in the IDL functional specification. The following example includes declarations that were not supported in previous version that will be allowed now are:

  • long c1[][4];

  • long c2[][0..3]; /* Same array shape as c1 */

  • long c3[0..*][4]; /* Same array shape as c1 */

  • long c4[0..*][0..3]; /* Same array shape as c1 */

  • float d1[1..10]; /* Equivalent to FORTRAN REAL D1(10) */

  • float d2[*..10]; /* Lower bound is determined at run time */

  • float d3[*..*]; /* Both bounds determined at run time */

The <attr_var>s are in one-to-one correspondence with the dimensions of the array, starting at the first. If there are fewer <attr_var>s than the array has dimensions then the missing <attr_var>s are assumed to be null. An <attr_var> will be non-null if and only if the lower bound of the corresponding dimension is determined at runtime. Not all <attr_var>s in a min_is clause can be null. Below are examples of the syntax. Assume values of variables are as follows: long a = -10; long b = -20; long c = -30; long d = 15; long e = 25. 

 [min_is(a)] long g1[*..10];                 /* g1[-10..10] */
 [min_is(a)] long g2[*..10][4];              /* g2[-10..10][0..3] */
 [min_is(a,b)] long g3[*..10][*..20];        /* g3[-10..10][-20..20] */
 [min_is(,b)] long g4[2][*..20];             /* g4[0..1][-20..20] */
 [min_is(a,,c)] long g5[*..7][2..9][*..8];   /* g5[-10..7][2..9][-30..8] */
 [min_is(a,b,)] long g6[*..10][*..20][3..8]; /* g6[-10..10][-20..20][3..8] */
 [max_is(,,e),min_is(a)] long g7[*..1][2..9][3..*];
                                             /* g7[-10..1][2..9][3..25] */
 [min_is(a,,c),max_is(,d,e)] long g8[*..1][2..*][*..*];
                                             /* g8[-10..1][2..15][-30..25] */

Support for IDL encoding Services:

This extension to the IDL stub compiler will enable instances of one or more data types to be encoded into and decoded from a byte stream format suitable for persistent storage without invoking RPC Runtime.

The encode and decode attributes are used in conjunction with IDL Encoding service routines (idl_es*) to enable RPC applications to encode datatypes in input parameters into a byte stream and decode datatypes in output parameters from a byte stream without invoking the RPC runtime. Encoding and decoding operations are analogous to marshaling and unmarshalling, except that the data is stored locally and is not transmitted over the network.

Support for User defined Exceptions

This extension to the IDL compiler will allow specification of a set of user-defined exceptions that may be generated by the server implementation of the interface. If an exception occurs during the execution of the server, it terminates the operation and the exception is propagated from server to client.

Support for Customized Binding handles

This enhancement allows the application developer to add some information that the application wants to pass between the client and server. This can be used when application-specific data is appropriate to use for finding a server when the data is also needed as a procedure parameter.

References

For details on the features of IDL refer to the below mentioned RFC:

  • Reference: RFC2.1: Proposed Enhancements for DCE 1.1 IDL, J. Harrow, July, 1992.
    URL: http://www.opengroup.organization/tech/rfc/

  • OSF DCE Application Development Guide -- Core Components Vol. - II (Revision 1.1)



Announcing MPE/iX High Availability Cluster/iX

Pascal/iX has $VOLATILE_WITH Option Enhancement