dati

Architetture
◆
1. Architetture tipiche
•
•
•
repository-based
client server
peer-to-peer
Gabriele Monfardini - Corso di Ingegneria del Software
1
1. Architetture tipiche
Differiscono fra loro per il modo in cui:
•
•
•
•
i dati vengono ripartiti
le risorse e le funzionalità/responsabilità vengono
distribuite
i sottosistemi si interfacciano e comunicano fra
loro
il controllo viene organizzato.
Gabriele Monfardini - Corso di Ingegneria del Software
2
1.1 – Architettura basata su repository
◆
In generale, i sottosistemi possono
condividere dati in due modi:
•
•
◆
Ciascun sottosistema mantiene un suo database, e
passa dati esplicitamente agli altri
I dati condivisi sono mantenuti in un database centrale,
o repository accessibile a tutti
L’architettura a repository è conveniente
quando devono essere condivise grandi
quantità di dati
• Esempi: CAD, CASE tools
Gabriele Monfardini - Corso di Ingegneria del Software
3
Esempio: architettura di un ambiente
CASE (Computer Aided Software
Engineering)
Design
editor
Design
translator
Code
generator
Project
repository
Design
analyser
Program
editor
Report
generator
Gabriele Monfardini - Corso di Ingegneria del Software
4
Caratteristiche della architettura a
repository
◆
Vantaggi
•
•
•
•
◆
Modo efficiente di condividere grandi moli di dati: write once for all to
read
Un sottosistema non si deve preoccupare di come i dati sono
prodotti/usati da ogni altro sottosistema
Gestione centralizzata di backup, security, access control, recovery da
errori...
Il modello di condivisione dati è pubblicato come repository schema
==> facile aggiungere nuovi sottosistemi
Svantaggi
•
•
•
•
I sottosistemi devono concordare su un modello dati di compromesso
==> minor performance
Data evolution: la adozione di un nuovo modello dati è difficile e costosa:
(a) esso deve venir applicato a tutto il repository, e (b) tutti i
sottosistemi devono essere aggiornati
Diversi sottosistemi possono avere diversi requisiti su backup, security…
Non supportati
E’ difficile distribuire efficientemente il repository su piu’ macchine
(continuando a vederlo come logicamente centralizzato): problemi di
ridondanza e consistenza dati.
Gabriele Monfardini - Corso di Ingegneria del Software
5
1.2 – Architettura Client-server
◆
E’ una architettura distribuita dove dati ed
elaborazione sono distribuiti su una rete di nodi di
due tipi:
•
•
I server sono processori potenti e dedicati: offrono servizi
specifici come stampa, gestione di file system,
compilazione, gestione traffico di rete, calcolo.
I clienti sono PC o workstation sui quali girano le
applicazioni-utente, che utilizzano i servizi dei server
(tramite remote procedure calls).
◆
I Clienti devono conoscere i nomi e la natura dei Server;
◆
I Server non devono conoscere identità e numero dei Clienti.
Gabriele Monfardini - Corso di Ingegneria del Software
6
Computers in rete locale
c1
CC1
c2
CC2
CC3
Network
s1, s2
c3, c4
s3, s4
Server
computer
SC1
SC2
c5, c6, c7
c8, c9
CC4
CC5
c10, c11, c12
Client
computer
CC6
Gabriele Monfardini - Corso di Ingegneria del Software
7
Client-server- Biblioteca elettronica di
foto e film
The client program is an integrated user-interface
to the services
Client 1
Client 2
Client 3
Client 4
Wide-bandwidth network
Catalogue
server
Video
server
Picture
server
Hypertext
server
Catalogue
Film clip
files
Digitiz ed
photographs
Hypertext
web
Providing links
to other servers
Transmit quickly,
in synchrony,
low resolution
High resolution,
no stringent timing
requirements
Gabriele Monfardini - Corso di Ingegneria del Software
(complementary
info)
8
Strati funzionali nell’architettura C/S
◆
Presentation layer
•
◆
Application processing layer
•
◆
Presentazione dei risultati
dell'elaborazione, raccolta input
Presentation layer
Funzionalità specifiche
dell'applicazione (in un sistema
bancario, ad es., apertura conti,
gestione titoli ecc...)
Application processing
layer
Data management layer
•
Amministrazione dei
dati/database
Data management
layer
Gabriele Monfardini - Corso di Ingegneria del Software
9
Architettura one-tier
◆
E' una architettura client/server nella
quale tutto gira su una singola macchina
•
•
Dal momento che l'applicazione è
centralizzata e funziona in un ambiente
noto e circoscritto, è facile da manutenere,
controllare ed è sicura riguardo all'accesso
improprio ai dati
Manca però di scalabilità, portabilità,
flessibilità
Gabriele Monfardini - Corso di Ingegneria del Software
10
Architettura two-tier
◆
E' una architettura client/server nella
quale l'interfaccia utente gira sul client
mentre il database ed i dati sono sul
server. La logica dell'applicazione può
essere elaborata sia sul client (‘fat
client’) che sul server (‘thin client’).
Gabriele Monfardini - Corso di Ingegneria del Software
11
Architettura two-tier: thin client e fat
client
Presentation
Thin-client
model
Server
Data management
Application
processing
Client
Presentation
Application processing
Fat-client
model
Client
Gabriele Monfardini - Corso di Ingegneria del Software
Server
Data
management
12
Architettura three-tier
◆
E' una architettura client/server con tre processi
ben separati che vengono eseguiti su tre
piattaforme diverse:
•
1. L'interfaccia utente che viene eseguita sul client
•
2. I moduli che realizzano l'elaborazione dei dati e le
funzionalità specifiche dell'applicazione. Questo strato gira su
una piattaforma che è spesso chiamata application server.
3. Il DBMS che mantiene i dati necessari all'application server.
La piattaforma che implementa questo strato è spesso detta
database server.
•
◆
L'architettura three-tier ha diversi vantaggi
rispetto a quella one-tier o two-tier:
•
•
Una maggiore modularità che rende più facile modificare
i componenti di uno strato senza che vi siano influenze
sugli altri
Separare le funzioni rende più facile avere performance
più elevate all'aumentare delle richieste
13
Three-tier architecture – struttura
ed esempio
Presentation
Client
Client
Server
Server
Application
processing
Data
management
HTTP interaction
Database server
Web server
Client
SQL query
Account service
provision
SQL
Customer
account
database
Client
Client
Gabriele Monfardini - Corso di Ingegneria del Software
14
Caratteristiche dell'architettura
client-server
◆
Vantaggi
•
•
•
◆
La distribuzione dei dati (quando c’è) è ovvia
Economico: permette di dimensionare l’hardware a seconda del
servizio supportato
Facile aggiungere nuovi server, o aggiornare quelli
presenti, senza toccare gli altri sottosistemi (server)
Difficoltà
•
•
•
I sottosistemi usano diversa rappresentazione e organizzazione
dei dati. Lo scambio dati (quando serve…) puo’ essere
inefficiente
Management (backup, recovery…) ridondante in ciascun server
Non c’è un registro centrale di server e servizi: puo’ essere
difficile individuare i servizi disponibili (in WAN piu’ che in LAN)
Gabriele Monfardini - Corso di Ingegneria del Software
15
Uso delle architecture
Architetture
Two tier
Sistemi
•
•
•
Sistemi legacy nei
quali separare la
logica dai dati non è
fattibile /
economicamente
conveniente
Sistemi con un alto
livello di
computazione ma con
pochi dati
Sistemi orientati ai
dati (navigazione o
ricerche) ma poca
computazione
16
Uso delle architecture
Architetture
Two-tier
con fat
clients
Sistemi


