A number of implementation decisions must be made in IPC mechanisms.
Although these have no effect on the semantics of the system, they can
greatly alter the performance.
In any multitasking system with Inter Process Communication, there
must be some scheme for controlling allocation and ownership of
memory. Dynamic use of memory is often required for IPC, whether
Message Passing or RPC, since it may not be known until call or send time
how large the call parameters will be.
There are several choices for buffering schemes with respective
tradeoffs between efficiency and safety. Some are appropriate to
message passing, others to RPC.
-
The caller/sender may allocate buffers.
-
For RPC, this may include space for return parameters, or else
this may be allocated by the receiver.
-
The ownership may be transferred to the receiver or not.
-
The buffers may be copied to space allocated by the receiver.
-
The caller may then free the call buffers.
-
The caller may rely on the
receiver to free the buffers for return parameters.
These schemes may be combined in various different ways.
Object oriented approaches make buffer handling in RPC type systems
much simpler, since lexical scope often determines when buffers or
messages can be garbage collected on memory management
An optimisation in RPC systems is to use shared memory when the call is
to a server which happens to be in the same address space.
Another useful optimzation is to provide scatter/gather memory in the
RPC application to stub and stub to protocol interface. It is often the
case that the data representation scheme in use means that this
optimizes the marshaling and unmarshalling of arguments. It is also
possible that this interface actually extends as far as the network
hardware interface and thus avoids any copying of arguments or buffers
at any stage. This can only be made safe when the underlying
operating system is sufficiently sophisticated in its memory
protection, or the programming language sufficiently type safe.