AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
PART – A 1. What are the significance of distributed system? a.
Concurrency of computers.
b.
b. No global clock.
c. c. Independent failures.
2. What is meant by location aware computing? Users can continue to access the intranet, as in their home intranet via the devices they carry with them, and there is increasing provision for users to utilize resources such as printers that are conveniently nearby as they move around. This is known as location aware computing.
3. What are the security challenges? List them. a. Denial of service attacks: The user may wish to disrupt a service for some reason. This can be achieved by bombarding the service with such a large number of pointless requests that the serious users are unable to use it. This is called a denial of service attack. b. Security of mobile code: Mobile codes needed to be handled with care. PC users sometimes send executable files as email attachments to be run by the recipient, but a recipient will not be able to run it.
4. What are the failures detected in DS? Masking failures: Some detected failures can be hidden or made less severe. Examples of hiding failures: 1. Messages can be retransmitted when they fail to arrive 2. File data can be written to a pair of disks that if one is corrupted, the other may still be correct. Tolerating failures: Most of the services in the Internet do exhibit failures. It would not be practical for them to detect and hide all the failures occur in such network. Their clients are designed to tolerate failures, which generally involve the users in that. Recovery from failures: involves the design of software so that the state permanent data can be rolled back after a server has crashed. 5. Define interprocess communication.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Interprocess communication - refers to low-level communication between processes in distributed systems such as message-passing, direct access to the API and support for multicast communication. 6. What is remote invocation? Remote invocation – represents techniques based on a two-way message exchange between communicating entities in a distributed system and results in the calling of a remote operation, procedure or method. 7. Define overlays. An overlay network is a virtual network of nodes and logical links that is built on top of an existing network with the purpose to implement a network service that is not available in the existing network. 8. What is network virtualization? Network virtualization: construct many different virtual networks over an existing network such as internet a. Support specific services needed b. Answers end-to-end argument c. Application specific virtual network 9. What are persistent objects? An object that is guaranteed to live between activations of processes is called a persistent object. 10. Define publish-subscribe systems. A publish-subscribe system is a system where publishers publish structured events to an event service and subscribers express interest in particular events through subscriptions. 11. List the characteristics of peer to peer systems. Peer-to-peer systems share these characteristics a. Each system share resources b. They may unique or duplicate c. Correct operation does not depends on any server d. Limited degree e. Algorithms for placing resources
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
12. What is name resolution? Name resolution is an iterative or recursive process whereby a name is repeatedly presented to naming contexts in order to look up the attributes to which it refers. A naming context either maps a given name onto a set of primitive attributes (such as those of a user) directly, or maps it onto a further naming context and a derived name to be presented to that context. 13. Define LDAP. The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services. 14. List the characteristics of AFS. AFS has two unusual design characteristics: 1. Whole-file serving: The entire contents of directories and files are transmitted to client computers by AFS servers. 2. Whole-file caching: Once a copy of a file or a chunk has been transferred to a client computer it is stored in a cache on the local disk. The cache contains several hundred of the files most recently used on that computer. The cache is permanent, surviving reboots of the client computer. Local copies of files are used to satisfy clients’ open requests in preference to remote copies whenever possible. 15. List the Lamport’s Happened before relationship. HB1: if e →i e' in process pi, then e → e' ` HB2: for any message m, send(m) → receive(m) HB3: if e → e' and e' → e'', then e → e'' 16. Define Transaction. A Transaction defines a sequence of server operations that is guaranteed to be atomic in the presence of multiple clients and server crash. 17. List the properties of distributed transactions. Atomicity - A transaction either completes successfully, and effects of all of its operations are recorded in the object, or it has no effect at all. Consistency – A transaction takes the system from one consistent state to another consistent state.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Isolation - Each transaction must be performed without interference from other transactions. The intermediate effects of a transaction must not be visible to other transactions. Durability - after a transaction has completed successfully, all its effects are saved in permanent storage for recover later. 18. List the problems of concurrent transactions. Lost update problem. Inconsistent retrievals. Serial Equivalence Conflicting operations 19. Explain the implementation of locks. The granting of locks will be implemented by a separate object in the server that we call the lock manager. The lock manager holds a set of locks, for example in a hash table. Each lock is an instance of the class Lock and is associated with a particular object. Each instance of Lock maintains the following information in its instance variables: o the identifier of the locked object; o the transaction identifiers of the transactions that currently hold the lock (shared locks can have several holders); o a lock type. 20. Define Wait –for graph. A wait-for graph can be used to represent the waiting relationships between current transactions. In a wait-for graph the nodes represent transactions and the edges represent wait-for relationships between transactions – there is an edge from node T to node U when transaction T is waiting for transaction U to release a lock. 21. List the activities in process migration mechanism. Four major activities Freezing the process on its source node and restarting it on its destination node. Transferring the process’s address space from its source node to its destination node. Forwarding massages meant for the migrant process. Handling communication between cooperating processes that have been separated as a result of process migration.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
22. Define Handoff and affinity scheduling. Handoff scheduling Allows a thread to name its successor if it wants to. Provides flexibility to bypass the queue of runnable threads and directly switch the CPU to the thread specified by the currently running thread. Affinity scheduling A thread is scheduled on the CPU it last ran on in hopes that part of its address space is still in that CPU’s cache. Gives better performance on a multiprocessor system. 23. State the types of process scheduling techniques Task assignment approach User processes are collections of related tasks Tasks are scheduled to improve performance Load-balancing approach Tasks are distributed among nodes so as to equalize the workload of nodes of the system Load-sharing approach Simply attempts to avoid idle nodes while processes wait for being processed. 24. State the concept behind Task assignment approach. The concept behind task assignment approach is finding an optimal assignment to achieve goals such as the following: a. Minimization of IPC costs b. Quick turnaround time of process c. High degree of parallelism d. Efficient utilization of resources
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
PART – B 1. What are request reply protocols? Explain the working of request reply protocols.
Supports message exchanges in client server interactions. Request reply is synchronous because the client process blocks until the reply arrives from the server. Reliable because the reply from the server is effectively an acknowledgement to the client. Asynchronous request-reply communication is used in situations where clients sends reply latter. The request-reply protocol Uses three communication primitives: doOperation, getRequest and sendReply, as shown in Figure 2.16
Fig. 2.16 Request-reply Communication
The request-reply protocol matches requests to replies. The delivery guarantees must be provided by the request-reply protocol. The server reply message can be used as an acknowledgement of the client request message. Figure 2.16 outlines the three communication primitives.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Fig. 2.17 Operations of the request-reply protocol
The doOperation method is used by clients to invoke remote operations. Its arguments specify the remote server and which operation to invoke, together with additional information (arguments)needed by the operation. Its result is a byte array containing the reply.
The first argument of doOperation is an instance of the class RemoteRef, which represents references for remote servers. This class provides methods for getting the Internet address and port of the associated server. The doOperation method sends a request message to the server whose Internet address and port are specified in the remote reference given as an argument. After sending the request message, doOperation invokes receive to get a reply message, from which it extracts the result and returns it to the caller. The caller of doOperation is blocked until the server performs the requested operation and transmits a reply message to the client process.
The getRequest is used by a server process to acquire service requests. When the server has invoked the specified operation, it then uses sendReply to send the reply message to the client. When the reply message is received by the client the original doOperation is unblocked and execution of the client program continues. The information to be transmitted in a request message or a reply message is shown in Figure 2.18
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Fig.2.18 Request reply message structure
The first field indicates whether the message is a Request or a Reply message. The second field, requestId, contains a message identifier. A doOperation in the client generates a requestId for each request message, and the server copies these IDs into the corresponding reply messages. This enables doOperation to check that a reply message is the result of the current request, not a delayed earlier call. The third field is a remote reference. The fourth field is an identifier for the operation to be invoked.
Message Identifiers Each message should have a unique identifier by which it can be referenced. A message identifier consists of two parts: o A requestId, an increasing sequence of integers selected by the sending process; o An identifier for the sender process, for example, its port and Internet address. Failure model of the request-reply protocol If the three primitives doOperation, getRequest and sendReply are implemented over UDP datagrams, then they suffer from the same communication failures. That is: o They suffer from omission failures. o Messages are not guaranteed to be delivered in sender order. Timeouts In case of timeout in doOperation o Return immediately from doOperation with an indication to the client that the doOperation has failed. o The timeout may be due to the request or reply message getting lost. To compensate for the possibility of lost messages, doOperation sends the request message
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
repeatedly until either it gets a reply or it is sure that the delay is due to lack of response from the server. o When doOperation returns, it will indicate to the client by an exception that no result was received. Discarding duplicate request messages Retransmitting the request message results in receiving it more than once. To avoid this, the protocol is designed to recognize successive messages with the same request identifier and to filter out duplicates. If the server has not yet sent the reply, it will transmit the reply when it has finished executing the operation. Lost reply messages If the server has already sent the reply and it receives a duplicate request it need not execute the operation again. An idempotent operation is an operation that can be performed repeatedly with the same effect each time. A server whose operations are all idempotent need not take special measures to avoid executing its operations more than once. Styles of exchange protocols Three protocols, that produce differing behaviours in the presence of communication failures are used for implementing various types of requests. o The request (R) protocol; o The request-reply (RR) protocol; o The request-reply-acknowledge reply (RRA) protocol. In the R protocol, a single Request message is sent by the client to the server. The R protocol may be used when there is no value to be returned and the client requires no confirmation. The client may proceed immediately after the request message is sent. The RR protocol is based on the request-reply protocol. No special acknowledgement messages are not required, server’s reply message is regarded as an acknowledgement. The RRA protocol is based on the exchange of three messages: request-reply-acknowledge reply. The Acknowledge reply message contains the requestId from the reply message being acknowledged. Use of TCP streams to implement the request-reply protocol The major issue in communication protocols is the buffer size for storing datagrams. If the TCP protocol is used, it ensures that request and reply messages are delivered reliably, so there is no need for retransmission of messages and filtering of duplicates. In addition the flow-control mechanism allows large arguments and results to be passed.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Successive requests and replies between the same client-server pair can be sent over the same stream minimizing connection overhead involved in remote invocation. The overhead due to TCP acknowledgement messages is reduced since a reply message follows soon after a request message. If the application does not require all of the facilities offered by TCP, then UDP can be implemented.
2. a) Explain about message queues.
Message queues are an important category of indirect communication systems. Whereas groups and publish subscribe provide a one-to-many style of communication, message queues provide a point-to-point service. Also referred to as Message-oriented middleware.
Programming model
Programming model is very simple. Producer processes can send messages to a specific queue and other (consumer) processes can then receive messages from this queue. Three styles of receive are generally supported: o a blocking receive, which will block until an appropriate message is available; o a non-blocking receive (a polling operation), which will check the status of the queue and return a message if available, or a not available indication otherwise; o a notify operation, which will issue an event notification when a message is available in the associated queue. The queuing policy is normally first-in-first-out (FIFO), message queues also support the concept of priority, with higher-priority messages delivered first. A message consists of a destination Id, metadata associated with the message, including fields such as the priority of the message and the delivery mode, and the body of the message.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Characteristics of message passing system
Persistent – stores messages indefinitely. Reliable delivery. Security
Implementation issues Centralized implementation
One or more message queues managed by a centralized queue manager located at a given node. Advantage: simplicity Drawback: manager can become heavy-weight, bottelneck, single-point-of-failure.
Decentralized federated structure with message channel as a unidirectional connection between two queue managers that is used to forward messages asynchronously from one queue to another.
b) Discuss the distributed shared memory approaches.
Shared memory techniques were developed principally for parallel computing
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Distributed shared memory (DSM) is an abstraction used for sharing data between computers that do not share physical memory distributed shared memory operates at the level of reading and writing bytes and is accessed by address.
The main point of DSM is that it spares the programmer the concerns of message passing when writing applications that might otherwise have to use it. DSM is primarily a tool for parallel applications or for any distributed application or group of applications in which individual shared data items can be accessed directly. Message passing cannot be avoided altogether in a distributed system: in the absence of physically shared memory, the DSM runtime support has to send updates in messages between computers. DSM systems manage replicated data: each computer has a local copy of recently accessed data items stored in DSM, for speed of access.
Message passing versus DSM The DSM and message-passing approaches to programming can be contrasted as follows: Service offered: o Under the message-passing model, variables have to be marshalled from one process, transmitted and unmarshalled into other variables at the receiving process. By contrast, with shared memory the processes involved share variables directly, so no marshalling is necessary.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
o Most implementations allow variables stored in DSM to be named and accessed similarly to ordinary unshared variables. In favour of message passing, on the other hand, is that it allows processes to communicate while being protected from one another by having private address spaces. o Synchronization between processes is achieved in the message model through message passing primitives themselves, using techniques such as the lock server implementation. In the case of DSM, synchronization is via normal constructs for shared-memory programming. o Since DSM can be made persistent, processes communicating via DSM may execute with non-overlapping lifetimes. By contrast, processes communicating via message passing must execute at the same time.
c) Write short notes on tuple space communication.
Processes communicate indirectly by placing tuples in a tuple space, from which other processes can read or remove them. Tuples do not have an address but are accessed by pattern matching on content. In the tuple space programming model, processes communicate through a tuple space – a shared collection of tuples. Tuples in turn consist of a sequence of one or more typed data fields such as <"fred", 1958>, <"sid", 1964> and <4, 9.8, "Yes">. Any combination of types of tuples may exist in the same tuple space.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Processes share data by accessing the same tuple space: they place tuples in tuple space using the write operation and read or extract them from tuple space using the read or take operation. The write operation adds a tuple without affecting existing tuples in the space. The read operation returns the value of one tuple without affecting the contents of the tuple space. The take operation also returns a tuple, but in this case it also removes the tuple from the tuple space.
A tuple specification includes the number of fields andthe required values or types of the fields. For example, take(
) could extract either <"fred", 1958> or <"sid", 1964>; take() would extract only <"fred", 1958> of those two. In the tuple space paradigm, no direct access to tuples in tuple space is allowed and processes have to replace tuples in the tuple space instead of modifying them. Thus, tuples are immutable. Implementation issues Centralized vs. Decentralized Replication – different strategies:
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
State-machine approach: Tuple spaces behaves like a state machine, maintaining state and changing this state in response to events received from other replicas or from the environment Partitioning into Views and Tuple Sets: updates are carried out in the context of the current view (the agreed set of replicas) and tuples are also partitioned into distinct tuple sets based on their associated logical names (designated as the first field in the tuple). The system consists of a set of workers carrying out computations on the tuple space, and a set of tuple space replicas.
3. a) What are routing overlays? Discuss the tasks performed by routing overlays.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
In peer-to-peer systems a distributed algorithm known as a routing overlay takes responsibility for locating nodes and objects. The middleware takes the form of a layer that is responsible for routing requests from any client to a host that holds the object to which the request is addressed. The objects of interest may be placed at and subsequently relocated to any node in the network without client involvement. It is termed an overlay since it implements a routing mechanism in the application layer that is quite separate from any other routing mechanisms deployed at the network level such as IP routing. The routing overlay ensures that any node can access any object by routing each request through a sequence of nodes, exploiting knowledge at each of them to locate the destination object. The GUIDs are used to identify nodes and objects.Also known as opaque identifiers, since they reveal nothing about the locations of the objects to which they refer.
The main tasks of routing overlay o Routs the request to a node at which a replica of the object resides. The routing overlay must also perform some other tasks: o Routing of requests to objects: A client wishing to invoke an operation on an object submits a request including the object’s GUID to the routing overlay, which routes the request to a node at which a replica of the object resides. o Insertion of objects: To make a new object available to a peer-to-peer service, it computes a GUID for the object and announces it to the routing overlay. o Deletion of objects: When clients request the removal of objects from the service the routing overlay must make them unavailable. o Node addition and removal : Nodes may join and leave the service. When a node joins the service, the routing overlay arranges for it to assume some of the responsibilities of other nodes. When a node leaves, its responsibilities are distributed amongst the other nodes.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Figure 3.3: Distribution of information in a routing overlay b) State the desirable features of a distributed file system: Transparency a. Structure transparency Clients should not know the number or locations of file servers and the storage devices. Note: multiple file servers provided for performance, scalability, and reliability. b. Access transparency Both local and remote files should be accessible in the same way. The file system should automatically locate an accessed file and transport it to the client’s site. c. Naming transparency The name of the file should give no hint as to the location of the file. The name of the file must not be changed when moving from one node to another. d. Replication transparency If a file is replicated on multiple nodes, both the existence of multiple copies and their locations should be hidden from the clients. User mobility Automatically bring the user’s environment (e.g. user’s home directory) to the node where the user logs in. Performance Performance is measured as the average amount of time needed to satisfy client requests. This time includes CPU time + time for accessing secondary storage + network access time.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
It is desirable that the performance of a distributed file system be comparable to that of a centralized file system. Simplicity and ease of use User interface to the file system be simple and number of commands should be as small as possible. Scalability Growth of nodes and users should not seriously disrupt service. High availability o A distributed file system should continue to function in the face of partial failures such as a link failure, a node failure, or a storage device crash. o A highly reliable and scalable distributed file system should have multiple and independent file servers controlling multiple and independent storage devices. High reliability Probability of loss of stored data should be minimized. System should automatically generate backup copies of critical files. Data integrity o Concurrent access requests from multiple users who are competing to access the file must be properly synchronized by the use of some form of concurrency control mechanism. o Atomic transactions can also be provided. Security Users should be confident of the privacy of their data. Heterogeneity There should be easy access to shared data on diverse platforms (e.g. Unix workstation, Wintel platform etc).
4. a) Write short notes on file accessing models. This depends on the method used for accessing remote files and the unit of data access. 1. Accessing remote files A distributed file system may use one of the following models to service a client’s file access request when the accessed file is remote: a. Remote service model Processing of a client’s request is performed at the server’s node. Thus, the client’s request for file access is delivered across the network as a message to the server, the server machine performs the access request, and the result is sent to the client. Need to minimize the number of messages sent and the overhead per message. b. Data-caching model
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
This model attempts to reduce the network traffic of the previous model by caching the data obtained from the server node. This takes advantage of the locality feature of the found in file accesses. A replacement policy such as LRU is used to keep the cache size bounded. While this model reduces network traffic it has to deal with the cache coherency problem during writes, because the local cached copy of the data needs to be updated, the original file at the server node needs to be updated and copies in any other caches need to be updated. Advantage of Data-caching model over the Remote service model: The data-caching model offers the possibility of increased performance and greater system scalability because it reduces network traffic, contention for the network, and contention for the file servers. Hence almost all distributed file systems implement some form of caching. Example, NFS uses the remote service model but adds caching for better performance. Unit of Data Transfer In file systems that use the data-caching model, an important design issue is to decide the unit of data transfer. This refers to the fraction of a file that is transferred to and form clients as a result of single read or write operation. c. File-level transfer model In this model when file data is to be transferred, the entire file is moved. Advantages: file needs to be transferred only once in response to client request and hence is more efficient than transferring page by page which requires more network protocol overhead. Reduces server load and network traffic since it accesses the server only once. This has better scalability. Once the entire file is cached at the client site, it is immune to server and network failures. Disadvantage: requires sufficient storage space on the client machine. This approach fails for very large files, especially when the client runs on a diskless workstation. If only a small fraction of a file is needed, moving the entire file is wasteful. d. Block-level transfer model File transfer takes place in file blocks. A file block is a contiguous portion of a file and is of fixed length (can also be a equal to a virtual memory page size). Advantages: Does not require client nodes to have large storage space. It eliminates the need to copy an entire file when only a small portion of the data is needed.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Disadvantages: When an entire file is to be accessed, multiple server requests are needed, resulting in more network traffic and more network protocol overhead. NFS uses blocklevel transfer model. e. Byte-level transfer model Unit of transfer is a byte. Model provides maximum flexibility because it allows storage and retrieval of an arbitrary amount of a file, specified by an offset within a file and length. Drawback is that cache management is harder due to the variable-length data for different access requests. f. Record-level transfer model This model is used with structured files and the unit of transfer is the record. b) Define LDAP. Explain its operations. The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. A common usage of LDAP is to provide a single sign on where one password for a user is shared between many services. Protocol overview A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA). The client then sends an operation request to the server, and the server sends responses in return. The client does not wait for a response before sending the next request, and the server may send the responses in any order. All information is transmitted using Basic Encoding Rules (BER). The client may request the following operations: o StartTLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection o Bind — authenticate and specify LDAP protocol version o Search — search for and/or retrieve directory entries o Compare — test if a named entry contains a given attribute value o Add a new entry o Delete an entry
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
o Modify an entry o Modify Distinguished Name (DN) — move or rename an entry o Abandon — abort a previous request o Extended Operation — generic operation used to define other operations o Unbind — close the connection (not the inverse of Bind) In addition the server may send "Unsolicited Notifications" that are not responses to any request, e.g. before the connection is timed out.
Directory structure An entry consists of a set of attributes. An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema. Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the parent entry's DN. A DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. An entry can look like this when represented in LDAP Data Interchange Format (LDIF) (LDAP itself is a binary protocol): dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888 555 1232 mail: [email protected] manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top
"dn" is the distinguished name of the entry; "cn=John Doe" is the entry's RDN (Relative Distinguished Name), and "dc=example,dc=com" is the DN of the parent entry, where "dc" denotes 'Domain Component'. The other lines show the attributes in the entry. Attribute
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, "mail" for e-mail address, and "sn" for surname. A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com" and its children. Servers may also hold references to other servers, so an attempt to access "ou=department,dc=example,dc=com" could return a referral or continuation reference to a server that holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client. Operations 1. Add The ADD operation inserts a new entry into the directory-server database. If the distinguished name in the add request already exists in the directory, then the server will not add a duplicate entry but will set the result code in the add result to decimal 68, "entryAlreadyExists". 2. Bind (authenticate) When an LDAP session is created, that is, when an LDAP client connects to the server, the authentication state of the session is set to anonymous. The BIND operation establishes the authentication state for a session. 3. Delete To delete an entry, an LDAP client transmits a properly formed delete request to the server. A delete request must contain the distinguished name of the entry to be deleted Request controls may also be attached to the delete request Only leaf entries (entries with no subordinates) may be deleted by a delete request. 4. Search and Compare The Search operation is used to both search for and read entries. Its parameters are: baseObject The name of the base object entry (or possibly the root) relative to which the search is to be performed. scope What elements below the baseObject to search. filter Criteria to use in selecting elements within scope. derefAliases Whether and how to follow alias entries (entries that refer to other entries), attributes Which attributes to return in result entries. sizeLimit, timeLimit
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Maximum number of entries to return, and maximum time to allow search to run. These values, however, cannot override any restrictions the server places on size limit and time limit. typesOnly Return attribute types only, not attribute values. 5. Modify The MODIFY operation is used by LDAP clients to request that the LDAP server make changes to existing entries. Attempts to modify entries that do not exist will fail. MODIFY requests are subject to access controls as implemented by the server. Extended operations 6. Abandon The Abandon operation requests that the server to abort an operation named by a message ID. 7. Unbind The Unbind operation abandons any outstanding operations and closes the connection. It has no response. 5. a) Explain the Chandy and Lamport’s snapshot algorithm. The Snapshot Algorithm Chandy and Lamport defined a snapshot algorithm to determine global states of distributed systems . The goal of a snapshot is to record a set of process and channel states (a snapshot) for a set of processes so that, even if the combination of recorded states may not have occurred at the same time, the recorded global state is consistent. o The algorithm records states locally; it does not gather global states at one site. The snapshot algorithm has some assumptions. o Neither channels nor processes fail. o Reliable communications ensure every message sent is received exactly once. o Channels are unidirectional. o Messages are received in FIFO order. o There is a path between any two processes. o Any process may initiate a global snapshot at any time. o Processes may continue to function normally during a snapshot Snapshot Algorithm For each process, incoming channels are those which other processes can use to send it messages.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Outgoing channels are those it uses to send messages. Each process records its state and for each incoming channel a set of messages sent to it. The process records for each channel, any messages sent after it recorded its state and before the sender recorded its own state. This approach can differentiate between states in terms of messages transmitted but not yet received. The algorithm uses special marker messages, separate from other messages, which prompt the receiver to save its own state if it has not done so and which can be used to determine which messages to include in the channel state. The algorithm is determined by two rules.
Figure 4.9 Chandy and Lamport‘s ‗snapshot‘ algorithm
Marker receiving rule for process pi On pi‘s receipt of a marker message over channel c: if (pi has not yet recorded its state) it records its process state now; records the state of c as the empty set; turns on recording of messages arriving over other incoming channels; else pi records the state of c as the set of messages it has received over c since it saved its state. end if Marker sending rule for process pi After pi has recorded its state, for each outgoing channel c: pi sends one marker message over c (before it sends any other message over c). Example Figure 11.11 shows an initial state for two processes.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Figure 11.12 shows four successive states reached and identified after state transitions by the two processes. Termination: it is assumed that all processes will have recorded their states and channel states a finite time after some process initially records its state.
Figure 4.10 Two processes and their initial states
Figure 4.11 The execution of processes in figure 4.10 Characterizing a state A snapshot selects a consistent cut from the history of the execution. Therefore the state recorded is consistent. This can be used in an ordering to include or exclude states that have or have not recorded their state before the cut. This allows us to distinguish events as presnap or post-snap events. The reachability of a state (figure 4.12) can be used to determine stable predicates.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Figure 4.12 Reachability between states in the snapshot algorithm
b) Explain the algorithms for distributed mutual exclusion Problem: an asynchronous system of N processes o Processes don't fail o Message delivery is reliable; not share variables. o only one critical region o application-level protocol: enter(), resourceAccesses(), exit() Requirements for mutual exclusion o Essential [ME1] safety: only one process at a time [ME2] liveness: eventually enter or exit Additional [ME3] happened-before ordering: ordering of enter() is the same as HB ordering Performance evaluation – overhead and bandwidth consumption: # of messages sent o client delay incurred by a process at entry and exit o throughput measured by synchronization delay: delay between one's exit and next's entry A central server algorithm Server keeps track of a token---permission to enter critical region. o A process requests the server for the token. o The server grants the token if it has the token. o A process can enter if it gets the token, otherwise waits. o When done, a process sends release and exits.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Figure 4.13 A ring of processes transferring a mutual exclusion token An algorithm using multicast and logical clocks Multicast a request message for the token (Ricart and Agrawala [1981]). o Enter only if all the other processes reply. o Totally-ordered timestamps: Each process keeps a state: RELEASED, HELD, WANTED. o If all have state = RELEASED, all reply, a process can hold the token and enter. o If a process has state = HELD, doesn't reply until it exits. o If more than one process has state = WANTED, process with the lowest timestamp will get all N-1 replies first.
Figure 4.14 Multicast Synchronization Ricart and Agrawala’s algorithm
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Figure 4.15 Ricart and Agrawala’s algorithm Maekawa‘s voting algorithm Observation: not all peers to grant it access. o Only obtain permission from subsets, overlapped by any two processes Maekawa‘s approach o subsets Vi,Vj for process Pi, Pj Pi ∈Vi, Pj ∈ Vj Vi ∩ Vj ≠ ∅, there is at least one common member subset |Vi|=K, to be fair, each process should have the same size o Pi cannot enter the critical section until it has received all K reply messages. o Choose a subset. Simple way (2√N): place processes in a √N by √N matrix and let Vi be the union of the row and column containing Pi. Optimal (√N): non-trivial to calculate (skim here). o Deadlock-prone • V1={P1, P2}, V2={P2, P3}, V3={P3, P1}. If P1, P2 and P3 concurrently request entry to the critical section, then its possible that each process has received one (itself) out of two replies, and none can proceed.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Adapted and solved by [Saunders 1987].
Figure 4.15 Maekawa’s voting algorithm 6. Define process migration. Explain the process migration mechanism.
Relocation of a process from its current location to another node. Process may be migrated o either before it start executing on its source node Known as non-preemptive process migration.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
o or during the course of its execution Known as preemptive process migration. Preemptive process migration is costlier.
Figure Flow of execution of a migration process Process migration involves the following steps: 1. Selection of a process that should be migrated. 2. Selection of a destination node to which the selected process should be migrated. 3. Actual transfer of the selected process to the destination node. The first two steps are taken care of by the migration policy and the third step by the migration mechanism. Desirable features of a good process migration mechanism A good process migration mechanism must possess Transparency Minimal Interference Minimal Residual Dependencies Efficiency Robustness Communication between coprocesses. 1. Transparency Level of transparency: Object Access level Transparency
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
2.
3. 4.
5.
6.
DEPARTMENT YEAR/SEC
: CSE : III B
Minimum requirement for a system to support non-preemptive process migration facility. Access to objects such as files and devices can be location independent. Allows free initiation of program at arbitrary node. Requires transparent object naming and locating. System Call & IPC level For migrated process, system calls should be location independent. For transparent redirection of messages during the transient state of a process. Transparency must be provided to support preemptive process migration facility Minimal interference Migration of a process should cause minimal interference of progress of the process involved. Achieve by minimizing the freezing time of the process being migrated. o Freezing time is the time period for which the execution of the process is stopped for transferring its information to the destination node. Minimal residual dependencies No residual dependency should be left on previous node. Efficiency Minimum time required for migrating a process. Minimum cost of locating an object. Minimum cost of supporting remote execution once the process is migrated. Robustness The failure of a node other than the one on which a process is currently running should not in any way affect the accessibility or execution of that process. Communication between coprocessors of a job To reduce communication cost, it is necessary that coprocesses are able to directly communicate with each other irrespective of their locations.
Process Migration Mechanism Four major activities Freezing the process on its source node and restarting it on its destination node. Transferring the process’s address space from its source node to its destination node. Forwarding massages meant for the migrant process. Handling communication between cooperating processes that have been separated as a result of process migration. Freezing the process:
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
The execution of the process is suspended and all external interactions with the process are deferred. Issues: o Immediate and delayed blocking of the process o Fast and slow I/O operations o Information about open files o Reinstating the process on its Destination node Immediate and delayed blocking of a process If the process is not executing a system call, it can be immediately blocked from further execution. If the process is executing a system call but is sleeping at an interruptible priority waiting for a kernel event to occur, it can be immediately blocked from further execution. If the process is executing a system call but is sleeping at an non-interruptible priority waiting for a kernel event to occur, it cannot be blocked immediately Fast and slow I/O operations Process is frozen after the completion of all fast I/O operations like disk access. Slow I/O operation (pipe or terminal) is done after process migration and when process is executed on destination node. Information about open files Includes name and identifier of the file, their access modes and the current positions of their file pointers. OS returns a file descriptor to process that is used for all I/O. It is necessary to somehow preserve a pointer to the file so that migrated process could continue to access it. Approaches : o Link is created to the file and the pathname of the link is used as an access point to the file after the process migrates. o An open file’s complete pathname is reconstructed when required by modifying the kernel. o Keeping Track of file replicas. Reinstating the process on its destination node On the destination node, an empty process state is created. Newly allocated process may or may not have the same process identifier as the migrating process.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Once all the state of the migrating process has been transferred from the source to destination node and copied into the empty state, new copy of the process is unfrozen and old copy is deleted. The process is restarted on its destination node in whatever state it was in before being migrated.
Address Space Transfer Mechanisms The migration of a process involves the transfer of o Process’s state o Process’s address space o from the source node to the destination node. Process State consists of o Execution Status – Register Contents o Memory Tables o I/O State : I/O Queue, I/O buffers, Interrupts o Capability list o Process’s Identifier o Process’s user and group identifier o Information about Open Files Process address space o code, o data and o program stack The size of the process’s address space (several megabytes) overshadows the size of the process’s state information (few kilobytes). Mechanisms for address space transfer: o Total freezing o Pretransferring o Transfer on reference 1. Total freezing A process’s execution is stopped while its address space is being transferred. Disadvantage: o Process is suspended for long time during migration, timeouts may occur, and if process is interactive, the delay will be noticed by the user.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
2.
DEPARTMENT YEAR/SEC
: CSE : III B
Pretransferring Also known as precopying. The address space is transferred while the process is still running on the source node. It is done as an initial transfer of the complete address space followed by repeated transfers of the page modified during the previous transfer. The pretransfer operation is executed at a higher priority than all other programs on the source node. Reduces the freezing time of the process but it may increase the total time for migrating due to the possibility of redundant page transfers.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
1. Transfer on reference The process address space is left behind on its source node, and as the relocated process executes on its destination node. Attempts to reference memory page results in the generation of requests to copy in the desired blocks from their remote location. A page is transferred from its source node to its destination node only when referenced. Very short switching time of the process from its source node to its destination node. Imposes a continued load on the process’s source node and results in the process if source node fails or is rebooted.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Advantages of process migration Reducing average response time of processes o To reduce the average response time of the processes, processes of a heavily loaded node are migrated to idle or underutilized nodes. o Speeding up individual jobs o A migration of job to different node is done and execute them concurrently. o Migrate a job to a node having a faster CPU or to a node at which it has minimum turnaround time. o More speed up more migration cost involved. Gaining higher throughput o Process migration facility may also be used properly to mix I/O and CPU-bound processes on a global basis for increasing the throughput of the system. o Utilizing resources effectively o Depending upon the nature of a process, it can be migrated to suitable node to utilize the system resource in the most efficient manner. Reducing network traffic o Migrating a process closer to the resources it is using most heavily. o Improving system reliability o Migrate a copy of a critical process to some other node and to execute both the original and copied processes concurrently on different nodes. o Improving system security o A sensitive process may be migrated and run on a secure node.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
7. a) Discuss the issues in load balancing approach. Issues in distributed load balancing algorithms Load estimation policy o determines how to estimate the workload of a node Process transfer policy o determines whether to execute a process locally or remote State information exchange policy o determines how to exchange load information among nodes Location policy o determines to which node the transferable process should be sent Priority assignment policy o determines the priority of execution of local and remote processes Migration limiting policy o determines the total number of times a process can migrate Load estimation policy To balance the workload on all the nodes of the system, it is necessary to decide how to measure the workload of a particular node Some measurable parameters (with time and node dependent factor) can be the following: o Total number of processes on the node o Resource demands of these processes o Instruction mixes of these processes o Architecture and speed of the node’s processor Several load-balancing algorithms use the total number of processes to achieve big efficiency In some cases the true load could vary widely depending on the remaining service time, which can be measured in several way: o Memoryless method assumes that all processes have the same expected remaining service time, independent of the time used so far o Pastrepeats assumes that the remaining service time is equal to the time used so far o Distribution method states that if the distribution service times is known, the associated process’s remaining service time is the expected remaining time conditioned by the time already used. None of the previous methods can be used in modern systems because of periodically running processes and daemons An acceptable method for use as the load estimation policy in these systems would be to measure the CPU utilization of the nodes
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Central Processing Unit utilization is defined as the number of CPU cycles actually executed per unit of real time It can be measured by setting up a timer to periodically check the CPU state (idle/busy)
Process transfer policy Most of the algorithms use the threshold policy to decide on whether the node is lightlyloaded or heavily-loaded Threshold value is a limiting value of the workload of node which can be determined by o Static policy: predefined threshold value for each node depending on processing capability o Dynamic policy: threshold value is calculated from average workload and a predefined constant Below threshold value node accepts processes to execute, above threshold value node tries to transfer processes to a lightly-loaded node Single-threshold policy may lead to unstable algorithm because underloaded node could turn to be overloaded right after a process migration.
To reduce instability double-threshold policy has been proposed which is also known as high-low policy. Double threshold policy o When node is in overloaded region new local processes are sent to run remotely, requests to accept remote processes are rejected. o When node is in normal region new local processes run locally, requests to accept remote processes are rejected. o When node is in underloaded region new local processes run locally, requests to accept remote processes are accepted.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Location Policy Threshold method o Policy selects a random node, checks whether the node is able to receive the process, then transfers the process. If node rejects, another node is selected randomly. This continues until probe limit is reached. Shortest method o L distinct nodes are chosen at random, each is polled to determine its load. The process is transferred to the node having the minimum value unless its workload value prohibits to accept the process. o Simple improvement is to discontinue probing whenever a node with zero load is encountered. Bidding method o Nodes contain managers (to send processes) and contractors (to receive processes) o Managers broadcast a request for bid, contractors respond with bids (prices based on capacity of the contractor node) and manager selects the best offer o Winning contractor is notified and asked whether it accepts the process for execution or not o Full autonomy for the nodes regarding scheduling o Big communication overhead o Difficult to decide a good pricing policy Pairing o Contrary to the former methods the pairing policy is to reduce the variance of load only between pairs o Each node asks some randomly chosen node to form a pair with it o If it receives a rejection it randomly selects another node and tries to pair again o Two nodes that differ greatly in load are temporarily paired with each other and migration starts o The pair is broken as soon as the migration is over o A node only tries to find a partner if it has at least two processes State Information Exchange Policy Dynamic policies require frequent exchange of state information, but these extra messages arise two opposite impacts: o Increasing the number of messages gives more accurate scheduling decision o Increasing the number of messages raises the queuing time of messages State information policies can be the following: o Periodic broadcast
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Each node broadcasts its state information after the elapse of every T units of time Problem: heavy traffic, fruitless messages, poor scalability since information exchange is too large for networks having many nodes o Broadcast when state changes Avoids fruitless messages by broadcasting the state only when a process arrives or departures Further improvement is to broadcast only when state switches to another region (double-threshold policy) o On-demand exchange In this method a node broadcast a State-Information-Request message when its state switches from normal to either underloaded or overloaded region. On receiving this message other nodes reply with their own state information to the requesting node Further improvement can be that only those nodes reply which are useful to the requesting node o Exchange by polling To avoid poor scalability (coming from broadcast messages) the partner node is searched by polling the other nodes on by one, until poll limit is reached Priority Assignment Policy Selfish o Local processes are given higher priority than remote processes. Worst response time performance of the three policies. Altruistic o Remote processes are given higher priority than local processes. Best response time performance of the three policies. Intermediate o When the number of local processes is greater or equal to the number of remote processes, local processes are given higher priority than remote processes. Otherwise, remote processes are given higher priority than local processes. Migration Limitation Policy This policy determines the total number of times a process can migrate o Uncontrolled A remote process arriving at a node is treated just as a process originating at a node, so a process may be migrated any number of times
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
o Controlled Avoids the instability of the uncontrolled policy Use a migration count parameter to fix a limit on the number of time a process can migrate Irrevocable migration policy: migration count is fixed to 1 For long execution processes migration count must be greater than 1 to adapt for dynamically changing states
Drawbacks of Load-balancing approach o Load balancing technique with attempting equalizing the workload on all the nodes is not an appropriate object since big overhead is generated by gathering exact state information o Load balancing is not achievable since number of processes in a node is always fluctuating and temporal unbalance among the nodes exists every moment
b) Explain the Load sharing approach for process scheduling. Basic ideas for Load-sharing approach o It is necessary and sufficient to prevent nodes from being idle while some other nodes have more than two processes o Load-sharing is much simpler than load-balancing since it only attempts to ensure that no node is idle when heavily node exists o Priority assignment policy and migration limiting policy are the same as that for the load-balancing algorithms Load Estimation policies Since load-sharing algorithms simply attempt to avoid idle nodes, it is sufficient to know whether a node is busy or idle Thus these algorithms normally employ the simplest load estimation policy of counting the total number of processes. In modern systems where permanent existence of several processes on an idle node is possible, algorithms measure CPU utilization to estimate the load of a node Process Transfer policy Algorithms normally use all-or-nothing strategy This strategy uses the threshold value of all the nodes fixed to 1 Nodes become receiver node when it has no process, and become sender node when it has more than 1 process
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
To avoid processing power on nodes having zero process load-sharing algorithms use a threshold value of 2 instead of 1 When CPU utilization is used as the load estimation policy, the double-threshold policy should be used as the process transfer policy
Location Policies Location policy decides whether the sender node or the receiver node of the process takes the initiative to search for suitable node in the system, and this policy can be the following: o Sender-initiated location policy Sender node decides where to send the process Heavily loaded nodes search for lightly loaded nodes o Receiver-initiated location policy Receiver node decides from where to get the process Lightly loaded nodes search for heavily loaded nodes Sender-initiated location policy o Node becomes overloaded, it either broadcasts or randomly probes the other nodes one by one to find a node that is able to receive remote processes o When broadcasting, suitable node is known as soon as reply arrives Receiver-initiated location policy o Nodes becomes underloaded, it either broadcast or randomly probes the other nodes one by one to indicate its willingness to receive remote processes Receiver-initiated policy require preemptive process migration facility since scheduling decisions are usually made at process departure epochs Experiences with location policies o Both policies gives substantial performance advantages over the situation in which no load-sharing is attempted o Sender-initiated policy is preferable at light to moderate system loads o Receiver-initiated policy is preferable at high system loads o Sender-initiated policy provide better performance for the case when process transfer cost significantly more at receiver-initiated than at sender-initiated policy due to the preemptive transfer of processes State information exchange policy In load-sharing algorithms it is not necessary for the nodes to periodically exchange state information, but needs to know the state of other nodes when it is either underloaded or overloaded
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Broadcast when state changes o In sender-initiated/receiver-initiated location policy a node broadcasts State Information Request when it becomes overloaded/underloaded o It is called broadcast-when-idle policy when receiver-initiated policy is used with fixed threshold value value of 1 Poll when state changes o In large networks polling mechanism is used o Polling mechanism randomly asks different nodes for state information until find an appropriate one or probe limit is reached o It is called poll-when-idle policy when receiver-initiated policy is used with fixed threshold value value of 1
8. a) Discuss about election algorithms. A ring-based election algorithm Arrange processes in a logical ring o pi sends messages to p(i+1) mod N. o It could be unrelated to the physical configuration. o Elect the coordinator with the largest id. o Assume no failures . Initially, every process is a non-participant. Any process can call an election. o Marks itself as participant. o Places its id in an election message. o Sends the message to its neighbour. o Receiving an election message . If id > myid, forward the msg, mark participant • If id < myid o Non-participant: replace id with myid: forward the msg, mark participant. o Participant: stop forwarding (why? Later, multiple elections) If id = myid, coordinator found, mark non-participant, electedi := id, send elected message with myid o Receiving an elected message. id != myid, mark non-participant, electedi := id forward the msg. If id = myid, stop forwarding
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Figure 4.16 A ring-based election in progress
Receiving an election message: o If id > myid, forward the msg, mark participant. o If id < myid non-participant: replace id with myid: forward the msg, mark participant participant: stop forwarding (why? Later, multiple elections) o if id = myid, coordinator found, mark non-participant, electedi := id, send elected message with myid. Receiving an elected message: o id != myid, mark non-participant, electedi := id forward the msg. o If id = myid, stop forwarding
The bully election algorithm Assumption o Each process knows which processes have higher identifiers, and that it can communicate with all such processes. Compare with ring-based election. o Processes can crash and be detected by timeout. Synchronous. Timeout T = 2Ttransmitting (max transmission delay) + Tprocessing (max processing delay). Three types of messages. o Election: announce an election. o Answer: in response to Election o Coordinator: announce the identity of the elected process. The bully election algorithm: how to
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Start an election when detect the coordinator has failed or begin to replace the coordinator, which has lower identifier o Send an election message to all processes with higher id's and waits for answers (except the failed coordinator/process). If no answers in time T o Considers it is the coordinator o Sends coordinator message (with its id) to all processes with lower id's Else o waits for a coordinator message and starts an election if T‘ timeout. o To be a coordinator, it has to start an election . A higher id process can replace the current coordinator (hence ―”bully”). The highest one directly sends a coordinator message to all process with lower identifiers Receiving an election message o Sends an answer message back o Starts an election if it hasn't started one o Send election messages to all higher-id processes (including the ―”failed” coordinator—the coordinator might be up by now) Receiving a coordinator message o Set electedi to the new coordinator.
Figure 4.17 The bully algorithm
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
b) Explain about Atomic Commit Protocols The atomicity property requires that either all of the servers involved in the same transaction commit the transaction or all of them abort. Agreement among servers are necessary. Transaction recovery is to ensure that all objects are recoverable. The values of the objects reflect all changes made by committed transactions and none of those made by aborted ones. Servers for a distributed transaction need to coordinate their actions. A client starts a transaction by sending an openTransaction request to a coordinator. The coordinator returns the TID to the client. The TID must be unique (serverIP and number unique to that server) Coordinator is responsible for committing or aborting it. Each other server in a transaction is a participant. Participants are responsible for cooperating with the coordinator in carrying out the commit protocol, and keep track of all recoverable objects managed by it. Each coordinator has a set of references to the participants. Each participant records a reference to the coordinator. One Phase atomic commit protocol A transaction comes to an end when the client requests that a transaction be committed or aborted. Simple way is: coordinator to communicate the commit or abort request to all of the participants in the transaction and to keep on repeating the request until all of them have acknowledged that they had carried it out. Inadequate because when the client requests a commit, it does not allow a server to make a unilateral decision to abort a transaction. E.g. deadlock avoidance may force a transaction to abort at a server when locking is used. So any server may fail or abort and client is not aware. Two phase commit protocol Allow any participant to abort its part of a transaction. Due to atomicity, the whole transaction must also be aborted. In the first phase, each participant votes for the transaction to be committed or aborted. Once voted to commit, not allowed to abort it. So before votes to commit, it must ensure that it will eventually be able to carry out its part, even if it fails and is replaced. A participant is said to be in a prepared state if it will eventually be able to commit it. So each participant needs to save the altered objects in the permanent storage device together with its status-prepared.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
In the second phase, every participant in the transaction carries out the joint decision. If any one participant votes to abort, the decision must be to abort. If all the participants vote to commit, then the decision is to commit the transaction. The problem is to ensure that all of the participants vote and that they all reach the same decision. It is an example of consensus. It is simple if no error occurs. However, it should work when servers fail, message lost or servers are temporarily unable to communicate with one another. If the client requests abort, or if the transaction is aborted by one of the participants, the coordinator informs the participants immediately. It is when the client asks the coordinator to commit the transaction that two-phase commit protocol comes into use. In the first phase, the coordinator asks all the participants if they are prepared to commit; and in the second, it tells them to commit or abort the transaction.
Operations for two-phase commit protocol canCommit?(trans)� Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote. doCommit(trans) Call from coordinator to participant to tell participant to commit its part of a transaction. doAbort(trans) Call from coordinator to participant to tell participant to abort its part of a transaction. haveCommitted(trans, participant) Call from participant to coordinator to confirm that it has committed the transaction. getDecision(trans) � Yes / No Call from participant to coordinator to ask for the decision on a transaction when it has voted Yes but has still had no reply after some delay. Used to recover from server crash or delayed messages. The two phase commit protocol Phase 1 (voting phase): 1. The coordinator sends a canCommit? request to each of the participants in the transaction.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
2. When a participant receives a canCommit? request it replies with its vote (Yes or No) to the coordinator. Before voting Yes, it prepares to commit by saving objects in permanent storage. If the vote is No the participant aborts immediately. Phase 2 (completion according to outcome of vote): 3. The coordinator collects the votes (including its own). a. If there are no failures and all the votes are Yes the coordinator decides to commit the transaction and sends a doCommit request to each of the participants. b. Otherwise the coordinator decides to abort the transaction and sends doAbort requests to all participants that voted Yes. 4. Participants that voted Yes are waiting for a doCommit or doAbort request from the coordinator. When a participant receives one of these messages it acts accordingly and in the case of commit, makes a haveCommitted call as confirmation to the coordinator.
Figure 4.34 Communication in a two phase commit protocol
Consider when a participant has voted Yes and is waiting for the coordinator to report on the outcome of the vote by telling it to commit or abort. Such a participant is uncertain and cannot proceed any further. The objects used by its transaction cannot be released for use by other transactions. Participant makes a getDecision request to the coordinator to determine the outcome. If the coordinator has failed, the participant will not get the decision until the coordinator is replaced resulting in extensive delay for participant in uncertain state. Timeout are used since exchange of information can fail when one of the servers crashes, or when messages are lost So process will not block forever Performance of a two phase commit protocol Provided that all servers and communication channels do not fail, with N participants N number of canCommit? Messages and replies Followed by N doCommit messages
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
The cost in messages is proportional to 3N The cost in time is three rounds of message. The cost of haveCommitted messages are not counted, which can function correctly without them- their role is to enable server to delete stale coordinator information. Failure of coordinator When a participant has voted Yes and is waiting for the coordinator to report on the outcome of the vote, such participant is in uncertain stage. If the coordinator has failed, the participant will not be able to get the decision until the coordinator is replaced, which can result in extensive delays for participants in the uncertain state. One alternative strategy is allow the participants to obtain a decision from other participants instead of contacting coordinator. However, if all participants are in the uncertain state, they will not get a decision. 9. Discuss the Edge chasing or path pushing algorithm for deadlock detection. Distributed approach for deadlock detection. No global wait-for graph is constructed, but each of the servers has knowledge about some of its edges. The servers attempt to find cycles by forwarding messages called probes, which follow the edges of the graph throughout the distributed system. A probe message consists of transaction wait-for relationships representing a path in the global wait-for graph.
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Figure 4.38 Probes transmitted to detect deadlock Edge chasing algorithms have three steps: o Initiation: when a server notes that a transaction T starts waiting for another U, where U is waiting to access object at another server. It initiates detection by sending a probe containing the edgeU> to the server of the object at which U is blocked. o Detection: consists of receiving probes and deciding whether deadlock has occurred and whether to forward the probes. The server receives the probe and check to see whether U is also waiting. If it is, the transaction it wais for (e.g. V) is added to the probe making it U->V>, and if the new transaction V is waiting for another object elsewhere, the probe is forwarded. o In this way, paths through the global wait-for graph are built one edge at a time. After a new transaction is added to the probe, it will see if the just added transaction has caused a cycle. o Resolution: when a cycle is detected, a transaction in the cycle is aborted to break the deadlock. Server X initiates detection by sending probe U> to the server of B ( server Y) Server Y receives probe U>, note that B is held by V and appends V to the probe to produce U->V>. It notes that V is waiting for C at server Z. This probe is forwarded to server Z. Server Z receives probe U->V> and notes C is held by W and appends W to the probe to produce U->V->W>. One of the transactions in the cycle must abort and the choice can be made based on priorities. Probe forwarding between servers is through coordinator Lock manager at participants inform coordinator when transaction starts waiting for objects and when transaction acquires objects and become active again. The coordinator is responsible for recording whether the transaction is active or waiting for a object, and participants can get this information from the coordinator. A server usually sends its probe to the coordinator of the last transaction in the path to find out whether the transaction is waiting for another object elsewhere. E.g. W->U->V, see V if waiting or not, if V is waiting for another object, V’s coordinator will forward the probe to the server of the object on which V is waiting on. This shows that when a probe is forwarded, two messages are required. Performance Analysis
AGNI COLLEGE OF TECHNOLOGY SUB NAME : Distributed Systems SUB CODE : CS6601
DEPARTMENT YEAR/SEC
: CSE : III B
Figure 4.39 Two probes initiated
In above example, two probe messages to detect a cycle involving three transactions. when one probe is forwarded, two messages are required. In general, a probe that detects a cycle involving N transactions will be forwarded by (N1) transaction coordinators via (N-1) servers of objects, requiring a total of 2(N-1) messages. Deadlock detection can be initiated by several transactions in a cycle at the same time. Multiple probe problem At about the same time, T waits for U ( T->U) and W waits for V (W->V). Two probes occur, two deadlocks detected by different servers. We want to ensure that only one transaction is aborted in the same deadlock since different servers may choose different transaction to abort leading to unnecessary abort of transactions. So using priorities to determine which transaction to abort will result in the same transaction to abort even if the cycles are detected by different servers. Using priority can also reduce the number of probes. For example, we only initiate probe when higher priority transaction starts to wait for lower priority transaction. If we say the priority order from high to low is: T, U, V and W. Then only the probe of T>U will be sent and not the probe of W->V.
