From: Gang Zhao (galaxy_at_cs.washington.edu)
Date: Mon Feb 02 2004 - 23:33:39 PST
The RPC paper is the first that I can see direct connection to my job. Not that the state of the world, but it explains how we got there.
The RPC paper makes a good case for why remote procedures should exist at all. The explanation that this allowed for simpler extension from single machine to multiple machine is compelling. Also the fact (as we have seen from this and other papers) that fork is difficult to implement makes this solution make sense.
The stub modules seemed the biggest leap. But it seemed that seemed to come out of the interface language, Lupine. It is not clear from the paper whether this existed first or whetehr it was created for RPC. If it hadn't existed already, it clearly would have needed to be created.
The one thing that doesn't seem to have been handled at all by this paper is the concept of callbacks. This problem would need to be solved before this could work on an object oriented language. But as it stands the paper does seem to preclude object oriented languages by forbidding all pointers.
Naming as specified in the papers isn't really yet unique. When were GUIDs created and when did they become the defacto standard?
The packet description is nice. While it seems heavyweight (and they talk about efficiency) the overall goal of making this as close to a LPC is achieved by sending lots and lots of packets, with an acknowledgement (of some form) sent for every packet.
Their modification of the network driver software to treat RPC as a special case turned out to be the correct bet, since RPC has become pretty dominant.
The timing numbers seemed a bit hand-waving, but good enough to see overall trends, that a remote call is significantly more expensive than a local call, but not too bad.
This paper was nice for its historical prospective.
This archive was generated by hypermail 2.1.6 : Mon Feb 02 2004 - 23:33:45 PST