RPC Evaluations.

Tue, 16 May 2000 00:51:34 EDT

Performing Remote Operations Efficiently on a LAN

The paper presents a communication model with taxonomy of communication instructions that can be used to build efficient communication subsystems for local networks. Primitives for communication can be built using the subsystem, which reduces the communication-processing overhead. Those primitives must be powerful and efficient at the same time.
The remote reference/remote operation model is described in which a master and a slave communicate through a communication process on them each. Processes are made regular or recoverable, each with a different cost in terms of storage. The communication process is a recoverable, rapidly activated, process that uses stable storage, and should be able to respond quickly. Remote references causes and operation to be done at the slave side, possibly with a return result. 5 attribute classes are associated with the references that provide rich set of primitives to communicate. The choice made within each attribute has a corresponding cost in term of: stable storage, reliability and robustness, overhead and efficiency. The different choices in the attribute allows operating systems to make their choice and pay for what they use only, since each implementation provides an extension in a function with its additive cost. Each of the different combinations is useful for a different purp!
References between processes are made over sessions, with a socket for the master and another for the slave. As with processes, if the session was to survive crashes, the sockets must be made recoverable. The choice in synchrony affects the efficiency of the performance ( processor-synchronous is better to use when the cost of doing the remote operation is less than the overhead of task switching ). The type of protocol used also affects the size of buffering and might limit the slave ability to free storage that is not needed anymore. Request/Respond is useful for all types of synchrony between the processes but is hard to maintain for all asynchrony communication. The RRA protocol is able to implement any of the types of communication with added cost to the communication.
The author provides an example and its performance is measured. Main points of the results are that the hardware implementation is much faster than software, remote references will degrade the performance, longer transmission time when using multiple sessions and the overuse of a resource might incur thrashing.
The paper showed the tradeoffs with the possible usage of communication facility and gives an outlook to which functions should be designed using the primitives and which should be left to higher level. In contrast to the other distributed system papers that we read, transparency is not the main goal of the design with the processes assumed to be located on fixed processors for the duration of the session.

Implementing Remote Procedure Calls

The paper describes the construction of an RPC facility of Cedar. The facility is developed to make distributed system simple, effiecient, powerful and secure. Based on the duality between message passing systems and procedure-based ones, the designers favored procedure calls since Mesa already supports them. The semantics for remote procedure calls is the same as those for the local ones. Thus, no time-out mechanism is used when using RPC ( Acks takes care of it ).
The module that wishes to allow other modules to invoke it needs to register its information (connect site, ..) in the Grapevine distributed database ( exporter ). The binding information registered makes an implicit unbinding when the server crashes ( unique id ). The caller (importer ), when invoking the remote procedure, obtains the binding information using the distributed database. The facility allows the caller to specify the type of the process it wants to connect with without specifying which instance ( and the RPCRuntime will connect it to the most efficient process , Cool but how ?! ).
The protocol implemented in the communication reduces the time necessary in a connection-oriented implementation , still with providing the RPC functionality. Many optimizations have been implemented that reduce the communication time ( implicit Acks, no establishing cost, reduction in process switches ..). With simple calls, the server detects duplication and retransmit already computed results. The state information at the server side is released after a certain amount of time. Complicated calls require Acks for all the transmitted packets except the last one, which simplifies and optimize the implementation.
I read an assumption that I found disturbing for such an implementation. Each activity or process can have at most one outstanding remote call at a time. This assumption made the communication synchronous and the only way to solve this is by forking a process to implement the RPC. I wonder if implementing asynchronous communication using this facility ( using the forks ) would give a better result than using other RPC facilities provided by other systems.

Sobeeh Almukhaizim