From: Raz Mathias (razvanma_at_exchange.microsoft.com)
Date: Wed Jan 28 2004 - 16:24:36 PST
This was a basic paper summarizing the issues in implementing remote
procedure calls. The ideal maintained throughout was that RPC's should
maintain the same semantics as regular procedure calls.
The paper introduced the basic mechanism of RPC calls. The simple idea
is that procedure calls are intercepted at the client side by a "client
stub." The stub passes the call to the RPC subsystem which marshals the
procedure call and parameters over to the server's RPC subsystem, which
calls into the server stub and finally into the procedure itself.
Returning a result is the reverse of this process. The paper described
how to detect both client and server crashes using the unique id and
sequence numbers, respectively. It briefly went over the problem of
mimicking remote exceptions by having the client stub raise them in a
manner indistinguishable from local procedure calls.
The importance of a directory system was put forth in this paper.
Grapevine was used as the networked directory system for looking up
bindings (on-the-network implementations of instances and interfaces for
procedure calls). Although such a system would not scale up to Internet
scales, a directory service is a useful concept in deployments the size
of large corporations. Three alternatives for binding were listed,
binding to an interface (with any instance on any machine), to an
instance (running on any machine) or to a network address (which is the
most restrictive). In trying to achieve procedural semantics, it seemed
to me that the authors could have gone a step farther to say that the
bindings needn't even be set explicitly by the calling application
(regular procedure calls don't require bindings). A central database on
the client machine can hold the bindings. They can be configured by a
separate application separate of the app doing the RPC's. This would be
akin to the model of creating a configuration file, etc. Bindings can be
resolved at the same layer where they are issued.
The idea of a networked virtual memory paging mechanism to achieve a
global shared memory space was a new one to me. Although this paper
didn't directly speak to such an implementation, (and in fact rejected
such an approach for performance reasons) it would be interesting to
look up the references to others that do.
The paper began by listing the basic problems encountered when
implementing RPC's. The set of issues included sharing pointer-rich
data, machine/communication failures, integration of RPC into existing
systems, binding, protocols, data integrity, and security. These issues
basically encompass the computer science topic of distributed computing
in general and could not possibly be addressed fully in this paper, and
in fact most were not. The paper mentioned that the various layers were
not kept separate for the purpose of optimizing the system. An example
of where this was not a good idea was the description of the transfer
protocol. The only "advantage" it really put forth was the fact that
RPC results are ACK's for RPC requests; a simple implementation of the
TCP protocol would ensure this optimization. The paper stated that no
"ping requests" were required to keep the connection alive (as this
paper claimed that there is no real concept of a connection), and yet on
the very next page it introduced the concept of a "probe" to determine
whether the computation was still running on the remote machine.
Without some sort of windowing, the transmission protocol introduced
here would have done horribly on large buffers (although it does,
commendably, admit to this flaw near the end of the paper).
The overview of the mechanisms in this paper (RPC and the Grapevine
directory system) is still relevant today with COM and the Active
Directory as an example. Unfortunately, the discussion of the
transmission protocol and the cursory way in which the topics were
glossed over made this paper seem "watered down" and my least favorite
so far.
This archive was generated by hypermail 2.1.6 : Wed Jan 28 2004 - 17:21:39 PST