1 Basics PDF

A.Y.
2014/2015
4 / 96
Andrea Omicini (DISI, Univ. Bologna)
1 Introduction to Distributed Systems
A.Y. 2014/2015
From an engineering viewpoint, is a sort of a posteriori definition
5 / 96
We may also call it the computer scientist definition of a distributed

system
This is a possible definition, which accounts for an observational /

user-oriented view
Users view
. . . collection of independent computers that appears to its users as a

single coherent system [TvS07]
A distributed system is. . .
Definition of a Distributed System
Definitions
Sorts of Distributed Systems

Distributed Computing Systems
Distributed Information Systems
Distributed Pervasive Systems
Engineers view
Motivations & Goals

Motivations
Goals
Definitions
A.Y. 2014/2015
6 / 96
Need for coherence over multiplicity and heterogeneity
A.Y. 2014/2015
According to either the users view or the engineers viewor both
A distributed system can be seen as a single coherent system
Heterogeneity
7 / 96
No assumptions on their individual nature, structure, behaviour, . . .
Independent / autonomous computational entities (computers,

microprocessors, . . . )
A distributed system is made of a multiplicity of components
Definition of Distributed System: Some Remarks
From an engineering viewpoint, is a sort of a priori definition
We may also call it the computer engineer definition of a distributed

system
This is another possible definition, which accounts for a constructive,

design-oriented view
. . . a collection of autonomous computational entities conceived as a

single coherent system by its designer
Issues
Definitions
Distributed System: A Different Definition
Definitions
Outline
Definitions
Issues
A.Y. 2014/2015
A.Y. 2014/2015
Many heterogeneous entities should look altogether as a single

uniform system
Amalgamation
Many autonomous entities should work altogether as a single

coherent system
Collaboration
Main Issues of Distributed System
independent failures of components
lack of a global clock
concurrency of components
10 / 96
8 / 96
This definition leads to the following especially significant characteristics

of distributed systems:
Remark [CDKB12]
. . . one in which components located at networked computers

communicate and coordinate their actions only by passing messages.
Distributed System: Another Definition [CDKB12]
Definitions
Issues
A.Y. 2014/2015
Bad for looking for new ideas and new problems
Good for preserving good habits
A.Y. 2014/2015
Trying to extend the same old interpretation of systems
Moving from a view of non-distributed systems
An Architectural View of Distributed Systems: Remark
A distributed system organised as middleware. The middleware layer

extends over multiple machines, and offers each application the same
interface [TvS07]
An Architectural View of Distributed Systems
Issues
12 / 96
11 / 96
Motivations & Goals
Motivations
A.Y. 2014/2015
13 / 96
A.Y. 2014/2015
from centralised (single-processor) systems

to decentralised (multi-processor), distributed systems
The scope and goal of computer science changed dramatically
16 / 96
Microprocessor technology made computational entities more and

more powerful and cheap
High-speed computer networks made interconnection of
computational entities possible at a wide range of scales and speeds
Then drastic advances in Electronics and TLC occurred
Computer science as the art of computer programming was born upon

such machines
Computer were huge & expensive machines

Computer were islands
At the very beginning
What Made Computational Systems Distributed?
provides for a common shared interface for both applications and

componentslike, operating systems
The middleware layer hides differences in technology, structure,

behaviour, . . .
communication issues like syntax, semantics, . . .
Solution through separation

The middleware layer enables meaningful interaction between
autonomous distributed components
Collaboration & heterogeneity
Middleware: A Principled Solution
Issues
Motivations
Motivations & Goals
Goals
A.Y. 2014/2015
17 / 96
Promoting scalability
Promoting openness
A.Y. 2014/2015
19 / 96
Allowing distribution of resources to be hidden whenever unnecessary
Making (distributed, remote) resources available for use
Four goals for a distributed system
Making Distributed System Worth the Effort
why should we build a system as a distributed system?

it is not easy to make a distributed system actually work
However, at a first sight, distribution apparently introduces problems,

rather than solving them
and to be put together somehow
Hardware, software, and network components are easy to find & use
A distributed system is easy to build
Why Should We Build in a Distributed System?
Motivations & Goals
Goals
Motivations & Goals
Goals
A.Y. 2014/2015
By hiding non-relevant properties to users, distributed systems provide

users with a higher level of abstraction
21 / 96
A.Y. 2014/2015
Distributed systems should hide heterogeneity, by providing

