Early Internet & RPC

Readings

• Robert E. Kahn, "Resource-Sharing Computer Communications Networks" (1972):

This is one of the early papers describing the rationale behind the ARPANET (which later evolved into the Internet). For more background on the ARPANET, see Computer Networks - The Heralds of Resource Sharing (optional).

Note how both the ARPANET and and standard operating systems were developed to facilitate resource sharing.

• Bruce J. Nelson, Remote Procedure Call (1981):

You only need to read the thesis summary which starts at page 224 in the PDF. If you have time, however, I'd suggest looking at the rest, particularly the introduction and related work.

• Birrell & Nelson, "Implementing Remote Procedure Calls" (1984)

Compare the perspective of this RPC implementation description with the more design-oriented focus of Nelson's thesis.

Questions to be discussed

1. What did the (technical) world look like when this paper was published?
2. What is the paper about? What are the key ideas?
3. What is the basic argument of the paper, and what sort of evidence is used to make the argument?
4. To what extent do you "believe" the argument? Why?
5. What did the authors get right about the future? What did they miss about the future?
6. What has been forgotten since this paper?

Debate

Debate about the pros and cons of RPC. Topic: RPCs are the right foundation for the distributed applications (on today's Internet).

Pros

1. Easy to use
   • makes remote procedure calls look like local calls
   • local is easy
   • therefore remote is easy with RPC - good!
2. (Counter to first con) Use standards, problem goes away
3. Easy to debug
4. Avoids complexity of protocol design
5. RPC can be abstracted from the protocol design
6. (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise.
7. (Counter to fifth con) - wrong!
8. (Counter to seventh con) - Use standards (ORBs in CORBA, etc.) for authentication
9. (Counter to eighth con) - But you specify the API
10. (Counter to ninth con) - It's the same with other methods. But RPC makes it easier to do.

Cons

1. Language/implementation specific
2. (Counter to third pro) Not easy to debug. example: NullPointerException thrown on server, containing line of erroneous code running on the server.
3. Counter to fifth pro) But there is more overhead - slower
4. Synchronous - wrong model for large, distributed applications, and also bad for users
5. Limited scalability - hard to do well
6. Limited control of communication details
7. Authentication is opaque
8. Larger attack surface area
9. Poor match to listening (hard for server to communicate information back to client)
10. Backwards compatibility is difficult
11. RPC is not a "natural" interaction style - message passing is more similar to human communication
12. Too much to set up for simple applications
13. Less flexible

Anil's Comments

RPC makes the simple things very easy, but it doesn't help with the big challenges of distributed programming: robustness and security. If those factors are of minimal importance (e.g. you are programming an isolated cluster running a very high-performance application), then this trade-off doesn't matter. However, there exist other distributed programming paradigms that are easy to use but that still distinguish between accessing internal functions and communicating with external entities.

If we can keep the developer aware of when communication occurs, then there is a chance that developer will remember to do the input validation and error checking at those points, which is what is needed to make robust and secure applications.