Evaluations: 05/16

Bianca Zadrozny (zadrozny@cs.ucsd.edu)
Tue, 16 May 2000 00:50:59 -0700

Implementing Remote Procedure Calls

This paper describes the implementation of an efficient RPC facility whose semantics is very similar to the semantics of a local procedure call. The program structure is based on stubs, which are automatically generated given an interface specification for the procedures that are going to be exported. The user and server stubs encapsulate the code for packing and unpacking arguments and results, and for dispatching to the correct procedure. This frees the programmer from worrying about communication related code.

The information about exported interfaces is kept in a Grapevine distributed database. One interesting feature of this scheme is that the client does not need to specify the network address of the server at compile time. It can specify a symbolic name for the desired interface that is to be imported. This name is then looked up in the database and the address of the server exporting the desired interface is located. Alternatively, the client can provide only the type of interface desired and any of the servers exporting an interface of that type can potentially be used. Another interesting feature of this scheme is that no data structures used for binding are kept in the exporting machine, which improves the scalability and reliability of the system. Furthermore, this scheme allows calls only to procedures that have been explicitly exported and for which the user was granted access, thus enforcing protection.

In order to achieve efficiency, a specialized transport level protocol is used. This protocol tries to minimize the real-time between initiating a call and getting results and also the load imposed on a server by a substantial number of users. The protocol is very efficient when the arguments of a call fit all in one packet, but is inefficient when this is not the case. The authors make this choice because they believe that the second case is very infrequent. Nonetheless, they do not provide any empirical data showing that this is really the case. Since there is no shared address space, it is possible that large data structures be frequently passed as arguments.

Exceptions are handled transparently by the RPC facility. If an exception occurs in the process on the server machine handling a call, an exception packet is transmitted to the calling process in place of the result packet. This causes an exception to be raised in the calling process. If there is a catch phrase for this exception, it is called and the results are passed back to the callee.

One weakness of this RPC facility is that it does not allow asynchronous calls. This is in agreement with the goal of making the semantics of remote calls resemble as close as possible the semantics of local calls. However, this limits the degree of parallelism of applications. This facility is thus not very suitable for computation intensive applications that need to divide their work among processors.


Performing Remote Operations Efficiently on a Local Computer Network

This paper describes a communication model that can serve as basis upon which one could implement high-level primitives for remote procedure calls, remote memory references, message passing, or any other type of remote reference instruction in a local computer network. This communication model exploits the characteristics of a local network to provide efficient functions that are suitable for implementing such high-level primitives.

One interesting concept present in this model is the one of recoverable processes, which are automatically resurrected after a processor crash and are reset to a consistent state. The model also defines a distinguished communication process per machine that is recoverable and specialized to perform communication functions efficiently. In particular, the communication process handles the transmission and reception of packets, the manipulation of communication state information, the execution of communication primitives issued by other processes in the same machine, and the execution of simple requests initiated by remote processes.

The model provides a very rich semantics for remote references. They have associated with them five attribute classes which indicate the reliability, the presence or absence of a return value, the synchrony, the need for flow control and the kind of process that is performing the reference. By adjusting these attributes values, it is possible to create many distinct types of communication primitives using the model.

The paper also addresses implementation issues that must be considered when implementing the different levels of reliability and the different types of synchronism. Furthermore, it gives examples of implementations of the model for particular attribute values, and reports the performance of one of the implementations. In order to completely validate the model, it would be necessary to design different high-level primitives using the model as a basis and evaluate their performance.

In my opinion, this paper is not very well-written. The figures do not help to illustrate the concepts because they do not match the text.