Shuman Guo CSc 8320 Advanced Operating Systems 2.6 Major Design Issues Shuman Guo CSc 8320 Advanced Operating Systems

Outlines Design & Implementation Issues Summary References Object Models and Naming Schemes Distributed Coordination Interprocess Communication Distributed Resources Fault Tolerance and Security Summary References

A distributed system consists of three major components: Coordination of distributed processes management of distributed resources implementation of distributed algorithms These components may be unreliable. Thus raise the design and implementation issues, in particular how to support transparency. First, we need to know how objects in the system are modeled and identified.

Design & Implementation Issues Object Models and Naming Schemes Distributed Coordination Interprocess Communication Distributed Resources Fault Tolerance and Security These issues are briefly summarized in the following section. They are the major focuses of discussion in later chapters.

Object Models and Naming Schemes [1] Objects in a computer system : processes, data files, memory, devices, processors, and networks. Objects are encapsulated in servers process servers, file servers, memory servers A client is a null server that accesses object servers.

Cont’d Three possible ways to identify a server Identification by name (name server) Identification by either physical or logical address (network server) Identification by service that the servers provide

Distributed Coordination [1] Processes require coordination to achieve synchronization Types of synchronization: Barrier synchronization Condition coordination Mutual exclusion

Types of Synchronization Barrier synchronization Process must reach a common synchronization point before they can continue. Condition coordination A process must wait for a condition that will be set asynchronously by other interacting processes to maintain some ordering of execution. Mutual exclusion Concurrent processes must have mutual exclusion when accessing a critical shared resource.

Example: Logical Clocks

Deadlock Handling[5] Deadlock handling is a major process coordination tool for building distributed services. Four conditions must hold for deadlock to occur: Exclusive use Hold and wait. No preemption Cyclical wait Deadlock can occur whenever two or more processes are competing for limited resources and the processes are allowed to acquire and hold a resource (obtain a lock) thus preventing others from using the resource while the process waits for other resources. Exclusive use – when a process accesses a resource, it is granted exclusive use of that resource. Hold and wait – a process is allowed to hold onto some resources while it is waiting for other resources. No preemption – a process cannot preempt or take away the resources held by another process. Cyclical wait – there is a circular chain of waiting processes, each waiting for a resource held by the next process in the chain.

Deadlock Cont’d The problem of deadlocks can be handled in following ways Prevention Ensure that deadlock is not possible. Avoidance require decisions by the system while it is running in order to insure that deadlocks will not occur Detection When detected, decide which process to rollback or abnormally terminate.

Deadlock Prevention Schemes that guarantee the deadlocks can never happen because of the way the system is structured. One of the four conditions is prevented, thus preventing deadlocks. For example, to impose an order on the resources and require processes to request resources in increasing order. This prevents cyclical wait and thus makes deadlocks impossible.

Interprocess Communication[1] Lower level: Interprocess communication can be accomplished by using simple message passing primitives. Higher level logical communication methods provides the transparency: Hide the physical details of message passing Two important concepts : The client/server model Remote Procedure Call (RPC) Communication is perhaps the single most essential issue in any distributed system design, since everything relies on it. In operating system, interaction between processes and information flow between objects all depend on communication.

The Client/Server Model[1] The client/ server model is a programming example for structuring processes in distributed systems. logical communication request reply actual communication network client server In this model, all system interactions are viewed as a pair of message exchanges in which the client process sends a request message to a server and waits for the server to respond with a reply message. This request/reply message passing a analogous to the procedure-call concept in programming languages where a calling procedure passes parameters to a called procedure, kernel kernel

The RPC Model[3] The remote procedure call model is similar to that of the local model: The caller places arguments to a procedure in a specific location (such as a result register). The caller temporarily transfers control to the procedure. When the caller gains control again, it obtains the results of the procedure from the specified location. The caller then continues program execution.

RPC Cont’d On the server side, a process is dormant (inactive, sleeping)-- awaiting the arrival of a call message. When one arrives, the server process computes a reply that it then sends back to the requesting client. After this, the server process becomes dormant again. This figure shows a synchronous RPC call, in which only one of the two processes is active at a given time. The remote procedure call hides the details of the network transport.

How RPC works? Basic network communication with Remote Procedure Call

Other Examples: (1)CORBA[4] The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together. CORBA defines commonly needed services (such as transactions and security, events, time, and other domain-specific interface models)

CORBA Cont’d The diagram illustrates how the generated code is used within the CORBA infrastructure:

Other Examples: (2) JAVA RMI[4] The Java Remote Method Invocation API , or Java RMI is a Java application programming interface for performing the equivalent of remote procedure calls A typical implementation model of Java RMI using Stub and Skeleton objects.

Distributed Resources[1] Load Distribution multiprocessor scheduling (Static) load sharing (Dynamic) Distributed shared memory Distributed file systems Static load distribution in distributed systems is referred to as multiprocessor scheduling. If load distribution A transparent memory system is one that presents a single shared memory view of physically distributed memories. (perhaps load redistribution is a better term) is done dynamically, it is called load sharing.

Load Distribution Multiprocessor scheduling Load sharing Minimize communication overhead with efficient scheduling. Load sharing Process migration strategy & mechanism

Distributed File Systems and Distributed Shared Memory Issues are based on a file point of view Distributed shared memory Issues are based on a process perception of the system. The common issues central to them: Sharing and replication of data

Fault Tolerance and Security[1] Security threats and failures are both system faults. The problem of failures can be alleviated if there is redundancy in the system. The system should transparently handle failures or removal of machines, network links, and other resources without loss of data or functionality. This should hold true for both the system itself and for its applications.

Security Cont’d Security Authentication -- clients and also servers and messages must be authenticated. Authorization-- access control has to be performed across a physical network with heterogeneous components under different administrative units using different security models.

Security examples[4] Extensible Authentication Protocol (EAP) is a universal authentication framework frequently used in wireless networks and P2P connections EAP is not a wire protocol; instead it only defines message formats.

More Info about EAP EAP Authentication Protocols for WLANs [6] The relationship between 802.1X and EAP(introduction)[7] EAP Methods for 802.11 Wireless LAN Security[8]

Summary[1] Given the system architectures, we summarized the important design and implementation issues. These issues include object models and naming schemes, interprocess communication and synchronization, data sharing and replication, and failure and recovery. These problems are unique to distributed systems.

References [1] Randy Chow & Theodore Johnson, 1997,“Distributed Operating Systems & Algorithms”, (Addison-Wesley), p. 45 to 50, 61 to 63. [2] Suresh Sridharan, 2006, “Distributed Operating Systems “, (University of Wisconsin, Madison). http://pages.cs.wisc.edu/~dusseau/Classes/CS739/Writeups/Survey.pdf [3]http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q0R5B-TET1_html/onc-rpc2.html [4]Wikipedia. http://en.wikipedia.org/wiki [5] JoAnne L. Holliday and Amr El Abbadi, ”Distributed Deadlock Detection”, http://www.cse.scu.edu/~jholliday/dd_9_16.htm

References [6]Krishna Sankar, Andrew Balinsky, Darrin Miller, Sri Sundaralingam. (Feb 18, 2005)” EAP Authentication Protocols for WLANs”. http://www.ciscopress.com/articles/article.asp?p=369223&seqNum=3&rl=1 [7] “802.1X Port-Based Authentication HOWTO” http://tldp.org/HOWTO/8021X-HOWTO/intro.html [8]” EAP Methods for 802.11 Wireless LAN Security” http://www.iec.org/online/tutorials/eap_methods/topic01.html

Any Questions?