From: Jeff Duzak (jduzak_at_exchange.microsoft.com)
Date: Tue Jan 27 2004 - 21:42:40 PST
In this paper, Birrell and Nelson describe in detail a system they have
implemented to support remote procedure calls between computers on the
Xerox internetwork. The goals of the implementation are high
performance and simple usage semantics.
The design of the system is very straightforward and powerful. The
first step in writing a program to use RPC is to define an interface
which specifies function names, argument counts and types, and return
values. Once the interface is specified, a tool called Lupine generates
stub functions for both the client and the server. On the client side,
a program can link with the stubs for a given interface and call those
stubs using a regular function call. On the server, any incoming RPC
call will be passed to a stub which will again use a regular function
call to invoke the implementation of that RPC. Hence, neither the
exporter nor importer of an RPC interface need know anything about the
mechanism of RPC.
The binding mechanism is again straightforward. A distributed database
is used to keep track of all published interfaces, and the names and
network addresses of all machines which implement those interfaces.
The paper goes into detail in describing the mechanism for transmitting
RPC data between two machines. Instead of using a high-level transfer
protocol, the system uses low level internet packets. The system of
exchanging packets is optimized for high performance in the case of fast
and frequent RPC calls, with not a large number of arguments. For
example, if an RPC is fast enough, the server machine (or exporter of
the RPC interface) need not send an acknowledgement of the RPC call, but
simply send a packet with the return value. Acknowledgements are used,
however, if the amount of data representing the arguments requires
multiple packets or if the server takes too long executing the RPC.
Hence, the protocol is not efficient for large data transfer.
The ideas in this paper were very familiar. For example, the idea of a
formal interface definition which tools would then use to facilitate
binding is familiar from COM. The general idea of making remote calls
appear as similar as possible to local calls is familiar from .Net web
methods.
The discovery mechanism that the authors use is enviable in its
simplicity, but doesn't seem feasible for generalized RPC development.
That is, it would require someone to maintain a central database of
servers implementing interfaces. Who would be responsible for that
database, and how that database would be made available to developers
would be a difficult problem.
This archive was generated by hypermail 2.1.6 : Tue Jan 27 2004 - 21:42:49 PST