CA464 Distributed Programming

Similar documents
Distributed Systems Principles and Paradigms. Chapter 01: Introduction

Distributed Systems Principles and Paradigms. Chapter 01: Introduction. Contents. Distributed System: Definition.

Distributed Systems Principles and Paradigms

Distributed Systems. Overview. Distributed Systems September A distributed system is a piece of software that ensures that:

DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN. Chapter 1. Introduction

DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN. Chapter 1. Introduction

Introduction. Distributed Systems IT332

Distributed Systems. Edited by. Ghada Ahmed, PhD. Fall (3rd Edition) Maarten van Steen and Tanenbaum

Distributed Systems. Chapter 1: Introduction

Advanced Distributed Systems

CSE 5306 Distributed Systems. Course Introduction

Chapter 1: Introduction 1/29

Outline. Definition of a Distributed System Goals of a Distributed System Types of Distributed Systems

Introduction to Distributed Systems. INF5040/9040 Autumn 2018 Lecturer: Eli Gjørven (ifi/uio)

Introduction Distributed Systems

Introduction to Distributed Systems (DS)

Distributed Information Processing

Chapter 1 Introduction

Introduction to Distributed Systems (DS)

Distributed System: Definition

Chapter 1: Distributed Systems: What is a distributed system? Fall 2013

What is a distributed system?

Concepts of Distributed Systems 2006/2007

DISTRIBUTED SYSTEMS. Second Edition. Andrew S. Tanenbaum Maarten Van Steen. Vrije Universiteit Amsterdam, 7'he Netherlands PEARSON.

Designing Issues For Distributed Computing System: An Empirical View

TDP3471 Distributed and Parallel Computing

Introduction to Distributed Systems

Distributed Systems COMP 212. Lecture 1 Othon Michail

Introduction to Distributed Systems

Distributed Operating Systems Spring Prashant Shenoy UMass Computer Science.

Distributed Systems. Lecture 4 Othon Michail COMP 212 1/27

Distributed Systems. Prof. Dr. Schahram Dustdar Distributed Systems Group Vienna University of Technology. dsg.tuwien.ac.

Introduction to Distributed Systems

CS655: Advanced Topics in Distributed Systems [Fall 2013] Dept. Of Computer Science, Colorado State University

Announcements. me your survey: See the Announcements page. Today. Reading. Take a break around 10:15am. Ack: Some figures are from Coulouris

Distributed Operating Systems Fall Prashant Shenoy UMass Computer Science. CS677: Distributed OS

Distributed Systems. Characteristics of Distributed Systems. Lecture Notes 1 Basic Concepts. Operating Systems. Anand Tripathi

Distributed Systems. Characteristics of Distributed Systems. Characteristics of Distributed Systems. Goals in Distributed System Designs

Distributed Systems Principles and Paradigms

Introduction to Distributed Systems

Chapter 8 Fault Tolerance

Distributed Systems COMP 212. Lecture 1 Othon Michail

Support for resource sharing Openness Concurrency Scalability Fault tolerance (reliability) Transparence. CS550: Advanced Operating Systems 2

It also performs many parallelization operations like, data loading and query processing.

Distributed Systems LEEC (2006/07 2º Sem.)

Introduction to Distributed Systems

Chapter 2 System Models

02 - Distributed Systems

Distributed Systems. Prof. Dr. Schahram Dustdar Distributed Systems Group Vienna University of Technology. dsg.tuwien.ac.

Distributed and Operating Systems Spring Prashant Shenoy UMass Computer Science.

Client Server & Distributed System. A Basic Introduction

Advanced Operating Systems

Outline. Distributed Computing Systems. The Rise of Distributed Systems. Depiction of a Distributed System 4/15/2014

THE IMPACT OF E-COMMERCE ON DEVELOPING A COURSE IN OPERATING SYSTEMS: AN INTERPRETIVE STUDY

02 - Distributed Systems

Distributed File Systems. CS432: Distributed Systems Spring 2017

Chapter 8 Fault Tolerance

Verteilte Systeme (Distributed Systems)

Ian Foster, CS554: Data-Intensive Computing

Distributed Systems Principles and Paradigms. Chapter 12: Distributed Web-Based Systems

Multiprocessors 2007/2008