uniform/homogeneous access to data, components, resources
23 / 96
Providing a homogeneous view over heterogeneity
There exists a number of different and useful sorts of transparency,

according to the property hidden to the users perception
22 / 96
All of them should be hidden from the users view, whenever possible &
non-relevant
Different resource usage interface / protocols
Different component structure
Different data representation
A.Y. 2014/2015
Hiding non-relevant properties of the systems components and

structure is called transparency
Transparency
A good reason to build a distributed system is to make physical

distribution irrelevant from the users viewpoint
Heterogeneity in representation and use
20 / 96
Physical distribution is not a feature, sometimes
Goals
A.Y. 2014/2015
Different forms of transparency in a distributed system (ISO, 1995)

[TvS07]
Access Transparency
Motivations & Goals
Goals
Types of Transparency in a Distributed System
Motivations & Goals
Distribution Transparency
By making interaction possible between users and resources, distributed

systems are enablers of sharing, information exchange, collaboration, . . .
E.g., printers, scanners, storage devices, distributed sensors, . . .
. . . anyone could legitimately use
. . . could be in any way connected to a computational system
Anything that . . .
What is a resource?
A good reason to build a distributed system is to make them

distributed resources available as they would belong to a single system
Resources are physically distributed
Making Resources Available
Motivations & Goals
Goals
Motivations & Goals
A.Y. 2014/2015
24 / 96
A.Y. 2014/2015
25 / 96
nowadays, users mobility is typically a core issue in the modelling and

engineering of artificial systems
some years ago this was a sort of secondary aspect
Also users might move
without losing functionality
without losing coherence
A distributed system should allow migration of resources
which has to maintain its coherence anyway
locations change within a distributed system
Resources might be mobile
Goals
Migration Transparency
e.g., URLs
There should exist a system of logical identifiers, not bound to

physical location
Naming is essential
Distributed systems should hide physical distribution, whenever

possible & non-relevant
Hiding physical distribution of users and resources
e.g., the position of a storage facility, or of a single printer in a cluster

of printers in a lab
Often, the physical location of a resource is not relevant for its use by
the usersand, viceversa, the location of users is often irrelevant for
the resource
Location of users and resources
Location Transparency
Motivations & Goals
Goals
Motivations & Goals
A.Y. 2014/2015
26 / 96
through redundancy
in promoting tolerance to failures
reduce bandwidth consumption

provide faster access
A.Y. 2014/2015
27 / 96
Like, for instance,

in providing a local copy of a resource to local agents/usersso as to
Sometimes replication helps
Goals
Replication Transparency I
Distributed systems could be useful to allow access to mobile resources by

mobile users, by hiding changes in location (migration transparency), even
while changes are actually occurring (relocation transparency).
Relocation transparency in some sense is a specialised version of

migration transparency
Migration should not prevent users to access resources, while they are
changing their location
Resources should be still accessible when moving
Relocation Transparency
Motivations & Goals
Goals
Motivations & Goals
A.Y. 2014/2015
29 / 96
As usual, transparently to the users
Typically, no user need to be bothered with these factslike,

another user is accessing the same database you are accessing just
now, who cares?
A.Y. 2014/2015
31 / 96
A distributed systems should take care of allowing transparent concurrent

access to resources, while ensuring consistency of resources.
A distributed system should take care of ensuring resource safety even

under concurrent accesses
For instance, two users may try to exploit the same resource at the
same time
30 / 96
When many users access the same resource concurrently, consistency

of its state is in jeopardybut should be ensured anyway
A.Y. 2014/2015
Users and resources are distributed, and work autonomously , in a

concurrent way
Goals
The problem of consistency
28 / 96
Activity in a distributed systems involves independent entities
Goals
A.Y. 2014/2015
Possibly, transparently to the users
A distributed system could take care of this, by defining access

policies governing concurrent sharing of resources
While shared access to resources could be done cooperatively, it is

often the case that users should access competitively to resources
Concurrency & Consistency
Motivations & Goals
Goals
Concurrency in activities should be hidden to users
Concurrency Transparency II
Motivations & Goals
Concurrency Transparency I
Distributed systems could exploit replication techniques for many reasons,

but should at the same time be able to hide it to users.
and should be essentially in the same state, so to be apparently one

