Locus, V, Mach: Difference between revisions
No edit summary |
No edit summary |
||
Line 25: | Line 25: | ||
# RPC can be abstracted from the protocol design | # RPC can be abstracted from the protocol design | ||
# (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise. | # (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise. | ||
# | # (Counter to fifth con) - wrong! | ||
# (Counter to seventh con) - Use standards (ORBs in CORBA, etc.) for authentication | |||
# (Counter to eighth con) - But you specify the API | |||
# (Counter to ninth con) - It's the same with other methods. But RPC makes it easier to do. | |||
===Cons=== | ===Cons=== | ||
Line 36: | Line 39: | ||
# Authentication is opaque | # Authentication is opaque | ||
# Larger attack surface area | # Larger attack surface area | ||
# Poor match to listening (hard for server to communicate information back to client) | |||
# Backwards compatibility is difficult | |||
# RPC is not a "natural" interaction style - message passing is more similar to human communication | |||
# Too much to set up for simple applications | |||
# Less flexible | |||
==Questions to be discussed== | ==Questions to be discussed== |
Revision as of 20:48, 16 January 2008
Readings
David R. Cheriton, "The V Distributed System."
Bruce Walker et al., "The LOCUS Distributed Operating System."
These two papers describe V and LOCUS, two early distributed operating systems.
This paper describes some key ideas behind Mach, a seminal microkernel-based operating system. The design of Mach informs later work in distributed operating systems. For more background on Mach, I suggest reading Wikipedia's article on Mach.
Debate
Debate about the pros and cons of RPC. Topic: RPCs are the right foundation for the distributed applications (on today's Internet).
Pros
- Easy to use
- makes remove procedure calls look like local calls
- local is easy
- therefore remove is easy with RPC - good!
- (Counter to first con) Use standards, problem goes away
- Easy to debug
- Avoids complexity of protocol design
- RPC can be abstracted from the protocol design
- (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise.
- (Counter to fifth con) - wrong!
- (Counter to seventh con) - Use standards (ORBs in CORBA, etc.) for authentication
- (Counter to eighth con) - But you specify the API
- (Counter to ninth con) - It's the same with other methods. But RPC makes it easier to do.
Cons
- Language/implementation specific
- (Counter to third pro) Not easy to debug. example: NullPointerException thrown on server, containing line of erroneous code running on the server.
- Counter to fifth pro) But there is more overhead - slower
- Synchronous - wrong model for large, distributed applications, and also bad for users
- Limited scalability - hard to do well
- Limited control of communication details
- Authentication is opaque
- Larger attack surface area
- Poor match to listening (hard for server to communicate information back to client)
- Backwards compatibility is difficult
- RPC is not a "natural" interaction style - message passing is more similar to human communication
- Too much to set up for simple applications
- Less flexible
Questions to be discussed
- What did the (technical) world look like when this distributed OS was designed & implemented?
- What are the key design features of the OS? What are the key compromises?
- To what extent is their system a "distributed operating system"?
- What is the basic argument for their design choices? What evidence do they cite in their favor?
- To what extent do you "believe" their design choices were right? Why?
- To what extent does their design work in the context of the modern Internet? Discuss wins and limitations.
- What concepts from the paper have been adopted by today's systems? What concepts should be adopted? What should be ignored?