Introduction. Chapter 1

Replication and Consistency. Fall 2010 Jussi Kangasharju

2.1 What are distributed systems? What are systems? Different kind of systems How to distribute systems? 2.2 Communication concepts

Introduction to Distributed Systems

Lecture 6 Consistency and Replication

System Models for Distributed Systems

Remote Procedure Call. Tom Anderson

Lecture 1: January 22

Distributed File Systems. CS 537 Lecture 15. Distributed File Systems. Transfer Model. Naming transparency 3/27/09

Introduction to Distributed Systems

MODELS OF DISTRIBUTED SYSTEMS

Basic vs. Reliable Multicast

Lecture 1: January 23

Distributed Systems COMP 212. Lecture 15 Othon Michail

Assignment 5. Georgia Koloniari

Distributed systems. Lecture 6: distributed transactions, elections, consensus and replication. Malte Schwarzkopf

Distributed Systems COMP 212. Lecture 1 Othon Michail

殷亚凤. Processes. Distributed Systems [3]

Chapter 10 DISTRIBUTED OBJECT-BASED SYSTEMS

Outline. INF3190:Distributed Systems - Examples. Last week: Definitions Transparencies Challenges&pitfalls Architecturalstyles

Chapter 17: Distributed Systems (DS)

Advanced Memory Management

PRIMARY-BACKUP REPLICATION

Lecture 9: MIMD Architectures

Replication in Distributed Systems

Datacenter replication solution with quasardb

Communication. Distributed Systems Santa Clara University 2016

Large Systems: Design + Implementation: Communication Coordination Replication. Image (c) Facebook

Chapter 2 Distributed Information Systems Architecture

Today: Fault Tolerance. Replica Management

DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN. Chapter 2 ARCHITECTURES

Chapter 4: Distributed Systems: Replication and Consistency. Fall 2013 Jussi Kangasharju

CS 454/654 Distributed Systems. Course Objective

5. Distributed Transactions. Distributed Systems Prof. Dr. Alexander Schill

Crossbar switch. Chapter 2: Concepts and Architectures. Traditional Computer Architecture. Computer System Architectures. Flynn Architectures (2)

Consistency & Replication

Distributed KIDS Labs 1

Distributed Systems [COMP9243] Session 1, 2018

Chapter 20: Database System Architectures

Transcription:

1 / 25 CA464 Distributed Programming Lecturer: Martin Crane Office: L2.51 Phone: 8974 Email: martin.crane@computing.dcu.ie WWW: http://www.computing.dcu.ie/ mcrane Course Page: "/CA464NewUpdate Textbook (Theory): Distributed Systems: Principles and Paradigms (Second Edition), Andrew S. Tanenbaum and Maarten Van Steen, Pearson, ISBN 0-13-613553-6 Textbook (Practice): Java Web Services: Up and Running, Martin Kalin, O Reilly, ISBN 978-0-596-52112-7

2 / 25 Introduction Distributed System: Definition Definition A distributed system is a piece of software that ensures that: a collection of independent computers appears to its users as a single coherent system Two aspects: (1) independent computers and (2) single system middleware. Computer 1 Computer 2 Computer 3 Computer 4 Appl. A Application B Appl. C Distributed system layer (middleware) Local OS 1 Local OS 2 Local OS 3 Local OS 4 Network

3 / 25 of Distributed Systems Making resources available Distribution transparency Openness Scalability

4 / 25 Distribution Transparency Transp. Access Location Migration Relocation Replication Concurrency Failure Description Hides differences in data representation and invocation mechanisms Hides where an object resides Hides from an object the ability of a system to change that object s location Hides from a client the ability of a system to change the location of an object to which the client is bound Hides the fact that an object or its state may be replicated and that replicas reside at different locations Hides the coordination of activities between objects to achieve consistency at a higher level Hides failure and possible recovery of objects Note Distribution transparency is a nice a goal, but achieving it is a different story.

4 / 25 Distribution Transparency Transp. Access Location Migration Relocation Replication Concurrency Failure Description Hides differences in data representation and invocation mechanisms Hides where an object resides Hides from an object the ability of a system to change that object s location Hides from a client the ability of a system to change the location of an object to which the client is bound Hides the fact that an object or its state may be replicated and that replicas reside at different locations Hides the coordination of activities between objects to achieve consistency at a higher level Hides failure and possible recovery of objects Note Distribution transparency is a nice a goal, but achieving it is a different story.

