MC0085 set 2 solved assingment 2012

1. In what aspects is the design of a distributed file system different from that of a centralized file system?

Answer:

A good distributed file system has the features described below that a centralized file system lacks of:

i) Transparency Location: a client cannot tell where a file is located Migration: a file can transparently move to another server Replication: multiple copies of a file may exist Concurrency: multiple clients access the same file

ii) Flexibility In a flexible DFS it must be possible to add or replace file servers. Also, a DFS should support multiple underlying file system types (e.g., various Unix file systems, various Windows file systems, etc.)

iii) Reliability In a good distributed file system, the probability of loss of stored data should be minimized as far as possible. i.e. users should not feel compelled to make backup copies of their files because of the unreliability of the system. Rather, the file system should automatically generate backup copies of critical files that can be used in the event of loss of the original ones. Stable storage is a popular technique used by several file systems for higher reliability.

iv) Consistency: Employing replication and allowing concurrent access to files may introduce consistency problems.

v) Security: Clients must authenticate themselves and servers must determine whether clients are authorised to perform requested operation. Furthermore communication between clients and the file server must be secured.

vi) Fault tolerance: Clients should be able to continue working if a file server crashes. Likewise, data must not be lost and a restarted file server must be able to recover to a valid state.

vii) Performance: In order for a DFS to offer good performance it may be necessary to distribute requests across multiple servers. Multiple servers may also be required if the amount of data stored by a file system is very large.

viii) Scalability: A scalable DFS will avoid centralised components such as a centralised naming service, a centralised locking facility, and a centralised file store. A scalable DFS must be able to handle an increasing number of files and users. It must also be able

to handle growth over a geographic area (e.g., clients that are widely spread over the world), as well as clients from different administrative domains.

2. What are the Issues in Load-Sharing Algorithms? Discuss in detail .

Answer:

Issues in Load-Sharing Algorithms: The design of a load sharing algorithm requires that proper decisions be made regarding load estimation policy, process transfer policy, state information exchange policy, priority assignment policy, and migration limiting policy. It is simpler to decide about most of these policies in case of load sharing, because load sharing algorithms do not attempt to balance the average workload of all the nodes of the system. Rather, they only attempt to ensure that no node is idle when a node is heavily loaded. The priority assignment policies and the migration limiting policies for load-sharing algorithms are the same as that of load-balancing algorithms.

Load Estimation Policies: In this an attempt is made to ensure that no node is idle while processes wait for service at some other node. In general, the following two approaches are used for estimation:

Use number of processes at a node as a measure of load Use the CPU utilization as a measure of load

Process Transfer Policies: Load sharing algorithms are interested in busy or idle states only and most of them employ the all-or-nothing strategy given below:

All or Nothing Strategy: It uses a single threshold policy. A node becomes a candidate to accept tasks from remote nodes only when it becomes idle. A node becomes a candidate for transferring a task as soon as it has more than one task. Under this approach, an idle process is not able to immediately acquire a task, thus wasting processing power. To avoid this, the threshold value can be set to 2 instead of 1.

Location Policies: Location Policy decides the sender node or the receiver node of a process that is to be moved within the system for load sharing. Depending on the type of node that takes the initiative to globally search for a suitable node for the process, the location policies are of the following types:

1. Sender-Initiated Policy: Under this policy, heavily loaded nodes search for lightly loaded nodes to which task may be transferred. The search can be done by sending a broadcast message or probing randomly picked nodes

An advantage of this approach is that sender can transfer the freshly arrived tasks, so no preemptive task transfers occur.

A disadvantage of this approach is it can cause system instability under high system load.

2. Receiver-Initiated Location Policy: Under this policy, lightly loaded nodes search for heavily loaded nodes from which tasks may be transferred

The search for a sender can be done by sending a broadcast message or by probing randomly picked nodes.

An disadvantage of this approach is it may result in preemptive task transfers because sender may not have any freshly arrived tasks.

Advantage is, this does not cause system instability, because under high system loads a receiver will quickly find a sender; and under low system loads, it is OK for processes to process some additional control messages.

3. Symmetrically Initiated Location Policy: Under this approach, both senders and receivers search for receivers and senders respectively.

4. State Information Exchange Policies: Since it is not necessary to equalize load at all nodes under load sharing, state information is exchanged only when the state changes.

5. Broadcast When State Changes: A node broadcasts a state information request message when it becomes under-loaded or overloaded.

In the sender-initiated approach a node broadcasts this message only when it is overloaded.

In the receiver-initiated approach, a node broadcasts this message only when it is under-loaded.

6. Poll When State Changes: When a node’s state changes, It randomly polls other nodes one by one and exchanges state information

with the polled nodes. Polling stops when a suitable node is found or a threshold number of nodes

have been polled. Under sender initiated policy, sender polls to find suitable receiver. Under receiver initiated policy, receiver polls to find suitable sender. The

above Average Algorithm by Krueger and Finkel (A dynamic load balancing algorithm) tries to maintain load at each node within an acceptable range of the system average.

7. Transfer Policy: A threshold policy that uses two adaptive thresholds, the upper threshold, and the lower threshold

A node with load lower than lower threshold is considered a receiver A node with load higher than the higher threshold is considered a sender.

A node’s estimated average load is supposed to lie in the middle of the lower and upper thresholds.

3. Explain the following with respect to Synchronization in Distributed Systems: a. Clock Synchronization b. Clock Synchronization Algorithms c. Distributed Algorithms d. Event Ordering

Answer:

(a)Clock Synchronization Time is an important concept when dealing with synchronisation and

coordination. In particular it is often important to know when events occurred and in what order they occurred. In a non-distributed system dealing with time is trivial as there is a single shared clock. All processes see the same time. In a distributed system, on the other hand, each computer has its own clock. Because no clock is perfect each of these clocks has its own skew which causes clocks on different computers to drift and eventually become out of sync.

There are several notions of time that are relevant in a distributed system. First of all, internally a computer clock simply keeps track of ticks that can be translated into physical time (hours, minutes, seconds, etc.). This physical time can be global or local. Global time is a universal time that is the same for everyone and is generally based on some form of absolute time.1 Currently Coordinated Universal Time (UTC), which is based on oscillations of the Cesium-133 atom, is the most accurate global time. Besides global time, processes can also consider local time. In this case the time is only relevant to the processes taking part in the distributed system (or algorithm). This time may be based on physical or logical clocks.

Physical Clocks Physical clocks keep track of physical time. In distributed systems that rely

on actual time it is necessary to keep individual computer clocks synchronized. The clocks can be synchronized to global time (external synchronization), or to each

other (internal synchronization). Cristian’s algorithm and the Network Time Protocol (NTP) are examples of algorithms developed to synchronize clocks to an external global time source (usually UTC). The Berkeley Algorithm is an example of an algorithm that allows clocks to be synchronized internally.

Cristian’s algorithm requires clients to periodically synchronize with a central time server (typically a server with a UTC receiver). One of the problems encountered when synchronizing clocks in a distributed system is that unpredictable communication latencies can affect the synchronization. For example, when a client requests the current time from the time server, by the time the server’s reply reaches the client the time will have changed. The client must, therefore, determine what the communication latency was and adjust the server’s response accordingly. Cristian’s algorithm deals with this problem by attempting to calculate the communication delay based on the time elapsed between sending a request and receiving a reply.

The Network Time Protocol is similar to Cristian’s algorithm in that synchronization is also performed using time servers and an attempt is made to correct for communication latencies. Unlike Cristian’s algorithm, however, NTP is not centralised and is designed to work on a wide area scale. As such, the calculation of delay is somewhat more complicated. Furthermore, NTP provides a hierarchy of time servers, with only the top layer containing UTC clocks. The NTP algorithm allows client-server and peer-to-peer (mostly between time servers) synchronization. It also allows clients and servers to determine the most reliable servers to synchronize with. NTP typically provides accuracies between 1 and 50 msec depending on whether communication is over a LAN or WAN.

Unlike the previous two algorithms, the Berkeley algorithm does not synchronize to a global time. Instead, in this algorithm, a time server polls the clients to determine the average of everyone’s time. The server then instructs all clients to set their clocks to this new average time. Note that in all the above algorithms a clock should never be set backward. If time needs to be adjusted backward, clocks are simply slowed down until time ’catches up’.

Logical Clocks For many applications, the relative ordering of events is more important than

actual physical time. In a single process the ordering of events (e.g., state changes) is trivial. In a distributed system, however, besides local ordering of events, all processes must also agree on ordering of causally related events (e.g., sending and receiving of a single message). Given a system consisting of N processes pi, i {1, . . . ,N}, we define the local event ordering → i as a binary relation, such that, if pi observes e before e′, we have e → i e′. Based on this local ordering, we define a global ordering as a happened before relation →, as proposed by Lamport [Lam78]: The relation → is the smallest relation, such that

1. e →i e′ implies e → e′, 2. for every message m, send(m) → receive(m), and

3. e → e′ and e′ → e′′ implies e → e′′ (transitivity).The relation → is almost a partial order (it lacks reflexivity). If a → b, then we say a causally affects b. We consider unordered events to be concurrent if they are unordered; i.e., a 6 → b and b 6 → a implies a k b.

(b)Clock Synchronization Algorithms Clock synchronization algorithms may be broadly classified as Centralized and

Distributed: Centralized Algorithms

In centralized clock synchronization algorithms one node has a real-time receiver. This node, called the time server node whose clock time is regarded as correct and used as the reference time. The goal of these algorithms is to keep the clocks of all other nodes synchronized with the clock time of the time server node. Depending on the role of the time server node, centralized clock synchronization algorithms are again of two types – Passive Time Sever and Active Time Server.

