X hits on this document

50 views

0 shares

0 downloads

0 comments

11 / 21

Implementing Remote Procedure Calls

  • 49

too complicated for this paper, but in summary it allows an importer to bind his program to several exporting machines, even when the importer cannot know statically how many machines he wishes to bind to. This has proved to be useful in some open-ended multimachine algorithms, such as implementing the manager of a distributed atomic transaction. We have not allowed binding at a finer grain than an entire interface. This was not an option we considered, in light of inutility of this mechanism in the packages and systems we have observed.

  • 3.

    PACKET-LEVEL TRANSPORT PROTOCOL

    • 3.1

      Requirements

The semantics of RPCs can be achieved without designing a specialized packet- level protocol. For example, we could have built our package using the PUP byte stream protocol (or the Xerox NS sequenced packet protocol) as our transport layer. Some of our previous experiments 13 were made using PUP byte streams,

and

the

Xerox

NS

"Courier"

RPC

protocol

4

uses

the

NS

sequenced

packet

protocol. Grapevine protocols are essentially similar to

and

use

PUP

byte

streams.

Our

measurements

13

and

remote procedure calls, experience with each of

these

implementations

convinced

us

that

this

approach

was

unsatisfactory.

The

particular nature performance gains

of RPC available

communication means that there are substantial if one designs and implements a transport protocol

specially for of ten might

RPC. Our experiments be possible.

indicated

that

a

performance

gain

of

a

factor

An intermediate stance might be tenable: we have never tried the experiment of using an existing transport protocol and building an implementation of it specialized for RPC. However, the request-response nature of communication with RPC is sufficiently unlike the large data transfers for which bytes streams are usually employed that we do not believe this intermediate position to be tenable.

One aim we emphasized in our protocol design was minimizing the elapsed real-time between initiating a call and getting results. With protocols for bulk data transfer this is not important: most of the time is spent actually transferring the data. We also strove to minimize the load imposed on a server by substantial numbers of users. When performing bulk data transfers, it is acceptable to adopt schemes that lead to a large cost for setting up and taking down connections, and that require maintenance of substantial state information during a connec- tion. These are acceptable because the costs are likely to be small relative to the data transfer itself. This, we believe, is untrue for RPC. We envisage our machines being able to serve substantial numbers of clients, and it would be unacceptable to require either a large amount of state information or expensive connection handshaking.

It is this level of the RPC package that defines the semantics and the guarantees we give for calls. We guarantee that if the call returns to the user then the procedure in the server has been invoked precisely once. Otherwise, an exception is reported to the user and the procedure will have been invoked either once or not at all--the user is not told which. If an exception is reported, the user does not know whether the server has crashed or whether there is a problem in the communication network. Provided the RPCRuntime on the server machine is

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

Document info
Document views50
Page views50
Page last viewedFri Oct 28 10:39:31 UTC 2016
Pages21
Paragraphs669
Words10995

Comments