5 / 25 Degree of Transparency Aiming at full distribution transparency may be too much: Users may be located in different continents Completely hiding failures of networks and nodes is (theoretically and practically) impossible You cannot distinguish a slow computer from a failing one You can never be sure that a server actually performed an operation before a crash Full transparency will cost performance, exposing distribution of the system Keeping Web caches exactly up-to-date with the master Immediately flushing write operations to disk for fault tolerance

5 / 25 Degree of Transparency Aiming at full distribution transparency may be too much: Users may be located in different continents Completely hiding failures of networks and nodes is (theoretically and practically) impossible You cannot distinguish a slow computer from a failing one You can never be sure that a server actually performed an operation before a crash Full transparency will cost performance, exposing distribution of the system Keeping Web caches exactly up-to-date with the master Immediately flushing write operations to disk for fault tolerance

5 / 25 Degree of Transparency Aiming at full distribution transparency may be too much: Users may be located in different continents Completely hiding failures of networks and nodes is (theoretically and practically) impossible You cannot distinguish a slow computer from a failing one You can never be sure that a server actually performed an operation before a crash Full transparency will cost performance, exposing distribution of the system Keeping Web caches exactly up-to-date with the master Immediately flushing write operations to disk for fault tolerance

5 / 25 Degree of Transparency Aiming at full distribution transparency may be too much: Users may be located in different continents Completely hiding failures of networks and nodes is (theoretically and practically) impossible You cannot distinguish a slow computer from a failing one You can never be sure that a server actually performed an operation before a crash Full transparency will cost performance, exposing distribution of the system Keeping Web caches exactly up-to-date with the master Immediately flushing write operations to disk for fault tolerance

6 / 25 Openness of Distributed Systems Open distributed system Be able to interact with services from other open systems, irrespective of the underlying environment: Systems should conform to well-defined interfaces Systems should support portability of applications Systems should easily interoperate Achieving openness At least make the distributed system independent from heterogeneity of the underlying environment: Hardware Platforms Languages

6 / 25 Openness of Distributed Systems Open distributed system Be able to interact with services from other open systems, irrespective of the underlying environment: Systems should conform to well-defined interfaces Systems should support portability of applications Systems should easily interoperate Achieving openness At least make the distributed system independent from heterogeneity of the underlying environment: Hardware Platforms Languages

7 / 25 Policies versus Mechanisms Implementing openness Requires support for different policies: What level of consistency do we require for client-cached data? Which operations do we allow downloaded code to perform? Which QoS requirements do we adjust in the face of varying bandwidth? What level of secrecy do we require for communication? Implementing openness Ideally, a distributed system provides only mechanisms: Allow (dynamic) setting of caching policies Support different levels of trust for mobile code Provide adjustable QoS parameters per data stream Offer different encryption algorithms

7 / 25 Policies versus Mechanisms Implementing openness Requires support for different policies: What level of consistency do we require for client-cached data? Which operations do we allow downloaded code to perform? Which QoS requirements do we adjust in the face of varying bandwidth? What level of secrecy do we require for communication? Implementing openness Ideally, a distributed system provides only mechanisms: Allow (dynamic) setting of caching policies Support different levels of trust for mobile code Provide adjustable QoS parameters per data stream Offer different encryption algorithms

8 / 25 Scale in Distributed Systems Many developers of modern distributed system easily use the adjective scalable without making clear why their system actually scales. Scalability At least three components: Number of users and/or processes (size scalability) Maximum distance between nodes (geographical scalability) Number of administrative domains (administrative scalability) Most systems account only, to a certain extent, for size scalability. The (non)solution: powerful servers. Today, the challenge lies in geographical and administrative scalability.

8 / 25 Scale in Distributed Systems Many developers of modern distributed system easily use the adjective scalable without making clear why their system actually scales. Scalability At least three components: Number of users and/or processes (size scalability) Maximum distance between nodes (geographical scalability) Number of administrative domains (administrative scalability) Most systems account only, to a certain extent, for size scalability. The (non)solution: powerful servers. Today, the challenge lies in geographical and administrative scalability.