and the same thing for each and every user
so they should have the same name
all replicas should be accessible in the same, transparent way
. . . replication is not something a user should worry about
Whatever the motivation behind replication . . .
Replication Transparency II
Motivations & Goals
Goals
Motivations & Goals
A.Y. 2014/2015
32 / 96
A.Y. 2014/2015
33 / 96
Distributed systems should exploit distribution to reduce the impact of

partial failure onto the overall system, hiding failures to users as much and
often as possible.
how do we distinguish between a dead resource and a very slow one?

Is silence from a resource originated by slowness, deliberate choice,
resource failure, or network failure?
E.g., the problem of latency
Being failure transparent is a hard problem
Hiding failure of resources to users
Masking failures under realistic assumptions
What does this mean?
Goals
Failure Transparency
Distribution should work as a feature.
Distributed failure is hard to control

Partial failure is possible, and much better than total failure of
centralised systems
Distribution might be either a source of problems or a blessing

It means that a failure could occur anywhere, but also that a part of
the system is likely keep on working
You know you have [a distributed system] when the crash of a

computer youve never heard of stops you from getting any work
done. (L. Lamport)
Failure in a distributed system is essentially a failure somewhere
Failure in Distributed Systems
Motivations & Goals
Goals
Motivations & Goals
Goals
A.Y. 2014/2015
34 / 96
A.Y. 2014/2015
35 / 96
Every engineer should find out the precise degree of transparency its
distributed system should feature, by taking into account other issues
like performance, understandability, . . .
Location-awareness is often a feature
It typically concerns performance, but is not limited to this
Trade-off between transparency and information
Degree of Transparency in a Distributed System II
Also, you should know that a file server is located in Italy or in Japan
when choosing from where you will download the nth
250-zillion-of-orribytes patch for your Windows operating system from
home
For instance, users may move and be subject to different time

zonesthis could lead to funny situations, if hidden
Hiding distribution is not always the best idea
Degree of Transparency in a Distributed System I
Motivations & Goals
Goals
Motivations & Goals
A.Y. 2014/2015
A.Y. 2014/2015
They capture syntax, rather than semanticsoften, they do not

specify the protocol, too
IDL (Interface Definition Languages) to define how interfaces are

specified
Interfaces to specify syntax for accessing services
Goals
Interfaces for Open Systems
Like, standard rules for services syntax and semantics, message

interchange, . . .
37 / 96
36 / 96
Something needs to be a priori shared between the system and the

(potential) components
Designing over unpredictability requires predictable items
Open systems are typically designed to be open
Open systems are fundamentally unpredictable
Essentially, the property of working with a number and sort of

components that is not set once and for all at design time
What is openness?
Openness
Motivations & Goals
Goals
Motivations & Goals
Goals
A.Y. 2014/2015
A.Y. 2014/2015
Separation between mechanisms and policies should be enforced
Policies should be either encapsulated into other components or

delegated to users
Mechanisms should be neutral, and open to different policy

specifications
Components providing mechanisms should not impose policies
Internal specifications should be as neat as the external ones
Components should be small and focussed enough to be easily

modified / replaced
External interfaces are not enough
Openness mandates for a clean architecture
Separating Policy from Mechanism
39 / 96
38 / 96
Extensibility measures how easy / difficult is to add new components

and functionality to an existing distributed system
Extensibility
Portability measures how much an application (or, a portion of it) can

be moved to a different distributed system and keep working
Portability
Interoperability measures how easy / difficult is to make one

component / system work with different ones based on some
standard-based specifications
Interoperability
Issues for Open Systems
Motivations & Goals
Goals
Motivations & Goals
Goals
A.Y. 2014/2015
Examples of scalability limitations [TvS07]
A.Y. 2014/2015
Scalability Problems: Scaling with Respect to Size
A system might scale up when it spans over a growing number of

distinct administrative domains
41 / 96
40 / 96
A system might scale up when the geographical distribution of users

and resources extends
A system might scale up when the number of users and resources

grows
Dimensions of scalability [Neu94]
There, size might mean actual size in number of components, but

also in geographical distribution
Often, few realistic assumptions can be done on the actual size of a

distributed system at design time
World-wide scale changes everything
Scalability
Motivations & Goals
Goals
Motivations & Goals
Goals
A.Y. 2014/2015
42 / 96
A.Y. 2014/2015
43 / 96
Only decentralised algorithms should be used in distributed systems
Any transmission problem would cause problems to the overall

