Features of Distributed Operating System
There are various important goals that must be met to build a distributed system worth the effort. A distributed system should easily connect users to resources, it should hide the fact that resources are distributed across a network, must be open, and must be scalable.
- Connecting Users and Resources :
The main goal of a distributed system is to make it easy for users to access remote resources, and to share them with other users in a controlled manner. Resources can be virtually anything, typical examples of resources are printers, storage facilities, data, files, web pages, and networks. There are many reasons for sharing resources. One reason is economics.
- Transparency :
An important goal of a distributed system is to hide the fact that its process and resources are physically distributed across multiple computers. A distributed system that is capable of presenting itself to users and applications such that it is only a single computer system is called transparent.
The concept of transparency can be applied to many aspects of a distributed system as shown in table.
Different Forms of Transparency –
|(1)||Access||Hide data representation.|
|(3)||Migration||Move place information.|
|(4)||Relocation||Hide moved place relocation.|
|(5)||Replication||Hide that a resource is replication.|
|(6)||Concurrency||Shared data bases access|
|(7)||Failure||Hide fact about resource failure.|
|(8)||Persistence||Hide fact about memory location.|
- Openness :
Another important goal of distributed systems is openness. An open distributed system is a system that offers services in standards that describable the syntax and semantics of those service instances, standard rules in computer networks control the format, content, and meaning of messages sent and received. Such rules are formalized in the protocols. In distributed systems, services are typically specified through interfaces, often called interface definition languages (IDL). Interface definitions written in IDL almost always capture only the syntax of services. They accurately specify the names of functions that are available with the types of parameters, return values, possible exceptions that can be raised and so on.
- Scalability :
The uncertain trend in distributed systems is towards larger systems. This observation has implications for distributed file system design. Algorithms that work well for systems with 100 machines can work for systems with 1000 machines and none at all for systems with 10, 000 machines. for starters, the centralized algorithm does not scale well. If opening a file requires contacting a single centralized server to record the fact that the file is open then the server will eventually become a bottleneck as the system grows.
- Reliability :
The main goal of building distributed systems was to make them more reliable than single processor systems. The idea is that if some machine goes down, some other machine gets used to it. In other words, theoretically the reliability of the overall system can be a Boolean OR of the component reliability. For example, with four file servers, each with a 0.95 chance of being up at any instant, the probability of all four being down simultaneously is 0.000006, so the probability of at least one being available is (1-0.000006)= 0.999994, far better than any individual server.
- Performance :
Building a transparent, flexible, reliable distributed system is useless if it is slow like molasses. In particular application on a distributed system, it should not deteriorate better than running some application on a single processor. Various performance metrics can be used. Response time is one, but so are throughput, system utilization, and amount of network capacity consumed. Furthermore, The results of any benchmark are often highly dependent on the nature of the benchmark. A benchmark involves a large number of independent highly CPU-bound computations which give radically different results than a benchmark that consists of scanning a single large file for same pattern.