1. Passive Time Server Centralized Algorithm: In this method each node periodically sends a message to the time server. When the time server receives the message, it quickly responds with a message (“time = T”), where T is the current time in the clock of the time server node. Assume that when the client node sends the “time = ?” message, its clock time is T0, and when it receives the “time = T” message, its clock time is T1. Since T0 and T1 are measured using the same clock, in the absence of any other information, the best estimate of the time required for the propagation of the message “time = T” from the time server node to the client’s node is (T1-T0)/2. Therefore, when the reply is received at the client’s node, its clock is readjusted to T + (T1-T0)/2.

2. Active Time Server Centralized Algorithm: In this approach, the time server periodically broadcasts its clock time (“time = T”). The other nodes receive the broadcast message and use the clock time in the message for correcting their own clocks. Each node has a priori knowledge of the approximate time (Ta) required for the propagation of the message “time = T” from the time server node to its own node, Therefore, when a broadcast message is received at a node, the node’s clock is readjusted to the time T+Ta. A major drawback of this method is that it is not fault tolerant. If the broadcast message reaches too late at a node due to some communication fault, the clock of that node will be readjusted to an incorrect value. Another disadvantage of this approach is that it requires broadcast facility to be supported by the network. Another active time server algorithm that overcomes the drawbacks of the above algorithm is the Berkeley algorithm proposed by Gusella and Zatti for internal synchronization of clocks of a group of computers running the Berkeley UNIX. In this algorithm, the time server periodically sends a message (“time = ?”) to all the computers in the group. On receiving this message, each computer sends back its clock value to the time server. The time server has a priori knowledge of the approximate time required for the propagation of a message from each node to its own node. Based on this knowledge, it first readjusts the clock values of the reply messages, It then takes a fault-tolerant average of the clock

values of all the computers (including its own). To take the fault tolerant average, the time server chooses a subset of all clock values that do not differ from one another by more than a specified amount, and the average is taken only for the clock values in this subset. This approach eliminates readings from unreliable clocks whose clock values could have a significant adverse effect if an ordinary average was taken.

The calculated average is the current time to which all the clocks should be readjusted, The time server readjusts its own clock to this value, Instead of sending the calculated current time back to other computers, the time server sends the amount by which each individual computer’s clock requires adjustment, This can be a positive or negative value and is calculated based on the knowledge the time server has about the approximate time required for the propagation of a message from each node to its own node.

Centralized clock synchronization algorithms suffer from two major drawbacks:

1. They are subject to single – point failure. If the time server node fails, the clock synchronization operation cannot be performed. This makes the system unreliable. Ideally, a distributed system, should be more reliable than its individual nodes. If one goes down, the rest should continue to function correctly.

2. From a scalability point of view it is generally not acceptable to get all the time requests serviced by a single time server. In a large system, such a solution puts a heavy burden on that one process.

(c)Distributed Algorithms We know that externally synchronized clocks are also internally synchronized.

That is, if each node’s clock is independently synchronized with real time, all the clocks of the system remain mutually synchronized. Therefore, a simple method for clock synchronization may be to equip each node of the system with a real time receiver so that each node’s clock can be independently synchronized with real time. Multiple real time clocks (one for each node) are normally used for this purpose.

Theoretically, internal synchronization of clocks is not required in this approach. However, in practice, due to inherent inaccuracy of real-time clocks, different real time clocks produce different time. Therefore, internal synchronization is normally performed for better accuracy. One of the following two approaches is used for internal synchronization in this case.

1. Global Averaging Distributed Algorithms: In this approach, the clock process at each node broadcasts its local clock time in the form of a special “resync” message when its local time equals T0+iR for some integer I, where T0 is a fixed time in the past agreed upon by all nodes and R is a system parameter that depends on such factors as the total number of nodes in the system, the maximum allowable drift rate, and so on. i.e. a resync message is broadcast from each node at the beginning of every fixed length resynchronization interval. However, since the

clocks of different nodes run slightly different rates, these broadcasts will not happen simultaneously from all nodes.

After broadcasting the clock value, the clock process of a node waits for time T, where T is a parameter to be determined by the algorithm. During this waiting period, the clock process records the time, according to its own clock, when the message was received. At the end of the waiting period, the clock process estimates the skew of its clock with respect to each of the other nodes on the basis of the times at which it received resync messages. It then computes a fault-tolerant average of the next resynchronization interval.

The global averaging algorithms differ mainly in the manner in which the fault-tolerant average of the estimated skews is calculated. Two commonly used algorithms are:

1. The simplest algorithm is to take the average of the estimated skews and use it as the correction for the local clock. However, to limit the impact of faulty clocks on the average value, the estimated skew with respect to each node is compared against a threshold, and skews greater than the threshold are set to zero before computing the average of the estimated skews.