algorithm
The network would be overloaded
Data should flow from the whole network to and from the place
where the centralised algorithm works
The trouble with centralised algorithms
Decentralised vs. Centralised Algorithms I
However, centralisation hinder scalability , and should be avoided in

general in distributed systems whenever possible
Sometimes, the most efficient algorithm from a theoretical viewpoint

might be a centralised one
Even though a single collection of data is a bottleneck, it could still

be needed if replication is insecure
Even though a single server is a bottleneck, it could be a necessity in

case of security problems, or, normative requirements
Making things centralised might be necessary
Centralisation
Motivations & Goals
Goals
Motivations & Goals
Goals
A.Y. 2014/2015
44 / 96
Centralisation is still a mess
Shared troubles with size scalability
A.Y. 2014/2015
45 / 96
Communication in WAN is typically unreliable, and typically

point-to-pointLAN broadcasting no longer an option: e.g., how do I
locate a service?
Communication in LAN is typically synchronousthis does not scale

up to WAN: e.g., how do I set up timeouts?
The trouble with communication
Scalability Problems: Geographical Scalability I
There is no implicit assumption that a global clock exists
Failure of one machine does not ruin the algorithm
Machines make decisions based only on local information
No machine has complete information about the system state
Characteristics of decentralised algorithms
Decentralised vs. Centralised Algorithms II
Motivations & Goals
Goals
Motivations & Goals
Goals
Replication
Distribution
asynchronous communication
Hiding communication latency
Three Basic Techniques [Neu94]
Techniques for Geographical Scalability
A.Y. 2014/2015
A.Y. 2014/2015
security measures are needed that may hinder scalability

policies may conflict
47 / 96
46 / 96
E.g.: within a single domain, users and components might be trusted:

however, trust does not cross domain boundaries
Distributed systems typically extend over multiple administration /
organisation domains
Administration / organisation troubles
Scalability Problems: Geographical Scalability II
Motivations & Goals
Goals
Motivations & Goals
Goals
A.Y. 2014/2015
48 / 96
A.Y. 2014/2015
49 / 96
alternative techniques like shipping code are needede.g., Javascript

or Java Applets
like in Web application when a user is just waiting for the response
Sometimes, asynchronous communication is not feasible
Problem
Scaling Techniques: Hiding Communication Latency II
when a response come in, the application is interrupted and a handler

is called to complete the request
the application does not stop waiting for a response
a request is sent by the application
This basically means using asynchronous communication for requests

whenever possible
Asynchronous communication
Try to avoid wasting time waiting for remote responses to service requests
whenever possible
The basic idea
Scaling Techniques: Hiding Communication Latency I
Motivations & Goals
Goals
Motivations & Goals
Goals
A.Y. 2014/2015
50 / 96
A.Y. 2014/2015
the naming service is thus distributed across several machines,

without centralisation
e.g., apice.unibo.it
the names in each zone are in charge of a single server
domains are divided in non-overlapping zones
the DNS is hierarchically organised into a tree of domains
Example: The Domain Name System (DNS)
51 / 96
Taking a component, splitting it into parts, and spreading the parts across
the system
The basic idea
Scaling Techniques: Distribution
The difference between letting (a) a server or (b) a client check forms as
they are being filled [TvS07]
Scaling Techniques: Code Shipping Example
Motivations & Goals
Goals
Motivations & Goals
Goals
A.Y. 2014/2015
A.Y. 2014/2015
53 / 96
A.Y. 2014/2015
55 / 96
sometimes, personal interactions within an organisation are the only

way to overcame a pseudo-technical problem
however, caching is a decision by the client of a resource, replication

by the owner of a resource
not every organisation problem has a technical solution
A recommendation for computer scientists & engineers
only a partial solution, nevertheless, something should be done
users take over control: peer-to-peer technologies
A successful approach: Ignoring administrative domains
maybe the most difficult problem: many non-technical problems to be

solved, such as policy of organisation and human collaboration
54 / 96
caching is making a copy of a resource, like replication
is a special form of replication
Caching
Replication typically involves making a copy of a resource form the

original location to a location in the proximity of the (potential) users
When degradation of performance occurs, replicating components

