Paper Evaluations: 05-16-2000

Tue, 16 May 2000 00:08:02 -0700 (PDT)

Title: "Implementing Remote Procedure Calls"

This paper describes the implementation of a package providing
facilities for remote procedure calls. Using such facilities,
procedure calls are either local or remote. Hence, programs invoke
operations locally and remotely using the same semantics of procedure
calls. Moreover, RPC is an efficient form of communication, and general
in terms of communicating different parts of a program.

In order to call a remote procedure, a program in the caller machine
calls a procedure in the user-stub, which is responsible for placing a
specification of the target procedure and the arguments in one or more
packets. Then, the user-stub makes a request to the RPCRuntime to
transmit these reliably. On the callee machine, the RPCRuntime
receives those packets and passes them to the server-stub. The
server-stub unpacks them and them makes a local call to the
appropriate procedure. In the meanwhile, the processes in the caller
machine is blocked, waiting for the response. When the call in the
callee finishes, the server-stub sends packets to the caller machine
containing the results. During the whole communication of a call, if
any of the packets is lost, it is responsibility of the RPCRuntime to
retransmit. The RPCRuntime is also responsible for emulating the
mechanism of exception handling.

The request-response nature of a remote call makes the stream
protocols to large data transfers inadequate to RPC. Thus, protocols
are specified for simple and complicated calls. In simple calls, only
one packet is required to invoke the procedure and one packet for the
results. The response containing the results is often considered an
acknowledgement. If this response in not received in a determined
period of time, the RPCRuntime in the caller machine sends the request
again. In addition, a explicit acknowledgement may be request and then
the RPCRuntime in the callee machine acknowledges the request as soon
as it is received. On the other hand, complicated calls may require
several packets, each of them being acknowledged by the callee.

The Grapevine database is used to store information about the servers.
Each server explicitly exports a Mesa interface modules and the
clients import the interfaces by querying the database. The interfaces
are named by a type and an instance. Providing the instance, the
client queries the database for the address of the server. If only the
type is provided, the RPCRuntime decides in one of the group
determined by the type. Also, a fixed address can be determined in
compile time. An important aspect of this approach is that importing
an interface has no effect on the data structure of the server, and
hence provides a more scalable service.

Since the Grapevine database implementation is distributed and
replicated, a database server failure does not necessarily disables
the RPC service, because the clients are usually able to query another
server. Moreover, if an exporting machine crashes, the clients can
request the same service from another machine, if one is available,
because the Grapevine database stores a list of machines exporting the
same interface. Those features are very important for a reliable
system. This package, however, does not provide any support for
asynchronous calls. This feature is important for computations that
do not require any return value and hence can make progress in
parallel with the remote call. In addition, applications intended for
this system should be assessed to determine whether it provides
the correct features.


Title: "Performing Remote Operations Efficiently On a Local Computer

In this paper, a communication model is described for process
communication in a local area network. The basic idea is to provide a
communication substrate for high-level languages. The communication
primitives of those languages would be mapped to the functions of the
communication subsystem. This communication subsystem, however, is not
layered, so that the delays imposed by a layered architecture are
avoided. Instead a integrated approach is adopted and it can be
implemented directly on top of the communication hardware.

The communication subsystem is based on the reference/remote operation
model. In this model, a master process executes remote references as
transactions to promote reliability when required. Each remote
reference causes a single remote operation to be performed by a
remotely located process. Examples of remote references are remote
memory references, remote subroutine calls, and message passing

Processes can classified as regular processes, which disappear
after a processor failure, and recoverable processes, which can be
recovered after a processor crash and restart. Regular and recoverable
processes are ordinary processes used by applications. There is one
special process in each processor called communication processor. The
communication process performs four main functions: it maintains
system-sessions, it supervises the initiation and closing of other
sessions, it accepts the references from a master process and
initiates their remote execution, and finally it accepts remote
requests, awaking the slave process if necessary.

The main contribution of the paper are the five attribute classes of
the model. The reliability of a remote reference is specified by one
category. The categories basically differ in the number of remote
operations performed and the number of results committed, according to
the type of failures. A remote reference may return or not a value.
In terms of synchrony, a remote operation is processor-synchronous, if
the remote operation executes synchronously with respect to a calling
processor. Remote operations executing synchronously with respect to a
calling process are called process-synchronous. If the operation,
however, executes asynchronously with respect to the calling process,
the operation is asynchronous. Finally, the operations are either
primary or secondary. A primary operation is performed by a remote
communication process, while a secondary operation is performed by a
remote ordinary process.

A logical connection between a master process and slave process, over
which the master issues requests and the slave issues responses, is
defined as a session. System-sessions are pair of sessions maintained
by each pair of communicating processes. When a session is initiated,
a socket is created on each of the master and slave
processors. Sockets associate packets with sessions, contain
information to map requests/responses to individual processes, and
store state information so that sessions can provide specific semantic

Depending on the reference attributes, different protocols are used to
implement the various types of remote references. The request (R)
protocol is used for remote references which do not require a reliable
call, a return value, and flow-control. In the case that flow-control
is required, either the request/response (RR) protocol or the
request/response/acknowledge-response (RRA) is used. RRA differs from
RR in the acknowledgement of responses.

In my opinion, the model proposed is very interesting, but the paper
does not demonstrate how it would be useful in a real system. The
examples shown in the paper just report the implementation of
primitives extracted from the model. These examples, however, do not
include the implementation in a real system and evaluate the behavior
of the communication subsystem inside this context. For instance, it
is not clear how protection could be implemented using such a model.
Furthermore, the order used by the author to explain the model and
the implementation considerations confuses the reader.

--Flavio Junqueira

Flavio Paiva Junqueira, PhD Student
Department of Computer Science and Engineering
University of California, San Diego

Office location: AP&M 4349 e-mail: