Docent: Vincent Naessens

addictedswimmingAI and Robotics

Oct 24, 2013 (3 years and 10 months ago)

106 views

Docent
: Vincent Naessens




1.1. Definition of distributed system

`
1.2. Goals

`
1.3. Types of distributed systems



A distributed system is a collection of
independent computers
that appears to its
users as a
single coherent system


When building a distributed system?


Making resources accessible


Distribution transparency


Openness


Scalability




Examples are printers, computers, files, ...


Why sharing resources?


Economical reasons


Enabling collaboration (by means of groupware)


Collaborative editing


Teleconferencing systems


...


New problems with increased connectivity


Security and privacy problems


Unwanted communication (junk mail...)






Limits to degree of transparency offered to
users:


Requesting digital newspaper at 7 A.M. at the other side of the world


Attempting to mask a transient server failure without performance loss


Updating replica’s without performance loss


Distribution exposure is essential in context
aware services


Printing jobs on a nearby printer instead of a free printer

transparency

performance

comprehensibility


Offering services according to standard rules


Standaard rules for
syntax

and
semantics


Service specification (i.e.
s
yntax) through interfaces


IDL = Interface Definition Language

x
IDL captures the syntax of services


Semantics in natural language



Interoperability


Extent by which two implementations of the same interface
can work together


Portability


Extent to which SW components can work on multiple
implementations of the same IDL


Extensibility


Extent to which new components can be added to a system



What interfaces should be supported:


Interfaces seen to users and applications


Internal interfaces


Allows to build new components and plug them in


Example
: new caching strategy/component


3 dimensions of scalability


SIZE
: adding resources and users


LOCATION
: distance between resources/users


ADMINISTRATION
: manageable in complex settings


Scalability often leads to performance loss


reason
: centralisation does not work anymore


Characteristics of decentralized algorithms:

1.
No machine has complete
info
about the system state.

2.
Machines make decisions based only on local
info.

3.
Failure of one machine does not ruin the algorithm.

4.
No
global clock exists
.



Geographic scalability problems (LAN


WAN)

1.
Communication delays

2.
Broadcasting technique can no longer be used



Administrative scalability problems

1.
Conflicting policies related to payment, security...







Scalability problems caused by:


Limited capacities of servers


Limited capacities of networks



Three techniques for scalability


Replication


Hiding communication latencies


distribution


Hiding communication latencies

1.
Avoid waiting during remote service requests


TECH_1: Synchronous comm.


Asynchronous comm.


Interrupt handling routines


TECH_2: Creating a seperate thread

2.
Moving compution to the clients


done by
Javascript

and
Java applets


Example
:

see next slide




Hiding communication latencies


Distribution


Splitting a component in smaller parts


Spreading the parts across the system


Example
:
Internet Domain Name System (DNS)


Replication


GOAL_1: increasing availability


GOAL_2: increasing performance


Caching is special form of replication


Copy in proximity of the client






May lead to
consistency

problems


SOLUTION: Global synchronisation strategies



Caching

Replication

when?

On

demand

In advance

Who?

Requester

of data

Owner of data


False assumptions made by first time
developer:

1.
The network is reliable.

2.
The network is secure.

3.
The network is homogeneous.

4.
The topology does not change.

5.
Latency is zero.

6.
Bandwidth is infinite.

7.
Transport cost is zero.

8.
There is one administrator.



Distributed Computing Systems

Cluster Computing systems
-

homogeneous


Distributed Computing Systems




Different operating systems


Different admin. domains


Different networks


...

Grid Computing systems
-

heterogeneous

Creation of
virtual organisations

to fulfill tasks tasks (leads to
service oriented architectures)

MIDDLEWARE


Distributed Information Systems



Distributed transactions


client retrieves info from multiple servers in 1 request



Enterprise Application Integration (EAI)


Applications really communicate/collaborate



Distributed Information Systems

Transaction Processing Systems


Distributed Information Systems




ACID properties
of transactions:


Atomic
:
the
transaction happens
indivisibly


Consistent
:
the
transaction
holds system invariants


Isolated
: Concurrent transactions do not
interfere


Durable
: Once a transaction commits, the changes are
permanent.


Transaction Processing Systems


Distributed Information Systems



Transaction Processing Systems


Distributed Information Systems




Support for nested transactions: TP Monitor


Transaction Processing Systems


Distributed Information Systems




TP monitors are applications


Need to enable communication between applications


“interapplication communication”




Enterprise Application Integration


Distributed Information Systems




Examples:


RPC: doing local procedure call to remote procedure


RMI: doing local method call to remote object


Message
-
oriented middleware (MOM)


Solves reference problems


Solves “up
-
and
-
running” problems


PUBLISH/SUBSCRIBE systems



Enterprise Application Integration