across a distributed system may increase availability and solve
problems of latency
The trouble with organisation
52 / 96
The basic idea
Goals
A.Y. 2014/2015
the point is how much inconsistency could a system tolerate, and how
it could be hidden from users and components of a distributed system
inconsistency is technically unavoidable, whenever copying a resource

in a distributed setting
involving both caching and replication
Scalability Problems: Administrative Scalability
Motivations & Goals
Goals
Duplicating a resource introduces consistency problems
The Problem of Consistency
Motivations & Goals
Scaling Techniques: Replication
An example of dividing the DNS space into zones [TvS07]
Scaling Techniques: Distribution Example
Motivations & Goals
Goals
Motivations & Goals
Goals
A.Y. 2014/2015
56 / 96
A.Y. 2014/2015
57 / 96
When engineering non-distributed systems, such problems are likely not to

show up.
administrative domains
transport costs
bandwidth
latency
topology of the network
heterogeneity of the network
security of the network
reliability of the network
Such (false) assumptions relate to properties unique to distributed

systems
Pitfalls of Distributed Systems: Remarks
These false assumptions typically produces all mistakes in the engineering

of distributed systems
There is one administrator
Transport cost is zero
Bandwidth is infinite
Latency is zero
The topology does not change
The network is homogeneous
The network is secure
The network is reliable
False assumptions made by first time developer (by Peter Deutsch)
Pitfalls of Distributed Systems
Motivations & Goals
A.Y. 2014/2015
Grid Computing Systems
Cluster Computing Systems
Two classes
A.Y. 2014/2015
Using a multiplicity of distributed computers to perform

high-performance tasks
The main characteristic
Three Classes of Distributed Systems
61 / 96
59 / 96
A.Y. 2014/2015
62 / 96
A.Y. 2014/2015
63 / 96
Typically, a single computationally-intensive program is run in parallel

on multiple machines
Parallel programming
Usage
Cluster Computing Systems II
Also, robustness is higher, maintenance and incremental addition of

computing power is easier
The ever increasing price / performance ration of computers makes it

cheaper to build a supercomputer by putting together many simple
computers, rather than buying a high-performance one
Motivation
interconnected through a high-speed LAN
located in the same area
running the same OS
A collection of similar workstations / PCs
The basic idea
Cluster Computing Systems I
A.Y. 2014/2015
A.Y. 2014/2015
Grid computer systems instead are typically heterogeneous
In essence, cluster computer systems are homogeneous
computers in a cluster are typically similar

computers in a cluster have the same OS
computers in a cluster are connected to the same (local) network
Homogeneity
Homogeneity vs. heterogeneity
Cluster vs. Grid Computing Systems
[TvS07]
Each cluster is a collection of computing nodes controlled and

accessed by a single master node
Linux-based
Beowulf clusters
An Example of Cluster Computing Systems
65 / 96
64 / 96
A.Y. 2014/2015
66 / 96
A.Y. 2014/2015
Application layer applications operating in the virtual organisation
Collective layer handling access to multiple resourcesresource

discovery, allocation, . . .
67 / 96
Connectivity layer communication protocols for grid transactions

spanning over multiple resources, plus security protocols for
authentication
Resource layer management of single resourcese.g., access control
Fabric layer interface to local resources at a specific site
A layered architecture for a grid computing system [FKT01]
Architecture of a Grid Computing System I
By their very nature, grid computer systems deal with different

administrative domains
essentially, a new virtual organisational entity including people from

existing organisations
accessing resources made available by participating organisations
including servers, databases, hard disks, . . .
Resources from different organisations are brought together to

promote collaboration between individuals, groups, or institutions, by
passing organisation boundaries
Collaboration is built in the form of a virtual organisation
The main idea
Grid Computing Systems
A.Y. 2014/2015
68 / 96
A.Y. 2014/2015
Altogether, they provide uniform access to otherwise dispersed

resources
69 / 96
The core of a grid middeleware layer is represented by connectivity,

resource, and collective layers
Grid middleware layer
Architecture of a Grid Computing System III
[TvS07]
Architecture of a Grid Computing System II
A.Y. 2014/2015
71 / 96
A.Y. 2014/2015
Durable Once a transaction commits, its effects are permanent
Isolated Concurrent transactions do not interfere with each other
Consistent the transaction does not violate system invariants
Atomic the transaction occurs invisibly to the outside world
ACID properties
72 / 96
Special primitives from the distributed system or the runtime system
When databases are distributed, transactions should be distributed
Operations on databases are usually performed in terms of