2. In another algorithm, each node limits the impact of faulty clocks by first discarding the m highest and m lowest estimated skews and then calculating the average of the remaining skews, which is then used as the correction for the local clock. The value of m is usually decided based on the total number of clocks (nodes).

2.Localized Averaging Distributed Algorithms: In this approach, the nodes of a distributed system are logically arranged in some kind of pattern, such as a ring or a grid. Periodically, each node exchanges its clock time with its neighbors in the ring, grid, or other structure and then sets its clock time to the average of its own clock time to the average of its own clock time and the clock times of its neighbors.

(d)Event Ordering Lamport observed that for most applications it is not necessary to keep the

clocks in a distributed system synchronized. Rather, it is sufficient to ensure that all events that occur in a distributed system be totally ordered in a manner that is consistent with an observed behavior. For partial ordering of event, Lamport defined a new relation called happened-before and introduced the concept of logical clocks for ordering of events based on the happened-before relation. He then gave a distributed algorithm extending his idea of partial ordering to a consistent total ordering of all the events in a distributed system. His idea is given below:

Happened – Before Relation The happened before relation (denoted by →) on a set of events satisfies the

following conditions:

1. If a and b are the events in the same process and a occurs before b, then a → b.

2. If a is the event of sending a message by one process and b is the event of the receipt of the same message by another process, then a → b. This condition holds by the law of causality because a receiver cannot receive a message until the sender sends it, and the time taken to propagate a message from its sender to its receiver is always positive.

3. If a → b and b → c, then a → c. i.e. happened – before is a transitive relation. In a happened – before relation, two events a and b are said to be concurrent if they are not related by the happened – before relation. i.e. neither a → b nor b → a is true. This is possible if the two events occur in different processes that do not exchange messages either directly or indirectly via other processes. i.e. two events are concurrent if neither can causally affect the other.

Given a system consisting of N processes pi, i E {1, . . . ,N}, we define the local event ordering → i as a binary relation, such that, if pi observes e before e′, we have e → i e′. Based on this local ordering, we define a global ordering as a happened before relation →, as proposed by Lamport [Lam78]: The relation → is the smallest relation, such that

1. e →i e′ implies e → e′, 2. for every message m, send(m) → receive(m), and 3. e → e′ and e′ → e′′ implies e → e′′ (transitivity).

The relation → is almost a partial order (it lacks reflexivity). If a → b, then we say a causally affects b. We consider unordered events to be concurrent if they are unordered; i.e., a 6 → b and b 6 → a implies a E b.

4. Explain the following with respect to Naming in Distributed Systems: a. Desirable Features of a Good Naming system b. Fundamental Terminologies and Concepts c. System Oriented Names

Answer:

(a)Desirable Features of a Good Naming System A good naming system for a distributed system should have the following features:

i) Location transparency The name of an object should not reveal any hint about the physical location of the object

ii) Location independency Name of an object should not be required to be changed when the object’s location changes. Thus

A location independent naming system must support a dynamic mapping scheme

An object at any node can be accessed without the knowledge of its physical location

An object at any node can issue an access request without the knowledge of its own physical location

iii) Scalability Naming system should be able to handle the dynamically changing scale of a distributed system iv) Uniform naming convention Should use the same naming conventions for all types of objects in the system

v) Multiple user-defined names for the same object Naming system should provide the flexibility to assign multiple user-defined names for the same object. vi) Grouping name Naming system should allow many different objects to be identified by the same name. vii) Meaningful names A naming system should support at least two levels of subject identifiers, one convenient for human users and the other convenient for machines.

(b) Fundamental Terminologies and Concepts i) Name Server Name servers manage the name spaces. A name server binds an object to its location. Partitioned name spaces are easier to manage when compared to flat name space, because each server needs to maintain information for only one domain. ii) Name agent Name agents are known by various names. e.g. In Internet domain name service (DNS) they are called “resolvers”, in DCE directory service they are called “clerks”, A Name agent.

Acts between name servers and their clients Maintains knowledge of existing name servers Transfers user requests to proper name servers

iii) Context A context is the environment in which a name is valid. Often contexts represent a division of name space along regional, organizational or functional boundaries. Contexts can be nested in an hierarchical name space. iv) Name resolution Process of mapping an object’s name to its properties such as location. It is basically the process of mapping an object’s name to the authoritative name servers of that object. In partitioned name space, the name resolution mechanism traverses a resolution chain from one context to another until the authoritative name servers of the named object are encountered.

v) Abbreviation/Alias Users can define their own abbreviation for qualified names. Abbreviations defined by a user form a private context for that user. vi) Absolute and relative names In a tree structured name space, the full qualified name of an object need not be specified within current working context. e.g., Unix directory structure, Internet domain names, etc. vii) Generic and Multicast names In generic naming facility, a name is mapped to any one of the set of objects to which it is bound. In group or multicast naming facility, a name is mapped to all members of the set of objects to which it is bound.

(c) System Oriented Names System oriented names normally have the following characteristic features: i) Characteristics of System-oriented names

