From: Nathan Dire (ndire_at_cs.washington.edu)
Date: Sat Jan 31 2004 - 14:55:55 PST
In "Implementing Remote Procedure Calls", Birrell and Nelson present an
implementation of RPC for the Cedar Programming Environment on Xerox's
research internetwork. The basis for RPC is extending the familiar procedure
call mechanism to other processes on a network.
The authors' goal was to make distributed development easier. They also
wanted to make it flexible, efficient, and secure (as do we all!). Their
implementation of RPC consists of five pieces. First is the user, which is
the application making the remote calls on the caller machine. The user
application binds to a user-stub that marshals the parameters for the RPC
communication package, known as the RPCRuntime in this implementation. The
RPCRuntime communicates with another instance on the callee machine, which
passes the data to a server-stub for unmarshaling and execution by the server.
The results are passed back in a similar fashion.
Binding occurs is between an importer of and interface and the exporter. The
importer calls the procedures of the interface and the exported implements
them. Thus the user-stub exports an interface which is imported by the user,
and the server exports an interface which is imported by the server-stub. The
interface has two components: the type, which specifies the interface, and the
instance, which specifies the implementor of the interface. To locate an
exporter of an interface, the authors' employ the Grapevine Distributed
Database. Exporters register their interface and a connect-site with
Grapevine to make it available to users.
While RPC can be implemented using an existing transport protocol, Birrell
and Nelson implement their own for efficiency. The protocol is minimal,
designed for small amounts of data and has a very light-weight notion of
connections. The performance data is very limited and the paper doesn't
provide references for comparison, and so it's difficult to evaluate their
success in this regard.
With regards to this specific implementation, one question I have about the
architecture is the nature of the RPCRuntime. If it's a separate process, it
might add a lot of context switching and communication overhead. I'm not sure
why it wouldn't just be a linked into the user application or server (perhaps
it is and I misunderstand the structure). With regards to the basic concept,
I think many complex and/or performance critical applications may require a
more fine-grained approach to communication between processes, but RPC remains
an easy to use mechanism for distributed programming that's still popular
today.
This archive was generated by hypermail 2.1.6 : Sat Jan 31 2004 - 14:55:57 PST