transactions
Distributed transactions for distributed databases
Transaction Processing Systems
Enterprise Application Integration (EAI)
Several sophisticated applications not only databases, but also

processing components requiring to directly communicate with each
other
Transaction Processing Systems
Several non-interoperating servers shared by a number of clients:

distributed queries, distributed transactions
Sorts
Structural problems of interoperability
Many separate networked applications to be integrated
Origin
A.Y. 2014/2015
Nesting in transactions could be arbitrarily deep
[TvS07]
A.Y. 2014/2015
A nested transaction is made of a number of subtransactions
Nested Transactions
[TvS07]
Example Primitives for Transactions
74 / 96
73 / 96
A.Y. 2014/2015
In any case, transactions are ACID
A.Y. 2014/2015
In case, the copy of the world transformed becomes the world
The effect of a successful nested transaction would be propagated

only after it succeeds
All transactions are performed over a copy of the data, so

subtransactions could keep ACIDity in the local world
Private copy of the world as a solution
The Problem with Nested Transactions II
Durability here refers to the top-level transaction
76 / 96
75 / 96
The effects of subtransactions could not be really durable if the whole

transanction does not succeed
So, if a subtransaction fails, all subtransactions till there should be

undone, even though they already committed
A whole nested transaction should exhibit ACID properties
Durability of nested and sub-transactions
The Problem with Nested Transactions I
TP Monitor
[TvS07]
with a transactional semantics
to allow applications to access multiple DB servers
Transaction processing monitor (or, TP monitor)
An early solution: TP monitor
Durability here refers to the top-level transaction
A.Y. 2014/2015
A.Y. 2014/2015
78 / 96
77 / 96
The effects of subtransactions could not be really durable if the whole

transanction does not succeed
Distributed transactions are nested transactions
Leaf subtransactions are usual transactions over single servers
Nested transactions are a natural way for distributing transactions
Nested Transactions in Distributed Information Systems
[TvS07]
Middleware as a Communication Facilitator
A.Y. 2014/2015
A.Y. 2014/2015
80 / 96
79 / 96
Application should interact and communicate meaningfully with each

other
Beyond data integration, process integration
Integration should happen at the application level, too
A.Y. 2014/2015
A.Y. 2014/2015
A distributed pervasive system generally lacks of a human

administrative control
A distributed pervasive system is part of our surroundings
Main features
Like, in modern distributed pervasive systems?
Like, with mobile devices with batteries and sporadic network

connection?
What happens when instability is the default condition?
Distributed Systems with Instability
Publish & Subscribe
MOM Message-Oriented Middleware
RMI Remote Method Invocation
RPC Remote Procedure Call
Different communication middeware support different sorts of

communication
It is not only a matter of accessing distributed databases
Sorts of Communication Middleware
Enterprise Application Integration
83 / 96
81 / 96
A.Y. 2014/2015
84 / 96
A.Y. 2014/2015
85 / 96
coming from heterogeneous sources from inside and outside the home
system
Huge amount of heterogeneous personal information to be managed,
Systems built around personal information
home systems should be self-configuring and self-maintaining in

essence
No way to ask people to act as a competent network / system

administrator
Systems built around home networks
Home Systems
Devices generally join the system in order to access (provide)

information: information should then be easy to read, store, manage,
and share
Many devices in pervasive system will be used in different ways by

different users
A device must be continually aware of the fact that its environment

may change at any time
Remarks
Recognise sharing as the default
Encourage ad hoc composition
Embrace contextual changes
Three points
Requirements for Pervasive Distributed Systems [GDL+ 04]
A.Y. 2014/2015
86 / 96
A.Y. 2014/2015
What are the security issues and how can the proper policies be
enforced?
87 / 96
How can extreme robustness of the monitoring system be realized?
How can physicians provide online feedback?
What infrastructure is needed to generate and propagate alerts?
How can we prevent loss of crucial data?
Where and how should monitored data be stored?
Health Care Systems: Questions to be Addressed
[TvS07]
Possibly, minimising impact on the personlike, preventing free

motion
Personal systems built around a Body Area Network
Health Care Systems
A.Y. 2014/2015
A.Y. 2014/2015
Architecture of Sensor Networks: Two Extremes I
Both solutions are bad ones, since they require either too much
network consumption, or too much node power consumption
89 / 96
88 / 96
Two possible extremes: either sensors just send information in without