They are large integers or bit strings. These are also called unique identifiers because they are unique in time and

space. System oriented names are of the same size Generally shorter than human-oriented names and are easy for

manipulations like hashing, sorting and so on.

ii) Approaches for Generating System-Oriented names 1. Centralized approach: In this approach, a global identifier is generated for each object by a centralized generator. The central node is the bottleneck. 2. Distributed approach: In this approach, hierarchical concatenation is used for creating global unique identifiers. Each identification domain is identified by a unique identifier. Global identifier is obtained by concatenating the identifier of domain with an identifier used within the domain. 3. Generating Unique Identifiers in the event of crashes: A crash may lead to loss of state information and hence may result in the generation of non-unique identifiers. Two basic approaches to handle this problem:

Using a clock that operates across failures: A clock is used at the location of the unique identifier generator. The clock is guaranteed to operate across failures.

Using two or more levels of storage: In this approach, two or more levels of storage are used and the unique identifiers are structured in a hierarchical fashion with one field for each level.

5. Explain the following with respect Security in Distributed Systems: a. Cryptography b. Authentication

c. Access Control d. Digital Signatures

Answer:

(a)Cryptography Network security is mostly achieved through the use of Cryptography, a science based on abstract algebra. Definition: Cryptography, a word with Greek origins, means “Secret Writing”. However, we use the term to refer to the science and art of transforming messages to make them secure and immune to attacks. Figure below shows the components involved in the cryptography:

Components of Cryptography

The original message before being transformed is called Plaintext. After the message is transformed, it is called Ciphertext. An Encryption algorithm transforms the plain text into cipher text; A Decryption algorithm transforms the cipher text back into plain text. The sender uses an encryption algorithm and the receiver uses a decryption algorithm.

Cipher: The Encryption and Decryption algorithms are referred to as Ciphers. It is also used to refer to different categories of algorithms in cryptography. One cipher can serve millions of communicating pairs.

Key: It is a number (or a set of numbers) that the cipher, as an algorithm, operates on. To encrypt a message, we need an encryption algorithm, an encryption key, and the plaintext. These create the ciphertext. To decrypt a message, we need a decryption algorithm, a decryption key, and the ciphertext. These reveal the original plaintext.

Alice, Bob, and Eve In cryptography, it is customary to use three characters in an information exchange scenario: we use Alice, Bob, and Eve. Alice is the person who needs to send secure data. Bob is the recipient of data. Eve is the person who somehow disturbs the communication between Alice and Bob by intercepting messages to uncover the

data or by sending her own disguised messages. These three names represent computers or processes that actually send or receive data, or intercept or change data. Cryptographic algorithms can be divided into two groups:

Symmetric (Also called Secret – Key) Asymmetric (Also called Public – Key)

Symmetric Key Cryptography: In this both the parties use the same key. The sender uses this key and an encryption algorithm to encrypt data; the receiver uses the same key and the corresponding decryption algorithm to decrypt the data.

Symmetric – Key Cryptography

Asymmetric Key Cryptography: (or Public Key Cryptography) In this, there are two keys: a private key and a public key. The private key is kept by the receiver. The public key is announced to the public. In the figure shown below, assume that Alice wants to send a message to Bob. Alice uses the public key to encrypt the message. When the message is received by Bob, the private key is used to decrypt the message. In this method the public key used for encryption is different from the private key used for decryption. The public key is available to the public; the private key is available only to an individual.

(b)Authentication In most computer security contexts, user authentication is the fundamental building block and the primary line of defense. User authentication is the basis for most types of access control and for user accountability. The process of verifying an identity claimed by or for a system entity. An authentication process consists of two steps:

Identification step: Presenting an identifier to the security system. (Identifiers should be assigned carefully, because authenticated identities are the basis for other security services, such as access control service.)

Verification step: Presenting or generating authentication information that corroborates the binding between the entity and the identifier.

For example, user Alice Toklas could have the user identifier ABTOKLAS. This information needs to be stored on any server or computer system that Alice wishes to use and could be known to system administrators and other users. A typical item of authentication information associated with this user ID is a password, which is kept secret (known only to Alice and to the system). If no one is able to obtain or guess Alice‟s password, then the combination of Alice‟s user ID and password enables administrators to set up Alice‟s access permissions and audit her activity. Because Alice‟s ID is not secret, system users can send her e-mail, but because her password is secret, no one can pretend to be Alice.

In essence, identification is the means by which a user provides a claimed identity to the system; user authentication is the means of establishing the validity of the claim. Note that user authentication is distinct from message authentication.

Message authentication is a procedure that allows communicating parties to verify that the contents of a received message have not been altered and that the source is authentic. This unit is concerned solely with user authentication.

Means of Authentication There are four general means of authenticating a user‟s identity, which can be used alone or in combination:

Something the individual knows: Examples includes a password, a personal identification number (PIN), or answers to a prearranged set of questions.

