X hits on this document

73 views

0 shares

0 downloads

0 comments

2 / 21

40

  • A.D. Birrell and B. J. Nelson

still execute (depending on the details of the parallelism of that environment and the RPC implementation).

There are many attractive aspects to this idea. One is clean and simple semantics: these should make it easier to build distributed computations, and to get them right. Another is efficiency: procedure calls seem simple enough for the communication to be quite rapid. A third is generality: in singie-machine com- putations, procedures are often the most important mechanism for communica- tion between parts of the algorithm.

The public

idea of RPC has literature many

been around for many years. It has been discussed in the

times

since

at

least

as

far

back

as

1976

15.

Nelson's

doctoral dissertation 13 for an RPC system and

is an extensive examination of the design possibilities has references to much of the previous work on RPC.

However, full-scale implementations

of RPC

have

been

rarer

than

paper

designs.

Notable recent efforts include and current work at MIT 10.

Courier in

the

Xerox

NS

family

of protocols

4,

This paper results from the construction of an RPC facility for the Cedar project. We felt, because of earlier work (particularly Nelson's thesis and asso- ciated experiments), that we understood the choices the designer of an RPC facility must make. Our task was to make the choices in light of our particular aims and environment. In practice, we found that several areas were inadequately understood, and we produced a system whose design has several novel aspects. Major issues facing the designer of an RPC facility include: the precise semantics of a call in the presence of machine and communication failures; the semantics of address-containing arguments in the (possible) absence of a shared address space; integration of remote calls into existing (or future) programming systems; binding (how a caller determines the location and identity of the callee); suitable protocols for transfer of data and control between caller and callee; and how to provide data integrity and security (if desired) in an open communication network. In building our RPC package we addressed each of these issues, but it not possible to describe all of them in suitable depth in a single paper. This paper includes a discussion of the issues and our major decisions about them, and describes the overall structure of our solution. We also describe in some detail our binding mechanism and our transport level communication protocol. We plan to produce subsequent papers describing our facilities for encryption-based security, and providing more information about the manufacture of the stub modules (which are responsible for the interpretation of arguments and results of RPC calls) and our experiences with practical use of this facility.

1.2 Environment

The remote-procedure-call package we have built was developed primarily for use within the Cedar programming environment, communicating across the Xerox research internetwork. In building such a package, some characteristics of the environment inevitably have an impact on the design, so the environment is summarized here.

Cedar 6 is a large project concerned with developing a programming environ- ment that is powerful and convenient for the building of experimental programs and systems. There is an emphasis on uniform, highly interactive user interfaces, and ease of construction and debugging of programs. Cedar is designed to be used

ACM

Transactions on Computer Systems, Vol. 2, No. I,February 1984

Document info
Document views73
Page views73
Page last viewedTue Jan 17 23:52:00 UTC 2017
Pages21
Paragraphs669
Words10995

Comments