UNIT 1 Distributed Systems - A distributed system is a system consisting of a collection of autonomous machines connected by communication networks and equipped

with software systems designed to produce an integrated and consistent computing environment. Distributed systems enable people to cooperate and coordinate their activities more effectively and efficiently. A system that consists of a collection of two or more independent computers which coordinate their processing through the exchange of synchronous or asynchronous message passing. A distributed system is a collection of independent computers that appear to the users of the system as a single computer. A distributed system is a collection of autonomous computers linked by a network with software designed to produce an integrated computing facility. CHARACTERISTICS OF DISTRIBUTED SYSTEMS 1. Resource sharing. In a distributed system, the resources - hardware, software and data can be easily shared among users. For example, a printer can be shared among a group of users. 2. Openness. The openness of distributed systems is achieved by specifying the key software interface of the system and making it available to software developers so that the system can be extended in many ways. 3. Concurrency. The processing concurrency can be achieved by sending requests to multiple machines connected by networks at the same time. 4. Scalability. A distributed system running on a collection of a small number of machines can be easily extended to a large number of machines to increase the processing power. 5. Fault-tolerance. Machines connected by networks can be seen as redundant resources, a software system can be installed on multiple machines so that in the face of hardware faults or software failures, the faults or failures can be detected and tolerated by other machines 6. No common physical clock This is an important assumption because it introduces the element of distribution in the system and gives rise to the inherent asynchrony amongst the processors. 7. No shared memory This is a key feature that requires message-passing for communication. This feature implies the absence of the common physical clock. It may be noted that a distributed system may still provide the abstraction of a common address space via the distributed shared memory abstraction. Computer Networks vs. Distributed Systems Computer Network: the autonomous computers are explicitly visible (have to be explicitly addressed) Distributed System: existence of multiple autonomous computers is

transparent

MOTIVATION The motivation for using a distributed system is some or all of the following requirements: 1. Inherently distributed computations In many applications such as money transfer in banking, or reaching consensus among parties that are geographically distant, the computation is inherently distributed. 2. Resource sharing Resources such as peripherals, complete data sets in databases, special libraries, as well as data (variable/files) cannot be fully replicated at all the sites because it is often neither practical nor cost-effective. Further, they cannot be placed at a single site because access to that site might prove to be a bottleneck. 3. Enhanced reliability A distributed system has the inherent potential to provide increased reliability because of the possibility of replicating resources and executions, as well as the reality that geographically distributed resources are not likely to crash/malfunction at the same time under normal circumstances. Reliability entails several aspects: availability, i.e., the resource should be accessible at all times; integrity, i.e., the value/state of the resource should be correct, in the face of concurrent access from multiple processors, as per the semantics expected by the application; fault-tolerance, i.e., the ability to recover from system failures, where such failures may be defined to occur in one of many failure models Increased performance/cost ratio By resource sharing and accessing geographically remote data and resources, the performance/cost ratio is increased. Scalability As the processors are usually connected by a wide-area network, adding more processors does not pose a direct bottleneck for the communication network. Modularity and incremental expandability Heterogeneous processors may be easily added into the system without affecting the performance, as long as those processors are running the same middleware algorithms. Physical seperation: systems that rely on the fact that computers are physically seperated (e.g., to satisfy reliability requirements). Economics: collections of microprocessors offer a better price/performance ratio than large mainframes mainframes: 10 times faster, 1000 times as expensive

EXAMPLES OF DISTRIBUTED SYSTEMS 1. The Internet Heterogeneous network of computers and applications Implemented through the Internet Protocol Stack 2. Distributed Multimedia-Systems Often use Internet infrastructure Characteristics Heterogeneous data sources and sinks that need to be synchronized in real time * Video * Audio * Text Often: Distribution services * Multicast Examples Teleteaching tools (mbone-based, etc.) iVideo-conferencing 3. Intranets Locally administered network Usually proprietary (e.g., the University campus network) Interfaces with the Internet Firewalls Provides services internally and externally 4. Mobile and Ubiquitous Computing Systems Cellular phone systems (e.g., GSM, UMTS) Resources being shared * Radio frequencies * Transmission times on one frequency (UMTS: multiplexing) * The mobile on the move Laptop computers Wireless LANs (faculty campus WLAN, "MoPo") Handheld devices, PDAs etc 5. Embedded systems The networked coffee mug Avionics control systems Flight management systems in aircraft 6. Telephony systems

 Examples POTS , ISDN , Intelligent Networks

