DistOS 2014W Lecture 2: Difference between revisions
No edit summary |
though I am not the one who originally volunteered for the lecture notes for lecture 2 adding the notes I have in an attempt to capture the essence of discussions we had on the day |
||
| Line 1: | Line 1: | ||
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. 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 needs to be considered in this context are: How well can 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 - as 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 "such an attempt will be like Elephant riding a Unicycle" - helped to explain the reason behind the same, such system can be built but it would not be efficient/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 [https://en.wikipedia.org/wiki/TCP_IP| TCP and IP protocols]. | 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 [https://en.wikipedia.org/wiki/TCP_IP| TCP and IP protocols]. | ||
Anil observed that the Dist. OS 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. | Anil observed that the Dist. OS 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. | ||
Concluding the discussions 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. | |||
Revision as of 22:01, 21 January 2014
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. 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 needs to be considered in this context are: How well can 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 - as 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 "such an attempt will be like Elephant riding a Unicycle" - helped to explain the reason behind the same, such system can be built but it would not be efficient/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 Dist. OS 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.
Concluding the discussions 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.