8 / 25 Scale in Distributed Systems Many developers of modern distributed system easily use the adjective scalable without making clear why their system actually scales. Scalability At least three components: Number of users and/or processes (size scalability) Maximum distance between nodes (geographical scalability) Number of administrative domains (administrative scalability) Most systems account only, to a certain extent, for size scalability. The (non)solution: powerful servers. Today, the challenge lies in geographical and administrative scalability.

Techniques for Scaling Hide communication latencies Avoid waiting for responses; do something else: Make use of asynchronous communication Have separate handler for incoming response Problem: not every application fits this model 9 / 25

Techniques for Scaling Distribution Partition data and computations across multiple machines: Move computations to clients (Java applets) Decentralized naming services (DNS) Decentralized information systems (WWW) 10 / 25

11 / 25 Techniques for Scaling Replication/caching Make copies of data available at different machines: Replicated file servers and databases Mirrored Web sites Web caches (in browsers and proxies) File caching (at server and client)

Scaling The Problem Applying scaling techniques is easy, except for one thing: Having multiple copies (cached or replicated), leads to inconsistencies: modifying one copy makes that copy different from the rest. Always keeping copies consistent and in a general way requires global synchronization on each modification. Global synchronization precludes large-scale solutions. If we can tolerate inconsistencies, we may reduce the need for global synchronization, but tolerating inconsistencies is application dependent. 12 / 25

Scaling The Problem Applying scaling techniques is easy, except for one thing: Having multiple copies (cached or replicated), leads to inconsistencies: modifying one copy makes that copy different from the rest. Always keeping copies consistent and in a general way requires global synchronization on each modification. Global synchronization precludes large-scale solutions. If we can tolerate inconsistencies, we may reduce the need for global synchronization, but tolerating inconsistencies is application dependent. 12 / 25

Scaling The Problem Applying scaling techniques is easy, except for one thing: Having multiple copies (cached or replicated), leads to inconsistencies: modifying one copy makes that copy different from the rest. Always keeping copies consistent and in a general way requires global synchronization on each modification. Global synchronization precludes large-scale solutions. If we can tolerate inconsistencies, we may reduce the need for global synchronization, but tolerating inconsistencies is application dependent. 12 / 25

Scaling The Problem Applying scaling techniques is easy, except for one thing: Having multiple copies (cached or replicated), leads to inconsistencies: modifying one copy makes that copy different from the rest. Always keeping copies consistent and in a general way requires global synchronization on each modification. Global synchronization precludes large-scale solutions. If we can tolerate inconsistencies, we may reduce the need for global synchronization, but tolerating inconsistencies is application dependent. 12 / 25

Scaling The Problem Applying scaling techniques is easy, except for one thing: Having multiple copies (cached or replicated), leads to inconsistencies: modifying one copy makes that copy different from the rest. Always keeping copies consistent and in a general way requires global synchronization on each modification. Global synchronization precludes large-scale solutions. If we can tolerate inconsistencies, we may reduce the need for global synchronization, but tolerating inconsistencies is application dependent. 12 / 25

Developing Distributed Systems: Pitfalls Many distributed systems are needlessly complex caused by mistakes that required patching later on. There are many false assumptions: The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator 13 / 25

Developing Distributed Systems: Pitfalls Many distributed systems are needlessly complex caused by mistakes that required patching later on. There are many false assumptions: The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator 13 / 25

Developing Distributed Systems: Pitfalls Many distributed systems are needlessly complex caused by mistakes that required patching later on. There are many false assumptions: The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator 13 / 25

Developing Distributed Systems: Pitfalls Many distributed systems are needlessly complex caused by mistakes that required patching later on. There are many false assumptions: The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator 13 / 25

Developing Distributed Systems: Pitfalls Many distributed systems are needlessly complex caused by mistakes that required patching later on. There are many false assumptions: The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator 13 / 25

Developing Distributed Systems: Pitfalls Many distributed systems are needlessly complex caused by mistakes that required patching later on. There are many false assumptions: The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator 13 / 25

Developing Distributed Systems: Pitfalls Many distributed systems are needlessly complex caused by mistakes that required patching later on. There are many false assumptions: The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator 13 / 25