Challenges in the design of Distributed Systems 1. Heterogeneity of underlying network infrastructure, computer hardware- and software (e.g., operating systems, compare UNIX socket and Winsock calls), programming languages (in particular, data representations). Some approaches Middleware (e.g., CORBA): transparency of network, hard- and software and programming language heterogeneity Mobile Code (e.g., JAVA): transparency from hard-, software and programming language heterogeneity through virtual machine concept. 2. Openness Ensure extensibility and maintainability of systems Adherence to standard interfaces 3. Security Privacy Authentication Availability 4. Handling of failures Detection (may be impossible) Masking retransmission and redundancy of data storage Tolerance - exception handling 5. Concurrency Consistent scheduling of concurrent threads (so that dependencies are preserved, e.g., in concurrent transactions) Avoidance of dead- and lifelock problems 6. Transparency: concealing the heterogeneous and distributed nature of the system so that it appears to the user like one system.

ARCHITECTURE MODELS How are responsibilities distributed between system components and how are these components placed? Client-server model Peer-to-peer Variations of the above two: Proxy server Mobile code Mobile agents Network computers Thin clients Mobile devices Client - Server The system is structured as a set of processes, called servers, that offer services to the users, called clients. The client-server model is usually based on a simple request/reply protocol, implemented with send/receive primitives or using remote procedure calls (RPC) or remote method invocation (RMI): - the client sends a request (invocation) message to the server asking for some service; - the server does the work and returns a result (e.g. the data requested) or an error code if the work could not be performed. A server can itself request services from other servers; thus, in this new relation, the server itself acts like a client. Some problems with client-server: Centralisation of service = poor scaling - Limitations: capacity of server bandwidth of network connecting the server

Peer-to-Peer All processes (objects) play similar role. Processes (objects) interact without particular distinction between clients and servers. The pattern of communication depends on the particular application. A large number of data objects are shared; any individual computer holds only a small part of the application database. Processing and communication loads for access to objects are distributed across many computers and access links. Peer-to-Peer tries to solve client server problem by It distributes shared resources widely and share computing and communication loads. Problems with peer-to-peer: High complexity due to - cleverly place individual objects - retrieve the objects - maintain potentially large number of replicas.

Fundamental Models Description of properties that are present in all distributed architectures. Interaction Models Issues dealing with the interaction of process such as performance and timing of events. Failure Models Specification of faults that can be exhibited by processes and communication channels. Security Models Threats to processes and communication channels INTERACTION MODELS Issues dealing with the interaction of process such as performance and timing of events. Interaction Model Challenges Distributed systems are composed of cooperating processes: Generally unpredictable timing and rate of message transmission delivery between processes. Processes maintain their own private state. There is no single global notion of time. Performance Considerations Latency delay between the transmission start of a message and its receipt. Time taken by the actual message transmission will vary with load of message traffic and time required by OS services to process messages. Bandwidth amount of information that can be transmitted over a computer network in a given amount of time. Two Interaction Model synchronous systems: known lower and upper time bound for each execution step, for each message transmission, and for the clock drift consequence: can introduce a pulsed execution system practically difcult to build, may help in simplifying analysis Ineffective resource sharing asynchronous systems: messages can arrive and be sent at any time event ordering: can usually assume no relative order of reception wrt. sending of messages

 exception: messages sent on an order-preserving channel More opportunity for resource sharing, but much more complex design.

Failure Model Specification of faults that can be exhibited by processes and communication channels. Omission Failures: process or channels fails to perform an operation process omission failure (e.g. crash failure) Process halted (crashed) and will not execute any further. Fail-stop if other processes can detect this state. fail-stop: other processes can detect crash (requires guaranteed delivery of messages) communication omission failures (message drop) Communication messages are dropped between sender and receiver (sender buffer, receiver buffer or communication channel) Arbitrary Failures (Byzantine failure): anything may happen Absence of process and communication omission failures, but integrity of data or processing steps is in error and undetectable by other processes. Timing Failures: synchronous system: activities not completed within pulse real-time systems: activity not completed within promised time Masking Failures A service masks a failure by hiding it or converting it into a more acceptable type of failure. System is said to be fault tolerant Examples -checksums, message retransmission, redundant servers Reliable communication (despite omission failures): Validity any message is eventually delivered Integrity message received is identical to message sent, and no messages are delivered twice

SECURITY MODEL Threats to processes and communication channels. securing processes and channels against unauthorized access protecting objects: access rights given to a principal assumption of an enemy (aka adversary), capable of (threat model) sending messages to any process reading and copying any message between a pair of process enemy may operate either legitimitely-connected node, or illegal node. Threat to processes: may receive messages sent by enemy may not be able to reliably determine identity of sender server: may not be able to identify principal client: may fall to "spoong" Threats to communication channels: enemy may copy, alter, inject, or delete messages gain information only intended for the communication partner Other threats: denial of service, trojan horses, ... Defeating security threats: cryptography, authentication, secure channels

LIMITATION OF DISTRIBUTED SYSTEM No global clock Due to unpredictable message delay, it is difficult to synchronize physical clocks Distributed schedule is difficult to implement No shared memory It is difficult to obtain a coherent global view, which includes local state and messages in transmission.