Distributed Pervasive Systems


Mobile and embedded devices lead to instability


Requirements for pervasive
systems

1.
Embrace
contextual
changes


EX: Absence/presence of network connection

2.
Encourage ad hoc
composition


EX: used by different individuals

3.
Recognize sharing as the default.



Distributed Pervasive Systems




Where and how should monitored data be stored?


How can we prevent loss of crucial data?


What infrastructure is needed to generate and propagate
alerts?


How can physicians provide online feedback?


How can extreme robustness of the monitoring system
be realized?


What are the security issues and how can the proper
policies be enforced?


Example 1: ELECTRONIC HEALTH SYSTEMS


Distributed Pervasive Systems



Example 1: ELECTRONIC HEALTH SYSTEMS


Distributed Pervasive Systems




How do we (dynamically) set up an efficient tree in a
sensor network?


How does aggregation of results take place?


Can
it be controlled?


What happens when network links fail?




Example 2: SENSOR NETWORKS


Distributed Pervasive Systems





Example 2: SENSOR NETWORKS





2.1. Architectural styles

`
2.2. System architectures

`
2.3. Archictectures versus middleware


An architectural style consists of


Software components: modular


can be replaced


Connectors: mediate comm./coord./coop.


Four major architectural styles:

1)
Layered architectures

2)
Object
-
based architectures

3)
Data
-
centered architectures

o
Communication
between processes
through
a common
repository (such
as a distributed file system)

4)
Event
-
based architectures (publish/subscribe)

o
Shared data spaces (combination of event
-
based and
data
-
centered)


EX: client/server model

EX: networking community

Propagation of events

(only processes that subscribe

to events will handle them)



Referential decoupling

Both components do not to be

active simultaneously



Decoupling in time


Types of system architectures


Centralized architectures


Decentralized architectures


Hybrid architectures


Simple client server system


LAN: connectionless


In case of reliable network


If requests are idempotent


WAN: connections


TCP/IP


Application Layering

The simplified organization of an
Internet search engine into three
different layers.


Multitiered Architectures



Two tier architectures


A
client machine containing only the programs
implementing (part of) the user
-
interface level


A server machine containing the
rest

(the
programs
implementing the processing and data
level)



Three tier architectures




Two tier Architectures




Thin clients/terminals

Remote data repres.

Correctness

checks in forms

at client side

Banking

application

Local

caching

Fat clients


Three tier Architectures





Vertical distribution
(previous slides)


1 machine per layer (or couple of layers)


Centralized architectures



Horizontal distribution
(next slides)


distributing clients and servers


Peer
-
to
-
peer systems


Peers act as client and server


servents


Decentralized architectures


Concept over
overlay network


Refers to communication links


Structured peer
-
to
-
peer systems


Basics: distributed hash table


Large identifier space (128 bit or 160 bit)



Each node gets an identifier


Each data item gets an identifier


LOOKUP(data_item)
returns
network_address_of_node


Nodes keep list of id’s of other nodes


Example 1
: Chord system


LOOKUP(k)

returns
network_address(succ(k))


Easy membership management


Example 2
: Content Addressable Network (CAN)


d
-
dimensional cartesian coordinate space


Easy node join


difficult node exit


Chord System


Content Addressable Network (CAN)


Unstructured peer
-
to
-
peer systems


Each node keeps a list of
c

neighbours


Partial view on the network


Each node will update partial view using 2 threads:


Active thread


Passive thread


Exchange c/2+1 entries


[address, age]


store newly receive entries


Based on
age

and
randomness


Data randomly stored in nodes


Flooding algoritm required when requesting an item





Unstructured peer
-
to
-
peer systems





Unstructured peer
-
to
-
peer systems





Topology management of overlay networks


Using ranking function that orders nodes based on
some criterium:


Distance to other node


Semantic proximityof data items stored at a peer





Superpeers


Why leaving symmetric nature of P2P systems?


Flooding becomes problematic


Collaborative content deliverry


characteristics


Long lived


High availability


Normal peers connect to superpeers


Select the best superpeer to connect to!





Superpeers



Edge
-
Server Systems


Internet can be seen as a collection of edge servers




BitTorrent



Middleware generally follows an arch. style


Example
: CORBA


Object
-
based arch. style


Tendency to seperate policy


mechanisms


Interceptors
: break the normal flow of control



Interceptors: example with remote method
invocations

Invocation to

a replicated object

Splitting messages

to enhance reliability


Basic techniques for adaptive software

1.
Separation of concerns


n
on
-
functional stuff in seperate modules


difficult for cross
-
cutting concerns (f.i. security)

2.
Computational reflection


SW inspects itsself and eventually adapts


Built
-
in in virtual machines

3.
Component
-
based design


Binding at late stage (i.e. at runtime)