Something the individual possesses: Examples include electronic keycards, smart cards, and physical keys. This type of authenticator is referred to as a token.

Something the individual is (static biometrics): Examples include recognition by fingerprint, retina, and face.

Something the individual does (dynamic biometrics): Examples include recognition by voice pattern, handwriting characteristics, and typing rhythm.

All of these methods, properly implemented and used, can provide secure user authentication. However, each method has problems. An adversary may be able to guess or steal a password. Similarly, an adversary may be able to forge or steal a token. A user may forget a password or lose a token. Further, there is a significant administrative overhead for managing password and token information on systems and securing such information on systems. With respect to biometric authenticators, there are a variety of problems, including dealing with false positives and false negatives, user acceptance, cost, and convenience.

(c)Access Control

An access control policy dictates what types of access are permitted, under what circumstances, and by whom. Access control policies are generally grouped into the following categories:

Discretionary access control (DAC): Controls access based on the identity of the requestor and on access rules (authorizations) stating what requestors are (or are not) allowed to do.This policy is termed discretionary because an entity might have access rights that permit the entity, by its own volition, to enable another entity to access some resource.

Mandatory access control (MAC): Controls access based on comparing security labels (which indicate how sensitive or critical system resources are) with security clearances (which indicate system entities are eligible to access certain resources). This policy is termed mandatory because an entity that has clearance to access a resource may not, just by its own volition, enable another entity to access that resource.

Role-based access control (RBAC): Controls access based on the roles that users have within the system and on rules stating what accesses are allowed to users in given roles.

DAC is the traditional method of implementing access control. MAC is a concept that evolved out of requirements for military information security and is beyond the scope of this book. RBAC has become increasingly popular and is introduced later in this section.

These three policies are not mutually exclusive Figure 10.12. An access control mechanism can employ two or even all three of these policies to cover different classes of system resources.

(d)Digital Signatures A digital signature of a message is a number dependent on some secret known only to the signer, and, additionally, on the content of the message being signed. Signatures must be verifiable; if a dispute arises as to whether a party signed a document (caused by either a lying signer trying to repudiate a signature it did create, or a fraudulent claimant), an unbiased third party should be able to resolve the matter equitably, without requiring access to the signer‟s secret information (private key). Digital signatures have many applications in information security, including authentication, data integrity, and non-repudiation. One of the most significant applications of digital signatures is the certification of public keys in large networks. Certification is a means for a trusted third party (TTP) to bind the identity of a user to a public key, so that at some later time, other entities can authenticate a public key without assistance from a trusted third party.

The concept and utility of a digital signature was recognized several years before any practical realization was available. The first method discovered was the RSA signature scheme, which remains today one of the most practical and versatile techniques available. Subsequent research has resulted in many alternative digital signature techniques. Some offer significant advantages in terms of functionality and implementation. Basic definitions 1. A digital signature is a data string which associates a message (in digital form) with some originating entity. 2. A digital signature generation algorithm (or signature generation algorithm) is a method for producing a digital signature. 3. A digital signature verification algorithm (or verification algorithm) is a method for verifying that a digital signature is authentic (i.e., was indeed created by the specified entity). 4. A digital signature scheme (or mechanism) consists of a signature generation algorithm and an associated verification algorithm.5. A digital signature signing process (or procedure) consists of a (mathematical) digital signature generation algorithm, along with a method for formatting data into messages which can be signed. 6. A digital signature verification process (or procedure) consists of a verification algorithm, along with a method for recovering data from the message.

Notation for Digital Signature Mechanisms

(messages) M is the set of elements to which a signer can affix a digital signature.

(signing space) MS is the set of elements to which the signature transformations are applied. The signature transformations are not applied directly to the set M.

(signature space) S is the set of elements associated to messages in M. These elements are used to bind the signer to the message.

(indexing set) R is used to identify specific signing transformations.

6. Describe the following: A) Process Migration ; B) Threads

Answer:

(a)Process Migration Definition: The relocation of a process from its current location (the source system) to some other location (Destination). A process may be migrated either before it starts executing on its source node or during the course of its execution. The former is known as pre-emptive process migration. Process migration involves the following steps:

1. Selection of a process to be migrated 2. Selection of destination system or node 3. Actual transfer of the selected process to the destination system or node

The following are the desirable features of a good process migration mechanism:

A good process migration mechanism must possess transparency, minimal interferences, minimal residual dependencies, efficiency, and robustness.

i) Transparency: Levels of transparency: Access to objects such as files and devices should be done in a location-

independent manner. To accomplish this, system should provide a mechanism for transparent object naming.

System calls should be location-independent. However, system calls related to physical properties of node need not be location-independent.

Interprocess communication should be transparent. Messages sent to a migrated process should be delivered to the process transparently; i.e. the sender doesn’t have to resend it.