Applicazioni dove
l'eleborazione, di solito
piuttosto elevata, viene
eseguita sul client
(esempio visualizzazione di
dati)
Applicazioni con
funzionalità lato utente
sufficientemente stabili
Gabriele Monfardini - Corso di Ingegneria del Software
17
Uso delle architecture
Architetture
Three tier
Sistemi


Applicazioni grandi con
centinaia/migliaia di clienti
Applicazioni che integrano
ed elaborano informazioni
provenienti da fonti diverse
Gabriele Monfardini - Corso di Ingegneria del Software
18
Architettura peer-to-peer
◆
Una rete peer-to-peer (P2P) pura non ha
il concetto di client e server ma soltanto
di nodi paritetici che ad ogni istante
funzionano come client e come server
rispetto agli altri nodi della rete
Gabriele Monfardini - Corso di Ingegneria del Software
19
Architectura peer-to-peer pura
◆
◆
Non esistono server centrali che tengono
traccia dei nodi e delle informazioni loro
associate e che rispondono alle
interrogazioni che li riguardano
Non ci sono server centrali che
controllino la rete
Gabriele Monfardini - Corso di Ingegneria del Software
20
Architetture peer-to-peer ibride
◆
◆
◆
Esistono server centrali che tengono le
informazioni sui nodi e rispondono alle
interrogazioni su di essi
I nodi tengono le risorse disponibili
(mentre i server non hanno risorse) ed
informano di tali risorse i server
I nodi condividono le risorse fra loro
Gabriele Monfardini - Corso di Ingegneria del Software
21
BitTorrent
◆
◆
◆
◆
◆
Sviluppato da Bram Cohen nel 2002 in
Python
Disponibile per Windows, MacOS e
Linux
Ha bisogno di un server, il tracker che
tiene traccia dei client per poterli
mettere in comunicazione
Il tracker gestisce le risorse e può
bannare clienti che non rispettino le
regole
Tracker pubblici/privati (a invito)
Gabriele Monfardini - Corso di Ingegneria del Software
22
BitTorrent: file .torrent
◆
◆
◆
◆
Il file originale è diviso in tante parti
(frammenti o segmenti) di cui si calcola
un codice hash con SHA1
Il numero dei frammenti e i codici hash
necessari a garantire l'integrità dei dati
sono contenuti nel file .torrent
Tutti i client sono in grado di leggere e
produrre file .torrent
Il file .torrent contiene anche l'URL del
tracker in una apposita sezione
announce
Gabriele Monfardini - Corso di Ingegneria del Software
23
BitTorrent: come trovare il
.torrent
◆
◆
Il file .torrent è messo a disposizione
da chi ha distribuito la prima copia del
file
Esistono motori di ricerca specifici che
indicizzano solo file .torrent
Gabriele Monfardini - Corso di Ingegneria del Software
24
BitTorrent: seeds e peers
◆
◆
Seed: nodo che possiede il file e sta
solo facendo upload (questa fase è
detta seeding)
Peer: nodo che non possiede ancora
l'intero file e sta quindi facendo
download e upload ossia funge
contemporaneamente da client e da
server.
Uno dei vantaggi del protocollo BT è
che l'upload inizia non appena il peer è
in possesso di un frammento completo
Gabriele Monfardini - Corso di Ingegneria del Software
25
BitTorrent: leechers
◆
Share ratio=upload/download
◆
Tanto più è alto, quanto più il
comportamento è “collaborativo”
I peer con share ratio molto basso o
nullo sono detti leechers (sanguisughe)
e sono penalizzati in vari modi (ad
esempio essendo bannati da certi
tracker, oppure venendo penalizzati nel
download)
◆
Gabriele Monfardini - Corso di Ingegneria del Software
26
Seeders promotion problem
◆
◆
◆
Il protocollo è molto efficiente per i
contenuti “popolari” ma non favorisce a
sufficienza la disponibilità di contenuti
più rari
Dato che mantenere un seed per un
contenuto poco richiesto comporta dei
costi, la maggior parte dei contenuti
rari diventa non disponibile poco dopo
la sua pubblicazione
Per contrastare il problema si usa il
bundling ossia il mettere insieme più
file simili nello stesso .torrent
Gabriele Monfardini - Corso di Ingegneria del Software
27
Trackerless torrent e DHT
◆
◆
◆
Il tracker limita la resistenza del
protocollo a guasti e attacchi in quanto
è il single point of failure, l'anello
debole della catena
Nel 2005 alcuni client BT hanno
cominciato ad offrire il supporto a
torrent trackerless, senza server
tracker
Il meccanismo funziona implementando
una Distributed Hash Table
Gabriele Monfardini - Corso di Ingegneria del Software
28
DHT
◆
◆
◆
L'idea è quella di costituire un sistema
distribuito che permetta di fare lookup
di una chiave ottenendo un valore
Le coppie (chiave,valore) sono
distribuite tra i vari nodi secondo un
algoritmo noto
Il sistema è congegnato per scalare
bene fino a numeri di nodi molto
elevati (miliardi) e per avere la minima
redistribuzione di chiavi in caso di
scomparsa/comparsa di nodi
Gabriele Monfardini - Corso di Ingegneria del Software
29
DHT
◆
◆
◆
Si inizia da uno spazio astratto (ad
esempio le stringhe di 160 bit)
Dato un filename con i dati ad esso
relativi, tramite una hash function (ad
esempio SHA1) si genera la chiave k
lunga 160 bit del filename
A questo punto l'operazione put(k,dati)
porterà il nodo assegnatario della
chiave k a memorizzare il contenuto e
a rispondere alle seguenti operazioni di
get(k)
Gabriele Monfardini - Corso di Ingegneria del Software
30
DHT
◆
◆
Il collegamento fra nodi è detto overlay
network e le sue proprietà, dal punto di
vista della teoria dei grafi, sono
influenzate dal grado massimo di ogni
nodo (il numero di collegamenti ad altri
nodi) e quindi dal diametro della rete
Come si scelgono i nodi a cui collegarsi
e come vengono distribuite le chiavi
dipende dall'implementazione, ma
spesso si fa riferimento al concetto di
hashing consistente
Gabriele Monfardini - Corso di Ingegneria del Software
31
DHT
◆
◆
◆
L'hashing consistente stabilisce una
funzione distanza fra l'ID del nodo e la
chiave, assegnando ciascuna chiave al
nodo più vicino.
Allo stesso tempo i nodi sono collegati
ciascuno a quelli più vicini ad esso
secondo la funzione distanza
Quando un nodo scompare/riappare
solo i “vicini” saranno influenzati,
dovendo acquisire o cedere parte delle
coppia chiave/valore
Gabriele Monfardini - Corso di Ingegneria del Software
32
Peer eXchanging (PEX)
◆
◆
Con questo meccanismo ogni peer
contatta i peer noti per venire a
conoscenza di altri peer
Quindi questo consente di non avere
tracker fintanto che si possa contattare
uno o più peer iniziale da cui poi
ottenere liste di peer
Gabriele Monfardini - Corso di Ingegneria del Software
33
BitTorrent: traffico e
throttling
◆
◆
Il traffico generato da BT è una
percentuale non indifferente della
banda totale consumata (~20-40%
secondo studi di diversi anni fa)
Per questo motivo alcuni ISP hanno
deciso di limitare la banda concessa al
p2p per non penalizzare il resto del
traffico (throttling), utilizzando
algoritmi di traffic shaping e
alimentando polemiche relative alla
cosiddetta “Net Neutrality”
Gabriele Monfardini - Corso di Ingegneria del Software
34
Contromisure al throttling
◆
◆
MSE/PE: algoritmo di criptazione del
traffico
Alcuni algoritmi avanzati di traffic
analysis sono in grado di capire il tipo
di traffico usando tecniche statistiche
(anche se non il contenuto inviato)
Gabriele Monfardini - Corso di Ingegneria del Software
35