From: Manish Mittal (manishm_at_microsoft.com)
Date: Wed Jan 28 2004 - 17:21:36 PST
This paper describes a package which provides a remote procedure call
(RPC) facility and explains some of the design ideas and decisions
involved in it. The basic motivation the authors provide for the
implementation of an RPC package is to ease the process of writing
distributed applications.
RPCs are implemented using Stubs. From the user's standpoint, a normal
procedure call has taken place, when in reality the control has been
transferred to the local stub, which is responsible for packaging the
arguments and handing them to the RPCRuntime. The runtime then transfers
the arguments to the server, who receives them and gives them to the
server stub, who unpacks the arguments for local execution. This
procedure is executed again, in reverse order to return the function
result. The appropriate stubs can be automatically generated by a tool.
Before a procedure may be remotely called on a server, it must be
explicitly made available by "exporting" the interface using RPCRuntime.
The interface consists of a "type" (abstraction of the available
service) and "instance" (unique to a single machines exported interface)
and is managed via Grapevine databases. A "user" (importer) wishing to
make an RPC call must bind to an exporter. The importer calls its
user-stub which in turn specifies the desired interface type and
instance to RPCRuntime, which uses Grapevine to determine the server
address. If a call is made by specifying an interface type without an
instance then Grapevine will attempt to locate the closest exporter of
that interface.
In the implementation of the protocol, the author's tries to make the
RPC semantics to be as close as that of the local procedure calls. This
is achieved in a number of ways. For example, the RPC protocol does not
use timeouts i.e. a given process could only make one RPC at a time. The
paper also discusses a number of ways to optimize the performance of
RPC. Subsequent packets are used for implicit acknowledgment of previous
packets, this way the costs of maintaining connections are minimized.
The authors try to avoid costs of establishing and terminating
connections. Furthermore, data are encrypted when they are transmitted
on the network. The concept of 'Probe' packets is also noteworthy. Since
there are no timeouts in the RPC protocol, client can check if the
server has crashed by asking for explicit acknowledgement of "probe"
packets.
The authors give experimental data on the performance of remote
procedure calls versus local calls. RPCs are orders of magnitude slower
than local calls, but then the RPCs are not meant to compete directly
with local calls. Rather, the advantages of RPC's will be realized in
distributed applications.
This archive was generated by hypermail 2.1.6 : Wed Jan 28 2004 - 17:21:58 PST