ii) Minimal Interference: Migration of a process should involve minimal interference to the progress of the process and to the system as a whole. For example, minimize freezing time; can be done by partial transfer.

iii) Minimal residual dependencies: Migrated process should not continue to depend in any way on its previous node, because such dependency can diminish the benefits of migrating and also the failure of the previous node will cause the process to fail.

iv) Efficiency: Time required for migrating a process and cost of supporting remote execution should be minimized.

v) Robustness: Failure of any node other than the one on which the process is running should not affect the execution of the process.

Process Migration Mechanism Migration of a process is a complex activity that involves proper handling of several sub-activities in order to meet the requirements of a good process migration mechanism. The four major subactivities involved in process migration are as follows:

1. Freezing the process and restarting on another node. 2. Transferring the process’ address space from its source node to its

destination node 3. Forwarding messages meant for the migrant process4. Handling communication between cooperating processes that have been separated as a result of process migration.

The commonly used mechanisms for handling each of these subactivities are described below:

Mechanisms for freezing the process: In pre-emptive process migration, the usual process is to take a “snapshot” of

the process’ on its source node and reinstate the snapshot on the destination node. For this, at some point during migration, the process is frozen on its source node, its state information is transferred to its destination node, and the process is restarted on its destination node using this state information. By freezing this process, we mean that the execution of the process is suspended and all external interactions with the process are deferred.

Some general issues involved in these operations are described below:

i) Immediate and delayed blocking: When can these two approaches be used?

If the process is not executing a system call, it can be blocked immediately.

If a process is executing a system call, it may or may not be possible to block it immediately, depending on the situation and implementation.

ii) Fast and slow I/O operations: It is feasible to wait for fast I/O operations (e.g. disk I/O) after blocking. However, not feasible to wait for slow I/O operations such as terminal. But proper mechanisms are necessary for these I/O operations to continue.

iii) Information about open files: Names of files, file descriptors, current modes, current position of their file pointers, etc need to preserved and

transferred. Also, temporary files would more efficiently be created at the node on which the process is executing.

iv) Reinstating the process on the destination node: This involves creating an empty process on the destination node, and the state of the transferred process is copied into the empty process and is unfrozen.

v) Address Transfer mechanisms: Migration of a process involves the transfer of the process state (includes contents of registers, memory tables, I/O states, process identifiers, etc.) and the process’s address space (i.e., code, data, and the program stack).

There are three ways to transfer the address space: a) Total freezing: Process execution is stopped while the address

space is being transferred. It is simple but inefficient b) Pre-transferring: The address space is transferred while the

process is still running on the source node. Pre-transfer is followed by repeated transfer of pages modified during the transfer.

c) Transfer on reference: Only part of the address space is transferred. The rest of the address space is transferred only on demand. vi) Message forwarding mechanisms: After the process has been

migrated, messages bound for that process should be forwarded to its current node. The following are the three types of messages:

a) messages received at the source after the process execution is stopped at the source but the process was not started at the new node;

b) messages received at the source node after the process has started executing at the destination;

c) messages to be sent to the migrant process from any other node after the process started executing at the destination.

Message Forwarding Mechanisms In moving a message, it must be ensured that all pending, en-route, and future messages arrive at the process’s new location. The messages to be forwarded to the migrant process’s new location can be classified into the following:

Type 1: Messages received at the source node after the process’s execution has been stopped on its source node and the process’s execution has not yet been started on its destination node.

Type 2: Messages received at the source node after the process’s execution has started on its destination node.

Type 3: Messages that are to be sent to the migrant process from any other node after it has started executing on the destination node.

The different mechanisms used for message forwarding in existing distributed systems are described below:

1. Resending the message: Instead of the source node forwarding the messages received for the migrated process, it notifies the sender about the

status of the process. The sender locates the process and resends the message.

2. Origin site mechanism: Process’s origin site is embedded in the process identifier.

Each site is responsible for keeping information about the current locations of all the processes created on it.

Messages are always sent to the origin site. The origin site then forwards it to the process’s current location.

A drawback of this approach is that the failure of the origin site will disrupt the message forwarding .

Another drawback is that there is continuous load on the origin site.

3. Link traversal mechanism: A forwarding address is left at the source node

The forwarding address has two components o The first component is a system-wide unique process identifier,

consisting of (id of the node on which the process was created, local pid)

o The second component is the known location of the process. This component is updated when the corresponding process is accessed form the node.

Co-processes Handling Mechanisms In systems that allow process migration, an important issue is the necessity to provide efficient communication between a process (parent) and its sub-processes (children), which might have been migrated and placed on different nodes. The two different mechanisms used by existing distributed operating systems to take care of this problem are described below: 1. Disallowing separation of co-processes: There are two ways to do this

Disallow migration of processes that wait for one or more of their children to complete.

Migrate children processes along with their parent process.

2. Home node or origin site concept: This approach. Allows the processes and sub-processes to migrate independently. All communication between the parent and children processes take