Developing Distributed Systems: Pitfalls Many distributed systems are needlessly complex caused by mistakes that required patching later on. There are many false assumptions: The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator 13 / 25

Developing Distributed Systems: Pitfalls Many distributed systems are needlessly complex caused by mistakes that required patching later on. There are many false assumptions: The network is reliable The network is secure The network is homogeneous The topology does not change Latency is zero Bandwidth is infinite Transport cost is zero There is one administrator 13 / 25

Types of Distributed Systems 14 / 25 Types of Distributed Systems Distributed Computing Systems Distributed Information Systems Distributed Pervasive Systems

Types of Distributed Systems Distributed Computing Systems Many distributed systems are configured for High-Performance Computing Cluster Computing Essentially a group of high-end systems connected through a LAN: Homogeneous: same OS, near-identical hardware Single managing node 15 / 25

16 / 25 Introduction Distributed Computing Systems Types of Distributed Systems Master node Compute node Compute node Compute node Management application Parallel libs Component of parallel application Component of parallel application Component of parallel application Local OS Local OS Local OS Local OS Remote access network Standard network High-speed network

Types of Distributed Systems Distributed Computing Systems Grid Computing The next step: lots of nodes from everywhere: Heterogeneous Dispersed across several organizations Can easily span a wide-area network Note To allow for collaborations, grids generally use virtual organizations. In essence, this is a grouping of users (or better: their IDs) that will allow for authorization on resource allocation. 17 / 25

Types of Distributed Systems Distributed Information Systems The vast amount of distributed systems in use today are forms of traditional information systems, that now integrate legacy systems. Example: Transaction processing systems. BEGIN TRANSACTION(server, transaction) READ(transaction, file-1, data) WRITE(transaction, file-2, data) newdata := MODIFIED(data) IF WRONG(newData) THEN ABORT TRANSACTION(transaction) ELSE WRITE(transaction, file-2, newdata) END TRANSACTION(transaction) END IF 18 / 25

Types of Distributed Systems Distributed Information Systems The vast amount of distributed systems in use today are forms of traditional information systems, that now integrate legacy systems. Example: Transaction processing systems. BEGIN TRANSACTION(server, transaction) READ(transaction, file-1, data) WRITE(transaction, file-2, data) newdata := MODIFIED(data) IF WRONG(newData) THEN ABORT TRANSACTION(transaction) ELSE WRITE(transaction, file-2, newdata) END TRANSACTION(transaction) END IF Note Transactions form an atomic operation. 18 / 25

Types of Distributed Systems 19 / 25 Distributed Information Systems: Transactions Model A transaction is a collection of operations on the state of an object (database, object composition, etc.) that satisfies the following properties (ACID) Atomicity: All operations either succeed, or all of them fail. When the transaction fails, the state of the object will remain unaffected by the transaction. Consistency: A transaction establishes a valid state transition. This does not exclude the possibility of invalid, intermediate states during the transaction s execution. Isolation: Concurrent transactions do not interfere with each other. It appears to each transaction T that other transactions occur either before T, or after T, but never both. Durability: After the execution of a transaction, its effects are made permanent: changes to the state survive failures.

Types of Distributed Systems 19 / 25 Distributed Information Systems: Transactions Model A transaction is a collection of operations on the state of an object (database, object composition, etc.) that satisfies the following properties (ACID) Atomicity: All operations either succeed, or all of them fail. When the transaction fails, the state of the object will remain unaffected by the transaction. Consistency: A transaction establishes a valid state transition. This does not exclude the possibility of invalid, intermediate states during the transaction s execution. Isolation: Concurrent transactions do not interfere with each other. It appears to each transaction T that other transactions occur either before T, or after T, but never both. Durability: After the execution of a transaction, its effects are made permanent: changes to the state survive failures.

Types of Distributed Systems 19 / 25 Distributed Information Systems: Transactions Model A transaction is a collection of operations on the state of an object (database, object composition, etc.) that satisfies the following properties (ACID) Atomicity: All operations either succeed, or all of them fail. When the transaction fails, the state of the object will remain unaffected by the transaction. Consistency: A transaction establishes a valid state transition. This does not exclude the possibility of invalid, intermediate states during the transaction s execution. Isolation: Concurrent transactions do not interfere with each other. It appears to each transaction T that other transactions occur either before T, or after T, but never both. Durability: After the execution of a transaction, its effects are made permanent: changes to the state survive failures.

