Unit 2
System Models
2.1. Introduction Systems that are intended for use in real-world environments should be designed to function correctly in the widest possible range of circumstances and in the face of many possible difficulties and threats. Difficulties and threats for distributed systems Here are some of the problems that the designers of distributed systems face. Widely varying modes of use: The component parts of systems are subject to wide variations in workload – for example, some web pages are accessed several million times a day. Some parts of a system may be disconnected, or poorly connected some of the time – for example, when mobile computers are included in a system. Some applications have special requirements for high communication bandwidth and low latency – for example, multimedia applications. Wide range of system environments: A distributed system must accommodate heterogeneous hardware, operating systems and networks. The networks may differ widely in performance – wireless networks operate at a fraction of the speed of local networks. Systems of widely differing scales, ranging from tens of computers to millions of computers, must be supported. Internal problems: Non-synchronized clocks, conflicting data updates and many modes of hardware and software failure involving the individual system components. External threats: Attacks on data integrity and secrecy, denial of service attacks. Each type of model is intended to provide an abstract, simplified but consistent description of a relevant aspect of distributed system design. Physical models are the most explicit way in which to describe a system; they capture the hardware composition of a system in terms of the computers (and other devices, such as mobile phones) and their interconnecting networks. Architectural models describe a system in terms of the computational and communication tasks performed by its computational elements; the computational elements being individual computers or aggregates of them supported by appropriate network interconnections. Fundamental models take an abstract perspective in order to examine individual aspects of a distributed system. In this chapter we introduce fundamental models that examine three important aspects of distributed systems: interaction models, which consider the structure and sequencing of the communication between the elements of the system; failure models, which consider the ways in which a system may fail to operate correctly and; security models, which consider how the system is protected against attempts to interfere with its correct operation or to steal its data. 2.2. Architectural Models An architectural model of a distributed system first simplifies and abstracts the functions of the individual components of a distributed system and it considers: • The placement of the components across a network of computers. • The interrelationships between the components. Some more dynamic systems can be built as variations on the client and server model are • The possibility of moving code from one process to another allows a process to delegate tasks another process. • Some distributed systems are designed to enable computers and other mobile devices to be added or removed seamlessly, allowing them to discover the available services and offer their services to tohers. 2.2.1. Software Layers The software architecture refers to the structure of software as layers or modules in a single computer or more recently in terms of services offered and requested between processes located in the same or different computers. The Figure 2.1 gives the overview of platform and middleware. Figure 2.1 Hardware and Software Layers in distributed systems. Platform The lowest level hardware and software layers are called as “platform” for distributed systems and applications. These low level layers provide services to the layers above them, which are implemented independently in each computer, bringing to the system’s programming interface up to a level that facilitates communication and coordination between processes. Middleware Middleware is a layer of software which will mask heterogeneity and to provide the convenient programming model to application programmers. Middleware is represented by processes or objects in a set of computers that interact with each other to implement communication and resource sharing support for distributed applications. Examples of middleware include • CORBA • Java RMI • Web services • Mircorsoft’s Distributed Component Object Model (DCOM) • The ISO/IU-T’s Reference Model for Open Distributed Processing (RM-ODP). 2.2.2. System Architectures The two types of architectural models of distributed systems are • Client –Server architecture • Peer-Peer architecture Client –Server architecture This is very popular architecture for distributed systems. Figure 2.2 explains simple structure in which client processes interact with individual server processes in separate host computers in order to access the shared resources that they manage. The web crawlers are the programs which run in the background at a search engine site using HTTP requests to access web servers throughout the internet. Figure 2.2 Clients Invoke Individual Servers. Peer-Peer architecture In this architecture, all of the processes involved in a task play similar roles, interacting cooperatively as peers without any distinction between client and server processes or the computers that they run on. While the client server model offers a direct and relatively simple approach to the sharing of resources and data, it scales poorly. Peer to Peer applications and systems have been successfully constructed that enable tens or hundreds of thousands of computers to provide access to data and other resources that they collectively store and manage. Figure 2.3 explains the form of a peer-to-peer application. Applications are composed of large numbers of peer processes running on separate computers and the pattern of communication between them depends entirely on application requirements. Figure 2.3 A Distributed Application based on the Peer-to-Peer Architecture. 2.2.3. Variations Services provided by multiple servers Services may be implemented as several server processes in separate host computers interacting as necessary to provide a service to client processes as shown in Figure 2.4. The servers may partition the set of objects on which the service based and distribute them between themselves, or they may maintain replicated copies of them on several hosts. Figure 2.4 A Service Provided by Multiple Servers. Proxy servers and caches A cache is a store of recently used data objects that is closer than the objects themselves. When a new object is received at a computer it is added to the cache store, replacing some existing objects if necessary. Web proxy servers provide a shared cache of web resources for client machines at a site or across several sites. The purpose of proxy server is to increase availability and performance of the service by reducing the load on the wide area network and web servers. Figure 2.5 Web Proxy Servers. Mobile Code Applets are well known and widely used example of mobile load. The user running a browser selects a link to an applet whose code is stored on a web server, where the code is downloaded to the browser and runs there, as shown in Figure 2.6. An advantage of running the downloaded code locally is that it can give good interactive response since it does not suffer from the delays or variability of bandwidth associated with network communication. In push model, instead of server, the client initiates the interactions. Figure 2.6 Web Applets. Mobile Agents A mobile agent is a running program that travels from one computer to another in a network carrying out a task on someone’s behalf, such as collecting information, eventually returning with the results. Mobile agents might be used to install and maintain software on the computer within an organization. Mobile agents are a potential security threat to the resources in computers that they visit. Network Computers The network computer downloads its operating system and any application software needed by the user from a remote file server. Applications are run locally but the files are managed by a remote file server. Network applications such as a web browser can also be run. Since all the application data and code is stored by a file server, the users may migrate from one network computer to another. The processor and memory capacities of a network computer can be constrained in order to reduce its cost. Thin Clients The thin client refers to a software layer that supports a window based server interface on a computer that is local to the user while executing application programs on a remote computer as shown inn Figure 2.7. This architecture has the same low management and hardware costs as the network computer scheme, but instead of downloading the code of applications into the user’s computer. Figure 2.7 Thin Clients and Computer Servers. 2.2.4. Interfaces and Objects In basic client server architecture, each server process is seen as a single entity with a fixed interface defining the functions that can be invoked in it. The CORBA and Java model, the number and types of objects hosted by each process may vary as system activities require and in some implementations the locations of objects may also change. 2.2.5. Design Requirements for distributed architectures Performance issues Performance issues arising from the limited processing and communication capabilities of computers and networks are 1. Responsiveness 2. Throughput 3. Balancing Computational Loads Quality of services The non functional properties of systems that affect the quality service experienced by clients and users are reliability, security and performance. Adaptability to meet changing system configurations and resource availability has been recognized as a further important aspect of service quality. Reliability and security issues are critical in the design of most computer systems. There are related to failure model and security model. Use of caching and replication The web caching protocol allows both web browsers and proxy servers that caches responses to client requests to web servers. Therefore a client request may be satisfied by a response cached by the web browser or by a proxy server between it and the web server. The cache consistency protocol can be configured to provide browsers with fresh copies of resources held by the web server. Dependability issues Dependability is a requirement in most application domains. It is crucial not only in command and control activities but also in many commercial applications including the rapidly developing domain of internet commerce. Dependability of computer system is defined as correctness, security and fault tolerance. Dependable applications should continue to function correctly in the presence of faults, in hardware, software and networks. The architectural impact of the requirement for security concerns the need to locate sensitive data and other resources only in computers that can be secured effectively against attack. 2.3. Fundamental Problems In general, such a fundamental model should contain only the essential ingredients that considered to understanding and reasoning about aspects of a system’s behaviour. The purpose of such a model is: • To make explicit all the relevant assumptions about the systems we are modelling. • To make generalizations concerning what is possible or impossible, given those assumptions. The generalizations may take the form of general-purpose algorithms or desirable properties that are guaranteed. The aspects of distributed systems are Interaction: Computation occurs within processes; the processes interact by passing messages, resulting in communication (information flow) and coordination (synchronization and ordering of activities) between processes. In the analysis and design of distributed systems, interactions are concerned. The interaction model must reflect the facts that communication takes place with delays that are often of considerable duration, and that the accuracy with which independent processes can be coordinated is limited by these delays and by the difficulty of maintaining the same notion of time across all the computers in a distributed system. Failure: The correct operation of a distributed system is threatened whenever a fault occurs in any of the computers on which it runs (including software faults) or in the network that connects them. This provides a basis for the analysis of their potential effects and for the design of systems that are able to tolerate faults of each type while continuing to run correctly. Security: The modular nature of distributed systems and their openness exposes them to attack by both external and internal agents. The security model defines and classifies the forms that such attacks may take, providing a basis for the analysis of threats to a system and for the design of systems that are able to resist them. 2.3.1. Interaction Model Two significant factors affecting interacting processes in a distributed system: • Communication performance is often a limiting characteristic. • It is impossible to maintain a single global notion of time. Performance of communication channels • The communication channels in our model are realized in a variety of ways in distributed systems – for example, by an implementation of streams or by simple message passing over a computer network. Communication over a computer network has the following performance characteristics relating to latency, bandwidth and jitter: • The delay between the start of a message’s transmission from one process and the beginning of its receipt by another is referred to as latency. The latency includes: – The time taken for the first of a string of bits transmitted through a network to reach its destination. For example, the latency for the transmission of a message through a satellite link is the time for a radio signal to travel to the satellite and back. – The delay in accessing the network, which increases significantly when the network is heavily loaded. For example, for Ethernet transmission the sending station waits for the network to be free of traffic. – The time taken by the operating system communication services at both the sending and the receiving processes, which varies according to the current load on the operating systems. • The bandwidth of a computer network is the total amount of information that can be transmitted over it in a given time. When a large number of communication channels are using the same network, they have to share the available bandwidth. • Jitter is the variation in the time taken to deliver a series of messages. Jitter is relevant to multimedia data. For example, if consecutive samples of audio data are played with differing time intervals, the sound will be badly distorted. Computer clocks and timing events Each computer in a distributed system has its own internal clock, which can be used by local processes to obtain the value of the current time. Therefore two processes running on different computers can each associate timestamps with their events. However, even if the two processes read their clocks at the same time, their local clocks may supply different time values. This is because computer clocks drift from perfect time and, more importantly, their drift rates differ from one another. The term clock drift rate refers to the rate at which a computer clock deviates from a perfect reference clock. Even if the clocks on all the computers in a distributed system are set to the same time initially, their clocks will eventually vary quite significantly unless corrections are applied. There are several approaches to correcting the times on computer clocks. For example, computers may use radio receivers to get time readings from the Global Positioning System with an accuracy of about 1 microsecond. But GPS receivers do not operate inside buildings, nor can the cost be justified for every computer. Instead, a computer that has an accurate time source such as GPS can send timing messages to other computers in its network. The resulting agreement between the times on the local clocks is, of course, affected by variable message delays. Two variants of the interaction model In a distributed system it is hard to set limits on the time that can be taken for process execution, message delivery or clock drift. Synchronous distributed systems: It is defined a synchronous distributed system to be one in which the following bounds are defined: • The time to execute each step of a process has known lower and upper bounds. • Each message transmitted over a channel is received within a known bounded time. • Each process has a local clock whose drift rate from real time has a known bound. Asynchronous distributed systems: Many distributed systems, such as the Internet, are very useful without being able to qualify as synchronous systems. An asynchronous distributed system is one in which there are no bounds on: • Process execution speeds – for example, one process step may take only a picosecond and another a century; all that can be said is that each step may take an arbitrarily long time. • Message transmission delays – for example, one message from process A to process B may be delivered in negligible time and another may take several years. In other words, a message may be received after an arbitrarily long time. • Clock drift rates – again, the drift rate of a clock is arbitrary. Event ordering In many cases, we are interested in knowing whether an event (sending or receiving a message) at one process occurred before, after or concurrently with another event at another process. The execution of a system can be described in terms of events and their ordering despite the lack of accurate clocks. 2.3.2. Failure Model In a distributed system both processes and communication channels may fail – that is, they may depart from what is considered to be correct or desirable behaviour. The failure model defines the ways in which failure may occur in order to provide an understanding of the effects of failures. Omission failures • The faults classified as omission failures refer to cases when a process or communication channel fails to perform actions that it is supposed to do. Process omission failures: The chief omission failure of a process is to crash. However, this method of crash detection relies on the use of timeouts – that is, a method in which one process allows a fixed period of time for something to occur. In an asynchronous system a timeout can indicate only that a process is not responding – it may have crashed or may be slow, or the messages may not have arrived. A process crash is called fail-stop if other processes can detect certainly that the process has crashed. Fail-stop behaviour can be produced in a synchronous system if the processes use timeouts to detect when other processes fail to respond and messages are guaranteed to be delivered. Communication omission failures Consider the communication primitives send and receive. The loss of messages between the sending process and the outgoing message buffer is called as send omission failures, to loss of messages between the incoming message buffer and the receiving process as receive-omission failures, and to loss of messages in between as channel omission failures. Failures can be categorized according to their severity. All of the failures we have described so far are benign failures. Most failures in distributed systems are benign. Benign failures include failures of omission as well as timing failures and performance failures. Arbitrary failures The term arbitrary or Byzantine failure is used to describe the worst possible failure semantics, in which any type of error may occur. For example, a process may set wrong values in its data items, or it may return a wrong value in response to an invocation. Timing failures Timing failures are applicable in synchronous distributed systems where time limits are set on process execution time, message delivery time and clock drift rate. Masking failures Each component in a distributed system is generally constructed from a collection of other components. It is possible to construct reliable services from components that exhibit failures. 2.3.3. Security Model The security of a distributed system can be achieved by securing the processes and the channels used for their interactions and by protecting the objects that they encapsulate against unauthorized access. Protecting objects Figure 2.1 Objects and principals. Figure 2.1 shows a server that manages a collection of objects on behalf of some users. The users can run client programs that send invocations to the server to perform operations on the objects. The server carries out the operation specified in each invocation and sends the result to the client. Objects are intended to be used in different ways by different users. For example, some objects may hold a user’s private data, such as their mailbox, and other objects may hold shared data such as web pages. To support this, access rights specify which is allowed to perform the operations of an object. The principal is an authority associated for each result with the corresponding invocation. A principal may be a user or a process. The server is responsible for verifying the identity of the principal behind each invocation and checking that they have sufficient access rights to perform the requested operation on the particular object invoked, rejecting those that do not. The client may check the identity of the principal behind the server to ensure that the result comes from the required server. Securing processes and their interactions Processes interact by sending messages. The messages are exposed to attack because the network and the communication service that they use are open, to enable any pair of processes to interact. Servers and peer processes expose their interfaces, enabling invocations to be sent to them by any other process. Distributed systems are often deployed and used in tasks that are likely to be subject to external attacks by hostile users. This is especially true for applications that handle financial transactions, confidential or classified information or any other information whose secrecy or integrity is crucial. Integrity is threatened by security violations as well as communication failures. So we know that there are likely to be threats to the processes of which such applications are composed and to the messages travelling between the processes. The enemy To model security threats, enemy (adversary) is introduced that is capable of sending any message to any process and reading or copying any message sent between a pair of processes, as shown in Figure 2.2. Such attacks can be made simply by using a computer connected to a network to run a program that reads network messages addressed to other computers on the network, or a program that generates messages that make false requests to services, purporting to come from authorized users. The attack may come from a computer that is legitimately connected to the network or from one that is connected in an unauthorized manner. The threats from a potential enemy include threats to processes and threats to communication channels. Figure 2.2 The enemy. Threats to processes: A process that is designed to handle incoming requests may receive a message from any other process in the distributed system, and it cannot necessarily determine the identity of the sender. Servers: Since a server can receive invocations from many different clients, it cannot necessarily determine the identity of the principal behind any particular invocation. Even if a server requires the inclusion of the principal’s identity in each invocation, an enemy might generate an invocation with a false identity. Without reliable knowledge of the sender’s identity, a server cannot tell whether to perform the operation or to reject it. For example, a mail server would not know whether the user behind an invocation that requests a mail item from a particular mailbox is allowed to do so or whether it was a request from an enemy. Clients: When a client receives the result of an invocation from a server, it cannot necessarily tell whether the source of the result message is from the intended server or from an enemy, perhaps ‘spoofing’ the mail server. Thus the client could receive a result that was unrelated to the original invocation, such as a false mail item.
System Models
2.1. Introduction Systems that are intended for use in real-world environments should be designed to function correctly in the widest possible range of circumstances and in the face of many possible difficulties and threats. Difficulties and threats for distributed systems Here are some of the problems that the designers of distributed systems face. Widely varying modes of use: The component parts of systems are subject to wide variations in workload – for example, some web pages are accessed several million times a day. Some parts of a system may be disconnected, or poorly connected some of the time – for example, when mobile computers are included in a system. Some applications have special requirements for high communication bandwidth and low latency – for example, multimedia applications. Wide range of system environments: A distributed system must accommodate heterogeneous hardware, operating systems and networks. The networks may differ widely in performance – wireless networks operate at a fraction of the speed of local networks. Systems of widely differing scales, ranging from tens of computers to millions of computers, must be supported. Internal problems: Non-synchronized clocks, conflicting data updates and many modes of hardware and software failure involving the individual system components. External threats: Attacks on data integrity and secrecy, denial of service attacks. Each type of model is intended to provide an abstract, simplified but consistent description of a relevant aspect of distributed system design. Physical models are the most explicit way in which to describe a system; they capture the hardware composition of a system in terms of the computers (and other devices, such as mobile phones) and their interconnecting networks. Architectural models describe a system in terms of the computational and communication tasks performed by its computational elements; the computational elements being individual computers or aggregates of them supported by appropriate network interconnections. Fundamental models take an abstract perspective in order to examine individual aspects of a distributed system. In this chapter we introduce fundamental models that examine three important aspects of distributed systems: interaction models, which consider the structure and sequencing of the communication between the elements of the system; failure models, which consider the ways in which a system may fail to operate correctly and; security models, which consider how the system is protected against attempts to interfere with its correct operation or to steal its data. 2.2. Architectural Models An architectural model of a distributed system first simplifies and abstracts the functions of the individual components of a distributed system and it considers: • The placement of the components across a network of computers. • The interrelationships between the components. Some more dynamic systems can be built as variations on the client and server model are • The possibility of moving code from one process to another allows a process to delegate tasks another process. • Some distributed systems are designed to enable computers and other mobile devices to be added or removed seamlessly, allowing them to discover the available services and offer their services to tohers. 2.2.1. Software Layers The software architecture refers to the structure of software as layers or modules in a single computer or more recently in terms of services offered and requested between processes located in the same or different computers. The Figure 2.1 gives the overview of platform and middleware. Figure 2.1 Hardware and Software Layers in distributed systems. Platform The lowest level hardware and software layers are called as “platform” for distributed systems and applications. These low level layers provide services to the layers above them, which are implemented independently in each computer, bringing to the system’s programming interface up to a level that facilitates communication and coordination between processes. Middleware Middleware is a layer of software which will mask heterogeneity and to provide the convenient programming model to application programmers. Middleware is represented by processes or objects in a set of computers that interact with each other to implement communication and resource sharing support for distributed applications. Examples of middleware include • CORBA • Java RMI • Web services • Mircorsoft’s Distributed Component Object Model (DCOM) • The ISO/IU-T’s Reference Model for Open Distributed Processing (RM-ODP). 2.2.2. System Architectures The two types of architectural models of distributed systems are • Client –Server architecture • Peer-Peer architecture Client –Server architecture This is very popular architecture for distributed systems. Figure 2.2 explains simple structure in which client processes interact with individual server processes in separate host computers in order to access the shared resources that they manage. The web crawlers are the programs which run in the background at a search engine site using HTTP requests to access web servers throughout the internet. Figure 2.2 Clients Invoke Individual Servers. Peer-Peer architecture In this architecture, all of the processes involved in a task play similar roles, interacting cooperatively as peers without any distinction between client and server processes or the computers that they run on. While the client server model offers a direct and relatively simple approach to the sharing of resources and data, it scales poorly. Peer to Peer applications and systems have been successfully constructed that enable tens or hundreds of thousands of computers to provide access to data and other resources that they collectively store and manage. Figure 2.3 explains the form of a peer-to-peer application. Applications are composed of large numbers of peer processes running on separate computers and the pattern of communication between them depends entirely on application requirements. Figure 2.3 A Distributed Application based on the Peer-to-Peer Architecture. 2.2.3. Variations Services provided by multiple servers Services may be implemented as several server processes in separate host computers interacting as necessary to provide a service to client processes as shown in Figure 2.4. The servers may partition the set of objects on which the service based and distribute them between themselves, or they may maintain replicated copies of them on several hosts. Figure 2.4 A Service Provided by Multiple Servers. Proxy servers and caches A cache is a store of recently used data objects that is closer than the objects themselves. When a new object is received at a computer it is added to the cache store, replacing some existing objects if necessary. Web proxy servers provide a shared cache of web resources for client machines at a site or across several sites. The purpose of proxy server is to increase availability and performance of the service by reducing the load on the wide area network and web servers. Figure 2.5 Web Proxy Servers. Mobile Code Applets are well known and widely used example of mobile load. The user running a browser selects a link to an applet whose code is stored on a web server, where the code is downloaded to the browser and runs there, as shown in Figure 2.6. An advantage of running the downloaded code locally is that it can give good interactive response since it does not suffer from the delays or variability of bandwidth associated with network communication. In push model, instead of server, the client initiates the interactions. Figure 2.6 Web Applets. Mobile Agents A mobile agent is a running program that travels from one computer to another in a network carrying out a task on someone’s behalf, such as collecting information, eventually returning with the results. Mobile agents might be used to install and maintain software on the computer within an organization. Mobile agents are a potential security threat to the resources in computers that they visit. Network Computers The network computer downloads its operating system and any application software needed by the user from a remote file server. Applications are run locally but the files are managed by a remote file server. Network applications such as a web browser can also be run. Since all the application data and code is stored by a file server, the users may migrate from one network computer to another. The processor and memory capacities of a network computer can be constrained in order to reduce its cost. Thin Clients The thin client refers to a software layer that supports a window based server interface on a computer that is local to the user while executing application programs on a remote computer as shown inn Figure 2.7. This architecture has the same low management and hardware costs as the network computer scheme, but instead of downloading the code of applications into the user’s computer. Figure 2.7 Thin Clients and Computer Servers. 2.2.4. Interfaces and Objects In basic client server architecture, each server process is seen as a single entity with a fixed interface defining the functions that can be invoked in it. The CORBA and Java model, the number and types of objects hosted by each process may vary as system activities require and in some implementations the locations of objects may also change. 2.2.5. Design Requirements for distributed architectures Performance issues Performance issues arising from the limited processing and communication capabilities of computers and networks are 1. Responsiveness 2. Throughput 3. Balancing Computational Loads Quality of services The non functional properties of systems that affect the quality service experienced by clients and users are reliability, security and performance. Adaptability to meet changing system configurations and resource availability has been recognized as a further important aspect of service quality. Reliability and security issues are critical in the design of most computer systems. There are related to failure model and security model. Use of caching and replication The web caching protocol allows both web browsers and proxy servers that caches responses to client requests to web servers. Therefore a client request may be satisfied by a response cached by the web browser or by a proxy server between it and the web server. The cache consistency protocol can be configured to provide browsers with fresh copies of resources held by the web server. Dependability issues Dependability is a requirement in most application domains. It is crucial not only in command and control activities but also in many commercial applications including the rapidly developing domain of internet commerce. Dependability of computer system is defined as correctness, security and fault tolerance. Dependable applications should continue to function correctly in the presence of faults, in hardware, software and networks. The architectural impact of the requirement for security concerns the need to locate sensitive data and other resources only in computers that can be secured effectively against attack. 2.3. Fundamental Problems In general, such a fundamental model should contain only the essential ingredients that considered to understanding and reasoning about aspects of a system’s behaviour. The purpose of such a model is: • To make explicit all the relevant assumptions about the systems we are modelling. • To make generalizations concerning what is possible or impossible, given those assumptions. The generalizations may take the form of general-purpose algorithms or desirable properties that are guaranteed. The aspects of distributed systems are Interaction: Computation occurs within processes; the processes interact by passing messages, resulting in communication (information flow) and coordination (synchronization and ordering of activities) between processes. In the analysis and design of distributed systems, interactions are concerned. The interaction model must reflect the facts that communication takes place with delays that are often of considerable duration, and that the accuracy with which independent processes can be coordinated is limited by these delays and by the difficulty of maintaining the same notion of time across all the computers in a distributed system. Failure: The correct operation of a distributed system is threatened whenever a fault occurs in any of the computers on which it runs (including software faults) or in the network that connects them. This provides a basis for the analysis of their potential effects and for the design of systems that are able to tolerate faults of each type while continuing to run correctly. Security: The modular nature of distributed systems and their openness exposes them to attack by both external and internal agents. The security model defines and classifies the forms that such attacks may take, providing a basis for the analysis of threats to a system and for the design of systems that are able to resist them. 2.3.1. Interaction Model Two significant factors affecting interacting processes in a distributed system: • Communication performance is often a limiting characteristic. • It is impossible to maintain a single global notion of time. Performance of communication channels • The communication channels in our model are realized in a variety of ways in distributed systems – for example, by an implementation of streams or by simple message passing over a computer network. Communication over a computer network has the following performance characteristics relating to latency, bandwidth and jitter: • The delay between the start of a message’s transmission from one process and the beginning of its receipt by another is referred to as latency. The latency includes: – The time taken for the first of a string of bits transmitted through a network to reach its destination. For example, the latency for the transmission of a message through a satellite link is the time for a radio signal to travel to the satellite and back. – The delay in accessing the network, which increases significantly when the network is heavily loaded. For example, for Ethernet transmission the sending station waits for the network to be free of traffic. – The time taken by the operating system communication services at both the sending and the receiving processes, which varies according to the current load on the operating systems. • The bandwidth of a computer network is the total amount of information that can be transmitted over it in a given time. When a large number of communication channels are using the same network, they have to share the available bandwidth. • Jitter is the variation in the time taken to deliver a series of messages. Jitter is relevant to multimedia data. For example, if consecutive samples of audio data are played with differing time intervals, the sound will be badly distorted. Computer clocks and timing events Each computer in a distributed system has its own internal clock, which can be used by local processes to obtain the value of the current time. Therefore two processes running on different computers can each associate timestamps with their events. However, even if the two processes read their clocks at the same time, their local clocks may supply different time values. This is because computer clocks drift from perfect time and, more importantly, their drift rates differ from one another. The term clock drift rate refers to the rate at which a computer clock deviates from a perfect reference clock. Even if the clocks on all the computers in a distributed system are set to the same time initially, their clocks will eventually vary quite significantly unless corrections are applied. There are several approaches to correcting the times on computer clocks. For example, computers may use radio receivers to get time readings from the Global Positioning System with an accuracy of about 1 microsecond. But GPS receivers do not operate inside buildings, nor can the cost be justified for every computer. Instead, a computer that has an accurate time source such as GPS can send timing messages to other computers in its network. The resulting agreement between the times on the local clocks is, of course, affected by variable message delays. Two variants of the interaction model In a distributed system it is hard to set limits on the time that can be taken for process execution, message delivery or clock drift. Synchronous distributed systems: It is defined a synchronous distributed system to be one in which the following bounds are defined: • The time to execute each step of a process has known lower and upper bounds. • Each message transmitted over a channel is received within a known bounded time. • Each process has a local clock whose drift rate from real time has a known bound. Asynchronous distributed systems: Many distributed systems, such as the Internet, are very useful without being able to qualify as synchronous systems. An asynchronous distributed system is one in which there are no bounds on: • Process execution speeds – for example, one process step may take only a picosecond and another a century; all that can be said is that each step may take an arbitrarily long time. • Message transmission delays – for example, one message from process A to process B may be delivered in negligible time and another may take several years. In other words, a message may be received after an arbitrarily long time. • Clock drift rates – again, the drift rate of a clock is arbitrary. Event ordering In many cases, we are interested in knowing whether an event (sending or receiving a message) at one process occurred before, after or concurrently with another event at another process. The execution of a system can be described in terms of events and their ordering despite the lack of accurate clocks. 2.3.2. Failure Model In a distributed system both processes and communication channels may fail – that is, they may depart from what is considered to be correct or desirable behaviour. The failure model defines the ways in which failure may occur in order to provide an understanding of the effects of failures. Omission failures • The faults classified as omission failures refer to cases when a process or communication channel fails to perform actions that it is supposed to do. Process omission failures: The chief omission failure of a process is to crash. However, this method of crash detection relies on the use of timeouts – that is, a method in which one process allows a fixed period of time for something to occur. In an asynchronous system a timeout can indicate only that a process is not responding – it may have crashed or may be slow, or the messages may not have arrived. A process crash is called fail-stop if other processes can detect certainly that the process has crashed. Fail-stop behaviour can be produced in a synchronous system if the processes use timeouts to detect when other processes fail to respond and messages are guaranteed to be delivered. Communication omission failures Consider the communication primitives send and receive. The loss of messages between the sending process and the outgoing message buffer is called as send omission failures, to loss of messages between the incoming message buffer and the receiving process as receive-omission failures, and to loss of messages in between as channel omission failures. Failures can be categorized according to their severity. All of the failures we have described so far are benign failures. Most failures in distributed systems are benign. Benign failures include failures of omission as well as timing failures and performance failures. Arbitrary failures The term arbitrary or Byzantine failure is used to describe the worst possible failure semantics, in which any type of error may occur. For example, a process may set wrong values in its data items, or it may return a wrong value in response to an invocation. Timing failures Timing failures are applicable in synchronous distributed systems where time limits are set on process execution time, message delivery time and clock drift rate. Masking failures Each component in a distributed system is generally constructed from a collection of other components. It is possible to construct reliable services from components that exhibit failures. 2.3.3. Security Model The security of a distributed system can be achieved by securing the processes and the channels used for their interactions and by protecting the objects that they encapsulate against unauthorized access. Protecting objects Figure 2.1 Objects and principals. Figure 2.1 shows a server that manages a collection of objects on behalf of some users. The users can run client programs that send invocations to the server to perform operations on the objects. The server carries out the operation specified in each invocation and sends the result to the client. Objects are intended to be used in different ways by different users. For example, some objects may hold a user’s private data, such as their mailbox, and other objects may hold shared data such as web pages. To support this, access rights specify which is allowed to perform the operations of an object. The principal is an authority associated for each result with the corresponding invocation. A principal may be a user or a process. The server is responsible for verifying the identity of the principal behind each invocation and checking that they have sufficient access rights to perform the requested operation on the particular object invoked, rejecting those that do not. The client may check the identity of the principal behind the server to ensure that the result comes from the required server. Securing processes and their interactions Processes interact by sending messages. The messages are exposed to attack because the network and the communication service that they use are open, to enable any pair of processes to interact. Servers and peer processes expose their interfaces, enabling invocations to be sent to them by any other process. Distributed systems are often deployed and used in tasks that are likely to be subject to external attacks by hostile users. This is especially true for applications that handle financial transactions, confidential or classified information or any other information whose secrecy or integrity is crucial. Integrity is threatened by security violations as well as communication failures. So we know that there are likely to be threats to the processes of which such applications are composed and to the messages travelling between the processes. The enemy To model security threats, enemy (adversary) is introduced that is capable of sending any message to any process and reading or copying any message sent between a pair of processes, as shown in Figure 2.2. Such attacks can be made simply by using a computer connected to a network to run a program that reads network messages addressed to other computers on the network, or a program that generates messages that make false requests to services, purporting to come from authorized users. The attack may come from a computer that is legitimately connected to the network or from one that is connected in an unauthorized manner. The threats from a potential enemy include threats to processes and threats to communication channels. Figure 2.2 The enemy. Threats to processes: A process that is designed to handle incoming requests may receive a message from any other process in the distributed system, and it cannot necessarily determine the identity of the sender. Servers: Since a server can receive invocations from many different clients, it cannot necessarily determine the identity of the principal behind any particular invocation. Even if a server requires the inclusion of the principal’s identity in each invocation, an enemy might generate an invocation with a false identity. Without reliable knowledge of the sender’s identity, a server cannot tell whether to perform the operation or to reject it. For example, a mail server would not know whether the user behind an invocation that requests a mail item from a particular mailbox is allowed to do so or whether it was a request from an enemy. Clients: When a client receives the result of an invocation from a server, it cannot necessarily tell whether the source of the result message is from the intended server or from an enemy, perhaps ‘spoofing’ the mail server. Thus the client could receive a result that was unrelated to the original invocation, such as a false mail item.
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
Post a Comment