From: David Coleman \(Roxio Inc\) (v-davcol_at_windows.microsoft.com)
Date: Wed Jan 28 2004 - 16:18:01 PST
"Implementing Remote Procedure Calls" by Andrew Birrel and Bruce Nelson
describes their research and efforts implementing RPC; they explicitly
note that several previous papers had been paper-only system and they
encountered some poorly understood areas. Unfortunately they didn't
elaborate on these areas at all or how their approach differed from
previous work (much).
Their basic concept is that programs call through interfaces and the
modules that implement those interfaces can reside anywhere on the
network. A global locator service, Grapevine in this case, is used to
bind instances of interfaces to locations. Stub functions are used to
make the calls effectively transparent to the caller. Pointers cannot
be sent to RPCs due to the lack of a shared address space - I would have
expected them to marshal that data (obviously not embedded pointers
however).
The authors mention that security and protection were considered and are
supported. They did not discuss their approach in much detail. They
allow for the packets to be encrypted. Grapevine enforces access rights
which will prevent an unauthorized entity from placing an export entry
in the database which prevents the possibility of Trojan Horse-style
attacks. Any results returned from Grapevine for object location can be
considered to be secure. However, the concept of revocation was never
discussed and is not clear if it is supported.
It appears that the server must always be running in order to serve
requests. There doesn't seem to be a mechanism in place for the
RPCRuntime on the server machine to start up the server process upon an
attempt to call a server function. This can obviously lead to
significant overhead.
Their approach was to model local procedure calls to ensure the
transparency. This is a very useful goal in that it makes using RPC
very easy for caller. However, I would have liked to have seen
asynchronous RPC as well. They did pretty much support that via
lightweight process creation and then making the call in the process,
but I can see value for truly asynchronous calls.
Overall, as I was reading this paper my first thought was: COM. Again
it makes me realize just how much of our technology and industry today
is based on pioneering, well thought out, early work.
This archive was generated by hypermail 2.1.6 : Wed Jan 28 2004 - 16:18:07 PST