From: Ian King (iking_at_killthewabbit.org)
Date: Wed Jan 28 2004 - 09:31:54 PST
The authors describe a protocol for abstracting the language concept of a
procedure call so that it can be meaningfully conveyed to a remote computer.
The implementation is in support of a custom language, Mesa, on a particular
hardware platform, Dorado; it employs low level network abstractions in Xerox's
network protocol suite of the era. The goal is to duplicate the model of a
local procedure call (reasonably) transparently for both the caller and callee
(client and server); the work is evaluated by experimentally examining latency
for invocation of identical local and remote procedures.
There are some ideas that are implicitly simple, and what is needed is someone
to sit down and draw up a protocol that takes into account the general case, the
boundary cases and the error cases. In this paper, the authors acknowledge that
the concept of RPC has been discussed before, including in the dissertation of
one of them. However, their work discusses actual implementation, which shakes
out many details.
They have thoughtfully optimized for the common case: I've heard the statistic
that the bulk of procedure calls contain no more than three arguments. Then,
too, the protocol is as significant for what it does NOT do as what it does -
for instance, rather than implementing a timeout, this implementation models the
error scenario of a call that just doesn't return, which happens in local calls,
too. They acknowledge that RPC is significantly slower than other transport
protocols for large bytestreams, but it is noteworthy that it WILL perform such
transfers when needed. I also appreciate that the authors acknowledge they are
"flying below the radar" of the network suite; part of their efficiency arises
from the fact that no one else is (or was) doing the same. Nonetheless,
experience has demonstrated that lower level protocols are less
processor-intensive, and the RPC protocol provides sufficient out-of-band
delivery assurances to allow for so-called unreliable transport protocols to be
used effectively.
This implementation is particularly dependent on the Grapevine database, but the
requirements placed on Grapevine are easily abstracted to other mechanisms; the
database is a source of security, and therefore represents another potential
weakness for a given implementation. Encryption is also cited as a security
mechanism and, while certainly feasible, is likely to impact performance. Also,
this implementation's reliance on sequencing based on the system clock is
obviously unacceptable for a commercial, high-bandwidth deployment; this is
implicitly acknowledged, and such details as sequence numbers and packet
identifiers could easily become a serious issue in a robust implementation.
This archive was generated by hypermail 2.1.6 : Wed Jan 28 2004 - 09:43:10 PST