DistOS 2014W Lecture 2

From Soma-notes
Revision as of 15:51, 24 April 2014 by Josh brach (talk | contribs) (Cleaned up a bit; fixed some minor grammar; connected discussion to previous and future topics where relevant.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Abstractions in a Distributed Operating System (DOS)

Anil's view is that, though it is desirable to achieve a single system view, it’s a fool's errand to think that a 100% transparent single system view is achievable in the Distributed Operating system's Paradigm. An important question that needs to be answered while designing a DOS is how to ensure order in the Distributed System - in terms of (a) How to control participating systems (b) How the knowledge about constituent systems is passed around. So it becomes critical to look at how DOS achieves abstraction, enables and makes use of abstractions in realizing a system you want to use/program. Some of the aspects that need to be considered in this context are: How well can a DOS can realize the standard abstractions: Virtual Memory, File System Storage etc.

Towards building a Distributed system (scalable, reliable, maintainable) that should work perfectly it has to be based on abstractions representing the required system instead of building a system based on illusions. Anil pointed out: the tendency to make DOS behave as a centralized single system OS is a prominent pit-fall to avoid in the design of the Distributed Operating Systems. Such an approach would not be good in terms of performance and the analogy used was "such an attempt will be like Elephant riding a Unicycle" i.e. such system can be built, but it would be neither efficient nor fast and the performance would not be ideal.


We now have a working definition of a Distributed OS, so we look a little closer at the underlying network. The internet (and thus the vast majority of distributed OS work today) occurs over the TCP and IP protocols.

Anil observed that the DOS abstractions which succeed are ones that don't hide the network. For example, the remote procedure call (RPC) style abstractions have generally failed because they try to hide the untrusted nature of the network. The result has been a hodge-podge of firewall software which is primarily for blocking RPC-based protocols like SMB, NFS, etc. REST, on the other hand, has succeeded on the open web because it doesn't "hide the network" in this way. So we want to abstract away the details of how the network exists without abstracting away the fact that the network exists. This means that a non-distributed operating system will never transparently port to a distributed environment, which is probably for the best considering how a DOS solves different problems using different methods than a classic OS. Compare and contrast with Plan 9 which attempts to 'extend' the UNIX model to a distributed environment: it cannot do so entirely transparent of the network.

Rest of Course

Concluding the discussion, Anil mentioned that the focus of the course will be on: How do you build new abstractions and software services enabling Distributed Operating System, and not on approaches which takes single system Operating System and tries to turn it into a Distributed Operating System.