cooperating, or they do all the computation and return the results
that can possibly be queried along time
Distributed sources of information
A possible view: distributed databases
Acquiring, processing and transmitting environmental information
Clouds of spatially distributed sensorsfrom tens to thousands of

nodes with a sensing device
An enabling technology for pervasive systems
Sensor Networks
A.Y. 2014/2015
90 / 96
What happens when network links fail?
A.Y. 2014/2015
How does aggregation of results take place? Can it be controlled?
91 / 96
How do we (dynamically) set up an efficient tree in a sensor network?
Questions to be addressed
Aggregating the results at the different levels of the tree
Passing queries through the sensor tree
Setting up a tree network among sensors
In-network data-processing
Sensor Networks: A Solution
[TvS07]
Architecture of Sensor Networks: Two Extremes II
Conclusions
A.Y. 2014/2015
92 / 96
A.Y. 2014/2015
93 / 96
Different models, methodologies and technologies are to be used to

design and develop different sorts of distributed systems
Depending on both the environment where they are developed, the

goals they have to achieve, and the level of the available technologies
Diverse sorts of distributed systems exist
Summing Up II
To account for them, a new discipline for system engineering is

required
When they are ignored, suddenly lead to severe problems
Distributed systems introduces / reveals new dimensions of

computational systems
Systems are inherently complex, nowadays, and distributed systems

may help hiding some complexity and improving understanding and
ease of use
Several problems, and several opportunities, too
There are good reasons to build up distributed systems
Summing Up I
Conclusions

1 Basics PDF

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

1 Basics PDF

Transféré par

Droits d'auteur :

Formats disponibles

A.Y.

Andrea Omicini (DISI, Univ. Bologna)

1 Introduction to Distributed Systems

From an engineering viewpoint, is a sort of a posteriori definition

We may also call it the computer scientist definition of a distributed

This is a possible definition, which accounts for an observational /

. . . collection of independent computers that appears to its users as a

A distributed system is. . .

Definition of a Distributed System

1 Introduction to Distributed Systems

Sorts of Distributed Systems

Andrea Omicini (DISI, Univ. Bologna)

Motivations & Goals

1 Introduction to Distributed Systems

Andrea Omicini (DISI, Univ. Bologna)

1 Introduction to Distributed Systems

Need for coherence over multiplicity and heterogeneity

According to either the users view or the engineers viewor both

A distributed system can be seen as a single coherent system

No assumptions on their individual nature, structure, behaviour, . . .

Independent / autonomous computational entities (computers,

A distributed system is made of a multiplicity of components

Definition of Distributed System: Some Remarks

Andrea Omicini (DISI, Univ. Bologna)

From an engineering viewpoint, is a sort of a priori definition

We may also call it the computer engineer definition of a distributed

This is another possible definition, which accounts for a constructive,

. . . a collection of autonomous computational entities conceived as a

A distributed system is. . .

Distributed System: A Different Definition

1 Introduction to Distributed Systems

Andrea Omicini (DISI, Univ. Bologna)

1 Introduction to Distributed Systems

Many heterogeneous entities should look altogether as a single

Many autonomous entities should work altogether as a single

Main Issues of Distributed System

Andrea Omicini (DISI, Univ. Bologna)

independent failures of components

lack of a global clock

This definition leads to the following especially significant characteristics

. . . one in which components located at networked computers

A distributed system is. . .

Distributed System: Another Definition [CDKB12]

1 Introduction to Distributed Systems

Andrea Omicini (DISI, Univ. Bologna)

1 Introduction to Distributed Systems

Bad for looking for new ideas and new problems

Good for preserving good habits

Trying to extend the same old interpretation of systems

Moving from a view of non-distributed systems

An Architectural View of Distributed Systems: Remark

Andrea Omicini (DISI, Univ. Bologna)

A distributed system organised as middleware. The middleware layer

An Architectural View of Distributed Systems

Motivations & Goals

1 Introduction to Distributed Systems

Andrea Omicini (DISI, Univ. Bologna)

1 Introduction to Distributed Systems

from centralised (single-processor) systems

The scope and goal of computer science changed dramatically

Microprocessor technology made computational entities more and

Then drastic advances in Electronics and TLC occurred