X hits on this document





4 / 21


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

five beyond the necessary transmission times of the network). This seems important, lest communication become so expensive that application designers strenuously avoid it. The applications that might otherwise get developed would be distorted by their desire to avoid communicating. Additionally, we felt that it was important to make the semantics of the RPC package as powerful as possible, without loss of simplicity or efficiency. Otherwise, the gains of a single unified communication paradigm would be lost by requiring application programmers to build extra mechanisms on top of the RPC package. An important issue in design is resolving the tension between powerful semantics and efficiency.

Our final major aim was to provide secure communication with RPC. None of the previously implemented protocols had any provision for protecting the data in transit on our networks. This was true even to the extent that passwords were transmitted as clear-text. Our belief was that research on the protocols and mechanisms for secure communication across an open network had reached a stage where it was reasonable and desirable for us to include this protection in our package. In addition, very few (if any) distributed systems had previously provided secure end-to-end communication, and it had never been applied to RPC, so the design might provide useful research insights.

1.4 Fundamental Decisions

It is not an immediate consequence of our aims that we should use procedure calls as the paradigm for expressing control and data transfers. For example, message passing might be a plausible alternative. It is our belief that a choice between these alternatives would not make a major difference in the problems faced by this design, nor in the solutions adopted. The problems of reliable and efficient transmission of a message and of its possible reply are quite similar to the problems encountered for remote procedure calls. The problems of passing arguments and results, and of network security, are essentialy unchanged. The overriding consideration that made us choose procedure calls was that they were the major control and data transfer mechanism imbedded in our major language, Mesa.

One might also consider using a more parallel paradigm for our communication, such as some form of remote fork. Since our language already includes a construct for forking parallel computations, we could have chosen this as the point at which to add communication semantics. Again, this would not have changed the major design problems significantly.

We discarded the possibility of emulating some form of shared address space among the computers. Previous work has shown that with sufficient care mod-

erate efficiency can be achieved in doing this 14.







We do not



know whether an potentially major

diffÉculties spring can be integrated

to mind: into our

first, whether programming

the representation of remote addresses languages (and possibly the underlying

machine architecture) without undue upheaval; ciency can be achieved. For example, a host in by a 16-bit address, so a naive implementation

second, whether acceptable effi- the PUP internet is represented of a shared address space would

extend the width of language addresses by 16-bits. On the other possible that careful use of the address-mapping mechanisms of memory hardware could allow shared address space without changing

hand, it is our virtual the address

ACM Transactions on Computer Systems, Vol. 2, No. 1, February 1984

Document info
Document views47
Page views47
Page last viewedThu Oct 27 22:36:35 UTC 2016