Types of Distributed Systems 19 / 25 Distributed Information Systems: Transactions Model A transaction is a collection of operations on the state of an object (database, object composition, etc.) that satisfies the following properties (ACID) Atomicity: All operations either succeed, or all of them fail. When the transaction fails, the state of the object will remain unaffected by the transaction. Consistency: A transaction establishes a valid state transition. This does not exclude the possibility of invalid, intermediate states during the transaction s execution. Isolation: Concurrent transactions do not interfere with each other. It appears to each transaction T that other transactions occur either before T, or after T, but never both. Durability: After the execution of a transaction, its effects are made permanent: changes to the state survive failures.

Types of Distributed Systems 19 / 25 Distributed Information Systems: Transactions Model A transaction is a collection of operations on the state of an object (database, object composition, etc.) that satisfies the following properties (ACID) Atomicity: All operations either succeed, or all of them fail. When the transaction fails, the state of the object will remain unaffected by the transaction. Consistency: A transaction establishes a valid state transition. This does not exclude the possibility of invalid, intermediate states during the transaction s execution. Isolation: Concurrent transactions do not interfere with each other. It appears to each transaction T that other transactions occur either before T, or after T, but never both. Durability: After the execution of a transaction, its effects are made permanent: changes to the state survive failures.

Types of Distributed Systems Transaction Processing Monitor In many cases, the data involved in a transaction is distributed across several servers. A TP Monitor is responsible for coordinating the execution of a transaction Server Reply Transaction Client application Requests Reply TP monitor Request Request Reply Request Server Reply Server 20 / 25

Types of Distributed Systems Distr. Info. Systems: Enterprise Application Integration Problem A TP monitor doesn t separate apps from their databases. Also needed are facilities for direct communication between apps. Client application Client application Communication middleware Server-side application Server-side application Server-side application Remote Procedure Call (RPC) Message-Oriented Middleware (MOM) 21 / 25

Types of Distributed Systems 22 / 25 Distributed Pervasive Systems Emerging next-generation of distributed systems in which nodes are small, mobile, and often embedded in a larger system. Some requirements Contextual change: The system is part of an environment in which changes should be immediately accounted for. Ad hoc composition: Each node may be used in a very different ways by different users. Requires ease-of-configuration. Sharing is the default: Nodes come and go, providing sharable services and information. Calls again for simplicity. Note Pervasiveness and distribution transparency: a good match?

Types of Distributed Systems 22 / 25 Distributed Pervasive Systems Emerging next-generation of distributed systems in which nodes are small, mobile, and often embedded in a larger system. Some requirements Contextual change: The system is part of an environment in which changes should be immediately accounted for. Ad hoc composition: Each node may be used in a very different ways by different users. Requires ease-of-configuration. Sharing is the default: Nodes come and go, providing sharable services and information. Calls again for simplicity. Note Pervasiveness and distribution transparency: a good match?

Types of Distributed Systems 23 / 25 Pervasive Systems: Examples Home Systems Should be completely self-organizing: There should be no system administrator Provide a personal space for each of its users Simplest solution: a centralized home box? Electronic health systems Devices are physically close to a person: Where and how should monitored data be stored? How can we prevent loss of crucial data? What is needed to generate and propagate alerts? How can security be enforced? How can physicians provide online feedback?

Types of Distributed Systems 23 / 25 Pervasive Systems: Examples Home Systems Should be completely self-organizing: There should be no system administrator Provide a personal space for each of its users Simplest solution: a centralized home box? Electronic health systems Devices are physically close to a person: Where and how should monitored data be stored? How can we prevent loss of crucial data? What is needed to generate and propagate alerts? How can security be enforced? How can physicians provide online feedback?

Types of Distributed Systems Sensor networks Characteristics The nodes to which sensors are attached are: Many (10s-1000s) Simple (small memory/compute/communication capacity) Often battery-powered (or even battery-less) 24 / 25

Types of Distributed Systems Sensor networks as distributed systems Sensor network Operator's site Sensor data is sent directly to operator (a) Operator's site Each sensor can process and store data Query Sensor network Sensors send only answers (b) 25 / 25