place via the home node.

Process Migration in Heterogeneous Systems Following are the ways to handle heterogeneous systems

Use external data representation mechanism to handle this.

Issues related to handling floating point representation need to be addressed. i.e., number of bits allocated to mantissa and exponent should be at least as large as the largest representation in the system.

Signed infinity and signed 0 representation: Not all nodes in the system may support this.

Process Migration Merits Reducing the average response time of the processes Speeding up individual jobs Gaining higher throughput Utilizing resources effectively Reducing network traffic Improving system reliability Improving system security

(b)Threads Threads are a popular way to improve application performance through parallelism. In traditional operating systems the basic unit of CPU utilization is a process. Each process has its own program counter, register states, stack, and address space. In operating systems with threads facility, the basic unit of CPU utilization is a thread. In these operating systems, a process consists of an address space and one or more threads of control. Each thread of a process has its own program counter, register states, and stack. But all the threads of a process share the same address space. Hence they also share the same global variables. In addition, all threads of a process also share the same set of operating system resources such as open files, child processes, semaphores, signals, accounting information, and so on. Threads share the CPU in the same way as processes do. i.e. on a uni-processor system, threads run in a time-sharing mode, whereas on a shared memory multi-processor, as many threads can run simultaneously as there are processors. Akin to traditional processes, threads can create child threads, can block waiting for system calls to complete, and can change states during their course of execution. At a particular instance of time, a thread can be in any one of several states: Running, Blocked, Ready, or Terminated. In operating systems with threading facility, a process having a single thread corresponds to a process of a traditional operating system. Threads are referred to as lightweight processes and traditional processes are referred to as heavyweight processes.

Why Threads? Some of the limitations of the traditional process model are listed below:

1. Many applications wish to perform several largely independent tasks that can run concurrently, but must share the same address space and other resources.

For example, a database server or file server UNIX’s make facility allows users to compile several files in parallel, using separate processes for each.

2. Creating several processes and maintaining them involves lot of overhead. When a context switch occurs, the state information of the process (register values, page tables, file descriptors, outstanding I/O requests, etc) need to be saved.

3. On UNIX systems, new processes are created using the fork system call. fork is an expensive system call.

4. Processes cannot take advantage of multiprocessor architectures, because a process can only use one processor at a time. An application must create a number of processes and dispatch them to the available processors.

5. Switching between threads sharing the same address space is considerably cheaper than switching between processes The traditional UNIX process is single-threaded.

Consider a set of single threaded processes executing on a Uni - processor machine. The first three processes were spawned by a server in response to three clients. The lower two processes run some other server application

Traditional UNIX system – Uniprocessor with single-threaded processes

Two servers running on a uni – processor system. Each server runs as a single process, with multiple threads sharing a single address space. Inter-thread context-switching can be handled by either the OS kernel or a user-level threads library. Eliminating multiple nearly identical address spaces for each application reduces the load on the memory subsystem.

Disadvantage: Multithreaded processes must be concerned with synchronizing the access to the objects by several of their own threads. Two Multithreaded processes running on a multiprocessor. All threads of one process share the same address space, but run on different processors. We get improved performance but synchronization is more complicated.

Multithreaded Processes in a Multiprocessor System

To summarize: A Process can be divided into two components – a set of threads and a collection of resources. The collection of resources include an address space, open files, user credentials, quotas, etc, that are shared by all threads in the process.

A Thread is a dynamic object that represents a control point in the process and

that executes a sequence of instructions. has its private objects, program counter, stack, and a register context.

User-level thread libraries. IEEE POSIX standards group generated several drafts of a threads

package known as pthreads. Sun’s Solaris OS supports pthreads library. It also has implemented its

own threads library.

Models for Organizing Threads The following are some ways of organizing threads:

Dispatcher-workers model: Dispatcher thread accepts requests from clients and dispatches it to one of the appropriate free worker threads for further processing of the request.

Team Model: All threads behave equal in this model. Each thread gets and process’s client’s request on its own Pipline model: In this model, threads are arranged in a pipeline so that output data generated by the first thread is used for processing by the second thread, output by second thread is used by the third....

User-level Threads Libraries The interface provided by the threads package must include several important facilities such as for:

Creating and terminating threads Suspending and resuming threads

Assigning priorities to the individual threads Thread scheduling and context switching Synchronizing activities through facilities such as semaphores and

mutual exclusion locks Sending messages from one thread to another

Case Study – DCE threads DCE threads comply with IEEE POSIX (Portable OS interface) standard known as P-Threads.

DCE provides a set of user-level library procedures for the creation and maintenance of threads.

To access the thread services DCE provides an API that is compatible to the POSIX standard.

If a system supporting DCE has no intrinsic support for threads, the API provides an interface to the thread library that is linked to the application.

If the system supporting DCE has OS kernel support for threads, DCE is set up to use this facility. In this case the API serves as an interface to kernel supported threads facility.