From: Prasanna Kumar Jayapal (prasak_at_winse.microsoft.com)
Date: Mon Feb 02 2004 - 15:28:22 PST
This paper ("Implementing Remote Procedure Calls") describes the
structure, design, and implementation decisions made for the RPC
package. The idea behind RPC is to extend the semantics of procedure
calls within a program running on a single computer, to distributed
computing environments.
The authors start with describing their aim of making this RPC package
efficient, secure, to have powerful semantics and easy to use. Then,
they talk about the issues they face and the decisions they had to make
without compromising their aims. In their RPC design, there is no
support for calling by reference, timeouts and no provision for the use
of shared address spaces.
The RPC system consists of five pieces of programs - the user, the
user-stub, the RPC communication package (known as RPCRuntime), the
server-stub, and the server. The user, user-stub and one instance of
RPCRuntime execute in the caller machine, and the server, the
server-stub and another instance of RPCRuntime execute in the callee
machine. When a user wishes to make a remote call, it actually makes a
perfectly normal local call that invokes a corresponding procedure in
the user-stub, which is responsible for placing a specification of the
target procedure and arguments into one or more packets and asking the
RPCRuntime to transmit these reliably to the callee machine. On receipt
of these packets, the RPCRuntime in the callee machine passes them to
the server-stub. The server-stub unpacks them and again makes a
perfectly normal local call, which invokes the appropriate procedure in
the server. Meanwhile, the calling process is suspended awaiting a
result packet. RPCRuntime is responsible for retransmissions,
acknowledgements, packet routing, and encryption.
Binding is achieved by using the Grapevine distributed database. The
database maintains two tables, one for types of interface (of the
procedure call) and the other for instances, which may be the actual
name for the remote procedure offered. When an interface (of a module)
is exported by a server, the type and the instance are registered to the
database. A client, who wants to use an interface, looks up the server
address by giving the type and instance or just the type.
The RPC runtime uses its own specialized communications protocol for
transport of RPC packets that is lighter than traditional
connection-oriented protocols. The protocol is optimized for handling
simple calls on LAN environment; therefore it might not be suitable for
one way bulk data transmission. In this protocol, the machine that
transmits a packet is responsible for retransmitting it until an
acknowledgment. Caller process may call at most one outstanding remote
procedure at any time. No special connection establishment protocol is
required; receipt of a call packet from a previously unknown activity is
sufficient to create the connection implicitly, for last, no explicit
connection termination protocol is used.
The authors then discuss the techniques used to enhance the performance.
For example, when a server process is entirely finished with a call, it
reverts to its idle state instead of dying, thus saving the cost of
forking a process for each call. The performance analyses were nice to
read through although it was very brief. But overall, RPC seems like a
very powerful concept and is easy to use.
This archive was generated by hypermail 2.1.6 : Mon Feb 02 2004 - 15:28:18 PST