RPC Types and Buffering Changes

• Type Conversion The programmer is now obliged to manage type conversion between the IDL or XDR type, and whatever is available in run time support (e.g. alloc/free) for such a function. Since there may be more than one choice here, this leads to possible divergence in the internal representations of the external data type (in a non type-safe way, so programs may crash). In C terms ,this forces the programmer to use a CAST, which actually hides any error of type conversion from the meager checking provided in many compilers. Of course, an ubiquitous, stanard IDL would avert this problem a priori.
• Buffer Allocation Strategy A client or server may receive a response or request containing variables whose storage requirements cannot be known at compile or initial run time, but only at actual call time. This means that dynamic storage allocation is required. In the server, any storage associated with the call or response parameters can be freed by the RPC dispatcher. However, in the client, either the user is obliged to provide the storage or they must be given a standard handle for freeing the RPC reply parameter storage. (They cannot just assume they can use a standard free function as, for efficiency reasons in protocol layering implementation, the result parameters may be part of a larger piece of dynamically allocated storage with preceding header information). In fact, this latter problem arises even for existing data types such as strings in any case. There is also a storage management problem since the space required for the data type in machine native format may be more than network buffers provide, so the presentation decoding may not be done in place (even though it should be done in-line with the network receive buffer copy code).