From: Richard Jackson (richja_at_expedia.com)
Date: Wed Jan 28 2004 - 16:49:41 PST
This 1983 paper by Birrell and Nelson provides an interesting
perspective about the initial implementations of RPC or Remote Procedure
Call. This paper describes an implementation of RPC focusing on
high-level system design, client binding, and transmission issues.
The paper focuses on the following major areas: 1)high-level design of
Xerox RPC system, 2) binding, 3)discussion of lower-level data
transmission issues, 4)performance.
The first section describes the basic problem space. The authors
describe how a RPC mechanism needs to exist, such that many semantics of
local procedure calls are still preserved. Other RPC systems had
previously been proposed by Nelson, but this paper claims that Nelson's
ideas were not complete, and therefore required more research. Thus,
this paper documents how Xerox built its own version of a RPC system,
which feels very similar to RPC mechanisms of today. They outline these
four main goals for their RPC system: 1) easy to use for distributed
applications, 2) highly efficient, 3) must contain powerful semantics to
avoid requiring additional per-application components, 4) secure
communication. Of these, the paper indicates that #1 and #3 were met.
I'd argue that #2 is weakly met, and #4 was barely discussed. The
authors claim that security was beyond the scope of this paper, but I
think that the section on binding had major security problems which
should have been addressed. Finally, the general skeleton of RPC was
defined, which included 5 pieces: 1) user(application), 2) user stub,
3) RPC runtime(client and server each have this, separated by a
network), 4) server stub, 5) server. Just by inferring the meaning of
these 5 pieces, it is easy to see how this framework would be used
generically to build a RPC-enabled application.
The concept of binding was discussed. This is essentially the mechanism
by which a client knows how to call a RPC on another machine. Xerox
used a distributed database called Grapevine to keep track of binding
parameters. This data would be updated whenever interfaces change, and
would be queried by clients as needed. Overall, this concept seems
really foreign to me, as I don't think there should be a central
repository for data in a distributed system such as this. Of course,
for a large, dynamic network, I suppose that locating RPC services was
often problematic.
The next section described the underlying transport mechanisms. The
essence is that the RPC runtime abstracted all retransmission and
acknowledgement logic, so that the client could really treat this as it
would a local function call. Transmissions are guaranteed to be made
zero or one time. Duplicates can not happen. Timeouts do not exist, so
a client could potentially wait forever. Two forms of calls are
discussed, simple and complicated. The distinction was not completely
obvious, but it seemed that simple calls fit into a single packet, while
the complicated calls require multiple packets. In the latter case, a
series of acknowledgements are also sent, making the protocol seem quite
expensive. Security is mentioned, but not discussed. Surely, security
is important to prevent unauthorized users from invoking an arbitrary
RPC, and also protecting the in-transit data. Also, without a security
enhancement, the existing mechanism to distribute binding
info(Grapevine) seems to indicate "security via obscurity."
The final section discusses performance, and generally concludes that
performance is acceptable for non-bulk-transfer applications. I found
it very interesting that most of the performance penalty was not due the
transmission times, but rather the RPC layer itself. I think this could
be improved.
Overall, the paper was interesting, but I found some of the ideas to be
weakly supported. For example, their idea of using RPC as a
special-case network protocol that receives special treatment by the
network driver seemed just wrong. Also, their limited discussion of
security left me wondering if I'd be able to trust this RPC system.
This archive was generated by hypermail 2.1.6 : Wed Jan 28 2004 - 17:02:29 PST