The UniCon compiler uses a message passing mechanism to implement remote procedure calls (RPCs) in the source code implementation of a system. The compiler makes use of either of two well-known RPC facilities, depending upon the target operating system of the application: the Mach InterProcess Communication (IPC) facility for Mach and Real-Time Mach applications, and the RPCGen-based facility for applications running on Sun platforms.
Implementation of message passing for RPCs requires the production of glue code for both client processes and server processes performing RPCs. A client process is one that makes remote procedure calls, but does not export remote procedure definitions that can be called by other processes. A server process is one that does export remote procedure definitions. Glue code is source code that is not part of the application logic, but is required in a process to facilitate the message passing mechanism of the RPC facility. The glue code gets compiled and linked into both client and server processes that perform RPCs; it facilitates the creation, passing, and decoding of messages constructed from the arguments and return values of the routine calls.
Both RPC facilities mentioned above provide system designers with an IDL-like language to specify remote procedure definitions, which includes the data types of the arguments. These RPC facilities provide compilers for their respective languages that compile an IDL description of a set of services into the glue code needed by both client and server processes. The IDL compilers are not smart enough to be able to support complex data types of RPC arguments that can be constructed in a given programming language. The compilers usually only support simple data types like integers and character strings, and simple array types. Definitions of the complex data types, therefore, must be provided to the RPC facility, and these are usually specified in the IDL-like language in terms of the simple data types and array types.
NOTE: Since data in remote procedure calls is intended to flow between processes, data values cannot be passed by reference in the argument lists of remote routine calls. This is because the address space of a process is distinct, and not visible to another process. The values, therefore, must be passed by copy between processes. The data types of the arguments in the Signature of an RPC must reflect this restriction. Characters strings in the C language, for example, must be passed as arrays of characters, and not as pointers to character strings. Similarly pointers to other types of data are disallowed. This is why most RPC facilities support only simple data types and array types.
The RPCTypeDef property provides the system designer with the means for providing the RPC facility with definitions of the complex data types of arguments in remote procedure definitions. The UniCon compiler constructs the complex data type out of simple data types and array types in the IDL specifications of remote procedure definitions, and then uses these specifications to generate the glue code for a system.
The following is a list of standard data types in the C programming language that are recognized by the IDL compilers of both RPC facilities. If the arguments of the remote procedure calls in an application have the following type names, then no RPCTypeDef properties are necessary. The name of the type and the size (in bytes) of an object of that type are provided for each standard C type:
----------------- C data type Size ----------------- short 2 int 4 long 4 float 4 double 8 char 1 unsigned 4 -----------------The default sizes for the standard C types are the defaults for the "cc" compiler hosted on SunOS 4.1.3 systems. These defaults can be overriden (see below).
Character strings are considered complex data types to most RPC facilities, since they must be passed as arrays of characters (see above). To pass character strings as arguments in remote procedure calls, the application programmer must define complex C language data types representing arrays of the data type char. For example, character strings of length 10 can be defined as follows in an application:
typedef char string_10_type[10];To use this data type in an RPC, the system designer must specify an RPCTypeDef property in the property list of an instantiation or definition of the SchedProcess or Process component in which the RPCCall or RPCDef player is defined that uses the data type for one of its arguments. It is recommended that for formal arguments representing variable length character strings in remote routine definitions, a fixed length character array of maximum size be used. The RPC facility only copies character string data until it encounters the null character, so this is not an inefficient way of passing character data.
The value part of the RPCTypeDef property has three fields: the type name, the base type name, and the size, in that order. The type name is the name of the data type as it is defined in the source code implementation of the system. For example, in the Example section below, the name of the type being defined is new_type, which is the name of the type in the typedef in the C source code fragment also shown in the example.
The base type name is the name of the data type upon which the newly defined type is based. For example, if a remote procedure call contains an argument of the type my_integer, which is defined in the C language as follows:
typedef int my_integer;then the base type is the C standard type int. The RPCTypeDef property describing my_integer to the RPC facility would appear as follows:
RPCTYPEDEF (my_integer; int)The base type name can name a standard C language data type, the type name in another RPCTypeDef property in the same property list, or the keyword struct. Many complex C language data types are defined as structs containing members of other data types. If the base type name is the type name in another RPCTypeDef property, then no size specification is required in the RPCTypeDef property. UniCon uses the size specification from the RPCTypeDef property defining that type. If the base type name is a standard C language data type, no size specification is required either, since the UniCon compiler knows the default size associated with each C type. If the sizes of the standard C language types are different on the target machine for a given application than the defaults, specifying a size in the third field overrides the default that UniCon has for that type. Lastly, if the base type name is struct, then a size specification is required in the RPCTypeDef property. This must represent the size of the struct as given by the sizeof operator in the C programming language. The reason for this is that the sizeof operator takes into account the gaps between members of structs due to the compiler acquiring storage space for struct members on word boundaries.
The third field specifies the size (in bytes) that an object of the given base type name consumes. This field consists of some optional array bounds, followed by a byte size. The array bounds are integers surrounded by square brackets; there can be any number of array bound specifications, from none to an infinite number. Each array bound represents another dimension in the array type being defined, with the rightmost array bound representing the subscript that varies fastest as elements in the array are accessed in storage order. The byte size part of the third field is required, if the third field is non-empty. The byte size represents the size of an array element. If no array bounds are specified, then it represents the true size (in bytes) of on object of the base type.
There is no default value for the RPCTypeDef property.
The merge rule value for a given property tells the UniCon compiler what to do when a duplicate specification of that property occurs in the same property list. Usually a duplicate constitutes another property specification with the same name part. For example, any two specifications of the MaxAssocs property in the same property list, regardless of the specific contents of their respective value parts, are considered duplicates. For the
RPCTypeDef property, a specification is not a duplicate unless the value part is equivalent to the value part of a previously specified RPCTypeDef property. More specifically, two RPCTypeDef properties are duplicates if the first field in each is the same. The case of the letters in this check is significant, but the presence or absence of double-quotes is not.
Subsequent duplicate specifications of the RPCTypeDef property in a single property list replace earlier specifications (i.e., the last specification is the one that the UniCon compiler uses).
USES Server INTERFACE RTServer
PRIORITY (2)
RPCTYPEDEF (new_type; struct; 12)
RPCTYPEDEF (another_type; new_type)
RPCTYPEDEF (an_array_type; char; [12] 25)
RPCTYPESIN ("server_app.h")
END Server
The corresponding type definitions in the file "server_app.h" are as follows:
typedef struct {
int member1;
short member2;
int member3;
} new_type;
typedef new_type another_type;
typedef char an_array_type[12][25];
On a SunOS 4.1.3 system, the new_type struct takes up 12 bytes of space, so the <size> specification is the <integer> value 12. On a SunOs 4.1.3 system, an int requires 4 bytes of storage space, and a short requires 2 bytes. The reason that the total size is 12 bytes and not 10 is because SunOs always starts new storage allocation on a
Author:
Last Modified: May 12, 1996