Sistema P2P Persistente e Bilanciato

1
Sistema P2P Persistente e Bilanciato

• Emanuele Spinella
• Corso di Reti di Calcolatori LS
• Prof. Antonio Corradi
• A.A. 2003/2004

2
Reti Peer To Peer

• Una rete Peer To Peer (P2P) è un sistema
  distribuito che permette agli utenti in possesso
  di una certa applicazione di connettersi fra loro
  e condividere informazioni
• Paradigma C/S
• Ogni terminale può fungere alternativamente o
  simultaneamente da client e da server
• Comunicazione molti-a-molti

3
Reti Peer To Peer

• 3 possibili modelli
• Centralizzate
• Decentralizzate
• Ibride
• Ogni modello con proprie caratteristiche, punti
  deboli e punti di forza

4
Reti P2P Centralizzate

• Unico sistema centrale che gestisce il traffico
  degli utenti
• Il sistema centrale è costituito da uno o più
  server coordinati
• Il sistema centrale dispone di directories in cui
  tiene lelenco dei files condivisi e tutte le
  info necessarie per localizzare i proprietari e
  connettersi ad essi
• Napster come tipico esempio

5
Reti P2P Centralizzate

• Il peer che necessita di un file inoltra la
  richiesta al sistema centrale, il quale lo
  indirizza verso il proprietario del documento e
  fornisce il supporto per stabilire la connessione

Search file
Data Tranfer
Connection
Detect source
6
Reti P2P Centralizzate

• Vantaggi
• Efficienza e velocità di ricerca (servizio simile
  a quello di naming)
• Svantaggi
• Tempo di aggiornamento delle directories
  difficile da dimensionare
• Sistema centrale come pericoloso punto di rottura
  da cui dipende la disponibilità di servizio

7
Reti P2P Decentralizzate

• Nessun sistema centrale ogni peer si fa carico
  delle operazioni di ricerca e connessione (es.
  Gnutella)

Search file
Connect
Data transfer
Detect source
8
Reti P2P Decentralizzate

• Vantaggi
• Flessibilità non esistono punti di rottura che
  possono inibire il servizio
• Anonimato degli utenti
• Svantaggi
• La mancanza di registrazione riduce il controllo
  sugli utenti QoS non sempre garantita

9
Reti P2P Ibride

• Risultato dellunione delle due precedenti
  soluzioni
• Presenza di molti supernodi (server) presso
  ognuno dei quali sono registrati un certo numero
  di utenti
• Tutti i moderni sistemi P2P adottano una
  soluzione ibrida (WinMX, Kazaa, eMule, ecc.)

10
Reti P2P Ibride

• Il meccanismo di ricerca è simile a quello delle
  reti centralizzate, ma il peer cliente e quello
  servitore possono appartenere a supernodi diversi

Access directory search file in my subnet
Not found! ?
Access directory search file in my subnet
Data transfer
Connect
Detect source
Search file
Search file
11
Reti P2P ibride

• Il server ricerca il file allinterno dei peers
  registrati presso di esso e propaga la richiesta
  anche verso gli altri supernodi, che cercheranno
  nel proprio gruppo di utenti
• A ricerca terminata si effettua la connessione
  che precede il trasferimento dei dati

12
Reti P2P ibride

• Possibilità di gestire il livello di
  decentralizzazione o centralizzazione
• Un elevato numero di supernodi aumenta la
  decentralizzazione e diminuisce lincidenza
  derivante dalleventuale crash di un server (più
  supernodi significa meno peers registrati presso
  ognuno di essi, quindi meno utenti isolati dal
  servizio in caso di crash), ma si giova meno dei
  vantaggi che i server stessi possono offrire
• Un basso numero di supernodi sposta
  larchitettura verso il modello centralizzato,
  con tutti i vantaggi e gli svantaggi che questo
  comporta

13
Rete P2P persistente e bilanciata

• Necessità di dotare una rete P2P di
  caratteristiche atte ad aumentare la QoS offerta
  sui fronti della persistenza e del bilanciamento
  del carico
• Applicazioni in contesti che richiedono un alto
  livello di dependability (es. condivisione di
  importanti documenti fra stazioni di polizia e
  organizzazioni per la sicurezza sparse nel mondo
  e connesse in rete)
• Adozione della architettura ibrida

14
Persistenza

• La persistenza rappresenta la principale
  caratteristica del sistema
• Persistenza dellinfrastruttura necessità di far
  fronte ad eventuali crash dei supernodi per
  evitare lisolameto dalla rete dei peers ad essi
  connessi
• Persistenza dei nodi ogni singolo nodo deve
  garantire la persistenza in quanto depositario di
  importanti informazioni. Necessità di impiego di
  un modello di replicazione adeguato

15
Bilanciamento del carico

• Evitare la presenza contemporanea di nodi
  inattivi e nodi sovraccarichi
• Se un nodo richiede un documento posseduto da più
  peers, è opportuno che si valuti lo stato di
  carico di ognuno di essi e si effettui il
  trasferimento da quello con il numero inferiore
  di connessioni correnti

16
Architettura

• Tre attori principali
• LookUpServer svolge le funzioni tipiche dei
  supernodi (supporto per una ricerca efficiente e
  veloce dei documenti)
• Peer rappresenta un terminale della rete P2P
  (può essere uno dei computer presenti in una
  stazione di polizia)
• PeerCopy rappresenta la copia esatta di un Peer
  e fornisce il supporto per il modello di
  replicazione atto a garantire la persistenza dei
  nodi

17
LookUpServer

• Ogni peer, al suo ingresso nella rete, deve
  registrarsi presso un LookUpServer
• Novità rispetto al modello ibrido standard il
  LookUpServer non possiede nessuna directory delle
  risorse condivise (utilizzo di messaggi di
  ricerca)
• A fronte di una richiesta il LookUpServer del
  nodo client (MasterServer) invia dei messaggi di
  ricerca a tutti i propri peers e agli altri
  servers (SlaveServer)
• Maggiore overhead di comunicazione
• Eliminati i problemi derivanti dalla frequenza di
  aggiornamento delle directories

18
LookUpServer (ricerca)

• Il peer client invia la richiesta al proprio
  LookUpServer (MasterServer)

Search message
Response message
19
LookUpServer (ricerca)

• Il MasterServer replica la richiesta ai propri
  peers e agli SlaveServer

Search message
Response message
20
LookUpServer (ricerca)

• Gli SlaveServer replicano la richiesta ai propri
  peers

Search message
Response message
21
LookUpServer (ricerca)

• I peers che hanno ricevuto la richiesta
  rispondono ai propri LookUpServer

Search message
Response message
22
LookUpServer (ricerca)

• Il MasterServer riceve le risposte raccolte dagli
  SlaveServer

Search message
Response message
23
LookUpServer (ricerca)

• Il MasterServer compone la risposta complessiva e
  la invia al client, il quale dovrà poi scegliere
  il documento che desidera

Merge responses
Search message
Response message
24
Merge responses

• Problema dovuto alla formulazione delle richieste
  con stringhe che non costituiscono un match
  esatto con il nome del documento desiderato
• Possibilità di trovare più documenti che
  contengono la stringa di query (es. la stringa
  ack può causare il ritrovamento dei files
  acknowledge.pdf, racket.mp3, sacker.doc,
  pippo.ack, ecc)
• Più peers possono avere lo stesso documento
• Il MasterServer deve elaborare le risposte
  ricevute dai propri peers e dagli SlaveServer
  raggruppando le occorrenze uguali
• Lo stesso devono fare gli SlaveServer con le
  risposte provenienti dai propri peers

25
RequestFile

• E una struttura dati che rappresenta un file il
  cui nome contiene la stringa di query
• Ogni RequestFile è caratterizzato dal nome del
  file che rappresenta e dalla lista dei peers che
  lo possiedono

26
RequestFile

• Ogni LookUpServer riceverà un certo numero di
  RequestFile e dovrà unire quelli omonimi in un
  unico oggetto, aggregando le liste dei peers
  proprietari
• Lutente che ha inizialmente fatto la richiesta,
  alla fine del procedimento di ricerca, potrà
  scegliere fra un insieme di files (RequestFile)
  diversi senza sapere a chi appartengono
  (trasparenza della locazione)
• Il download di una risorsa appartenente a più
  nodi viene gestita dal sistema scegliendo il peer
  migliore da cui scaricare, in modo da
  bilanciare il più possibile il carico sulla rete

27
RequestFile (merging)

• Ogni peer istanzia un RequestFile per ogni file
  in suo possesso che fa match con la query

Request File Name resA PeerList p1
Request File Name resA PeerList p2
Request File Name resB PeerList p1
Request File Name resC PeerList p2
Peer p2
Peer p1
LookUpServer
28
RequestFile (merging)

• Il LookUpServer riceve i RequestFile di tutti i
  peers e unisce quelli omonimi modificando
  opportunamente la PeerList

Request File Name resA PeerList p1, p2
Request File Name resA PeerList p1
Request File Name resA PeerList p2
Request File Name resB PeerList p1
Request File Name resB PeerList p1
Request File Name resC PeerList p2
Peer p2
Request File Name resC PeerList p2
Peer p1
LookUpServer
Result
29
Peer

• Nodo che può effettuare e/o ricevere richieste di
  ricerca di files
• In caso di richiesta ricevuta, il Peer deve
  controllare nella propria directory di sharing la
  presenza di uno o più files nel cui nome sia
  contenuta la stringa di query
• Per ogni file compatibile con la query il Peer
  deve comporre un oggetto RequestFile e inviarlo
  al proprio LookUpServer

30
PeerCopy

• Ogni Peer è dotato di una copia, fisicamente
  rappresentata da un diverso terminale, che
  possiede gli stessi files condivisi
  dalloriginale
• Il modello di replicazione utilizzato è quello a
  copie calde e passive
• Calde in quanto vengono create insieme
  alloriginale e si mantengono aggiornate sullo
  stato del sistema
• Passive perchè non eseguono fino al crash del
  peer associato

31
PeerCopy

• Dal punto di vista logico il Peer estende il
  concetto di copia infatti questultima è un Peer
  a tutti gli effetti, a parte il fatto che non può
  inoltrare richieste, ma solo riceverne ed
  eventualmente eseguire lupload dei files
• Esattamente come un Peer, la copia si deve
  registrare presso il LookUpServer (lo stesso del
  Peer cui è associata)

32
QoS Persistenza

• La persistenza è ottenuta mediante un sistema di
  heartbeats che consente di testare costantemente
  lo stato di attività dellinfrastruttura di
  supporto (LookUpServer) e dei peers
• La mancata ricezione dellheartbeat allo scadere
  di un timeout, provoca linnesco di una procedura
  di recovery

33
QoS Persistenza dellinfrastruttura di supporto

• Leventuale crash di un LookUpServer può causare
  lisolamento dalla rete di tutti i peers (e delle
  copie) ad esso connessi
• Iniziativa dei peers e delle copie per monitorare
  lo stato del server ed eseguire leventuale
  procedura di recovery (monitoring non
  centralizzato)

34
QoS Persistenza dellinfrastruttura di supporto

• Invio periodico di heartbeats (hb) dal
  LookUpServer ai peers connessi

35
QoS Persistenza dellinfrastruttura di supporto

• Dopo la ricezione di ogni hb, il Peer fa partire
  un timer, prima dello scadere del quale deve
  essere ricevuto lhb successivo

36
QoS Persistenza dellinfrastruttura di supporto

• In caso di guasto, gli hb non possono più essere
  inviati e il timer di ogni Peer scade

timer
timer
37
QoS Persistenza dellinfrastruttura di supporto

• Ogni Peer esegue una procedura di recovery che
  consiste nel registrarsi presso un altro server e
  indurre la copia a fare lo stesso

register
New Server Info
register
register
New Server Info
register
38
QoS Persistenza dellinfrastruttura di supporto

• Viene ristabilito il sistema di hb

39
QoS Persistenza dei nodi

• In caso di crash di un Peer deve essere
  automaticamente messa in esecuzione la copia, per
  garantire la continuità del servizio
• La copia, calda e passiva, mantiene monitorato lo
  stato di attività delloriginale ricevendo da
  questo dei segnali di hb

40
QoS Persistenza dei nodi

• In caso di crash del Peer, la copia non riceve
  più alcun hb e, allo scadere di un timeout,
  inizia la propria procedura di recovery

PeerCopy timer
Server hb
41
QoS Persistenza dei nodi

• PeerCopy disattiva loriginale sul server il
  binomio Peer/PeerCopy è sempre presente, un flag
  stabilisce quale dei due è attivo

Deactivate original Peer
Server hb
42
QoS Persistenza dei nodi

• I parametri delloriginale vengono mantenuti
  allinterno del server anche in caso di crash, in
  modo da poter essere riutilizzati in seguito a
  una futura riattivazione e per mantenere la
  corrispondenza con la copia

Deactivate original Peer
Server hb
43
QoS Persistenza dei nodi

• Le richieste di files arrivano al Peer originale
  o alla copia a seconda dello stato del flag.
  PeerCopy è perciò in grado di effettuare lupload
  di un file

Deactivate original Peer
Server hb
44
QoS Persistenza dei nodi

• La seconda fase del protocollo di recovery
  prevede la redirezione degli hb del server verso
  la copia poiché loriginale è down spetta alla
  copia monitorare lo stato di attività del
  LookUpServer

Server hb
Server hb
45
QoS Persistenza dei nodi

• Il crash di un Peer può avvenire in un momento di
  inattività, ma anche durante il trasferimento di
  un file
• Oltre al protocollo di recovery bisogna gestire
  anche il fallimento del trasferimento dati
• Il Peer sorgente invia al nodo ricevente, prima
  dellinizio del trasferimento, lindirizzo della
  propria copia
• In caso di fallimento del Peer il nodo ricevente
  può, senza effettuare nuove ricerche, rivolgersi
  direttamente alla copia per riiniziare il
  trasferimento

46
QoS Persistenza generale

• E anche possibile che i guasti non colpiscano
  isolatamente il LookUpServer o il Peer, ma
  entrambe le entità
• Di particolare interesse il caso di guasto di un
  LookUpServer in un momento in cui anche il Peer
  originale è down

47
Registrazione virtuale

• Peer e PeerCopy sono due entità che collaborano
  per rappresentare un unico concetto di nodo
  persistente
• Finchè la copia è attiva, lutente percepisce il
  nodo come attivo, in quanto è in grado di fornire
  il servizio (anche se loriginale è down)

48
Registrazione virtuale

• Esattamente come nel caso di crash del solo Peer
  originale, il binomio Peer/PeerCopy deve rimanere
  presente a livello di LookUpServer
• Se cade anche il LookUpServer, spetta alla copia
  effettuare una nuova registrazione presso un
  altro server, sia di se stessa, sia
  delloriginale andato in crash (registrazione
  virtuale)
• Sul nuovo server vengono inseriti i parametri
  della copia e delloriginale, esattamente come
  sul vecchio. Viene infine opportunamente settato
  il flag che segnala lattività della copia
• Quando il Peer originale verrà riattivato si
  ritroverà registrato presso un server differente

49
Bilanciamento del carico

• Aspetto relativo alla QoS avente la finalità di
  distribuire, con politiche che rispettano il
  principio di minima intrusione, il carico in modo
  omogeneo sui diversi nodi
• Bilanciamento a livello di
• Peer/Copia per quanto riguarda il trasferimento
  dati
• LookUpServer per quanto riguarda il numero di
  registrazioni

50
Registration Balancing

• Lingresso nella rete da parte di un Peer
  presuppone la sua registrazione presso un
  LookUpServer
• Ogni Peer dispone di una lista di server
  memorizzata in locale sotto forma di file
• Il Peer contatta il primo server attivo della
  lista, il quale
• Aggiorna la server-list del Peer con lelenco
  attuale dei server attivi
• Rileva il numero di connessioni di tutti i server
  attivi e dirige la registrazione del peer verso
  il LookUpServer meno carico

51
Data Transfer Balancing

• In seguito a un processo di ricerca lutente può
  decidere di scaricare un documento posseduto da
  più peers
• Rilevazione del best peer to download
• Il peer richiedente contatta tutti i nodi
  presenti nella peer list delloggetto RequestFile
  associato alla risorsa desiderata, per conoscere
  quello meno carico e connettersi ad esso
• Viene stabilita la connessione con il nodo che
  sta effettuando il numero minimo di trasferimenti

52
Implementazione

• La fase implementativa ha visto lutilizzo della
  piattaforma java e in particolare di
• RMI come supporto allinvocazione remota dei
  metodi
• Multithreading per la gestione della persistenza
• Sockets per i trasferimenti dati

53
RMI

• Ogni Peer, nella fase di ingresso nella rete,
  ricopre il ruolo di un oggetto servitore che
  pubblica il proprio servizio per renderlo noto ai
  possibili clienti
• Il processo di registrazione prevede liscrizione
  del Peer allinterno di un RMI registry, che
  fornisce un riferimento ad esso a chiunque ne
  faccia richiesta
• Larchitettura P2P aggiunge a tale servitore la
  capacità di potere anche richiedere servizi e
  svolgere il ruolo di un client

54
RMI

• Tutte le entità in gioco (Peer, PeerCopy,
  LookUpServer) devono iscriversi in un registry,
  poiché tutte forniscono un servizio (ricerca
  files, trasferimento dati, registrazione)
• Il modello prevede la presenza del registry sulla
  macchina delloggetto che fornisce il servizio

55
RMI

• Nella server-list memorizzata in locale da un
  Peer ci sono perciò gli indirizzi e le porte su
  cui si affacciano i registry associati ai vari
  LookUpServer
• Il riferimento remoto a un LookUpServer viene
  ottenuto mediante un preliminare colloquio con il
  registry

56
MultiThreading

• Il sistema di heartbeat deve agire in background
  lasciando che i processi principali si occupino
  delle loro attività (registrazione, ricerca
  files, migrazioni, ecc.)
• Vengono creati opportuni thread che si occupano
  dellinvio e ricezione degli hb in modo autonomo
  e senza interferire con i processi principali

57
MultiThreading

• Ogni processo principale si occupa della
  creazione dei thread di cui necessita per la
  gestione degli hb
• LookUpServer genera un thread ServerDeamon che
  si occupa di inviare gli hb al Peer
• Peer genera un thread PeerDeamonSrv per ricevere
  gli hb dal server e un thread PeerDeamon per
  inviare gli hb alla copia
• PeerCopy genera un thread CopyDeamon, al momento
  della sua istanziazione, per ricevere gli hb
  dalloriginale e, in caso di crash di
  questultimo, in seguito alla procedura di
  recovery, genera il thread PeerDeamonSrv per
  ricevere gli hb del server

58
MultiThreading

• I deamon che ricevono gli hb sono costituiti da
  contatori watch dog decrementati periodicamente
• Ad ogni ricezione di un hb vengono ri-settati al
  valore massimo
• Se lhb tarda ad arrivare il contatore raggiunge
  lo zero e lancia lallarme per innescare la
  procedura di recovery

59
MultiThreading

• I deamon che inviano gli hb sono costituiti da
  cicli infiniti che, periodicamente, inviano un
  messaggio di reset-dog al contatore del
  processo ricevente

60
MultiThreading

• Anche il trasferimento dati utilizza il supporto
  offerto dal multithreading
• Necessità che il trasferimento avvenga in
  backround mentre il processo principale continua
  le sue attività
• Creazione di un thread TransferOutThread che
  genera una socket in ascolto per eventuali
  richieste di connessione
• Accept bloccante, thread necessari

61
Sockets

• Utilizzo delle sockets per il trasferimento dei
  files
• Connessione mediante il protocollo TCP che offre
  sicurezza, ordinamento
• Generazione di altri thread per stabilire il
  canale di connessione ed effettuare il
  trasferimento dati

62
Sockets

• Una volta stabilito il best peer to download il
  peer richiedente (rPeer) genera un thread
  TransferInThread che crea una socket e tenta di
  collegarla allend-point remoto
• Il Peer sorgente (sPeer) riceve la richiesta da
  parte di rPeer e, mediante il processo
  TransferOutThread, effettua laccept di
  connessione e stabilisce il canale mediante il
  quale può iniziare il trasferimento dati

63
Sockets

• Ogni Peer svolge la funzione di server
  concorrente, in quanto può eseguire più upload
  contemporaneamente

64
Sockets

• Necessaria la creazione di un ulteriore thread
  (RcpServiceThread) che si occupi del
  trasferimento mentre il TransferOutThread torna
  in ascolto di altre eventuali richieste di
  connessione

65
Conclusioni

• La realizzazione del progetto ha permesso di
  approfondire alcuni degli argomenti principali
  del corso di Reti di Calcolatori LS, come la
  disponibilità di servizio, le tecniche di
  replicazione e il bilanciamento del carico
• E stato dunque possibile analizzare
  concretamente tutti i passi, con relative
  problematiche, che hanno portato al
  raggiungimento di un soddisfacente livello di QoS

66
Conclusioni

• Il sistema realizzato presenta numerose
  semplificazioni rispetto ai moderni software P2P.
  Daltra parte lobiettivo era quello di
  concentrare gli sforzi maggiori sugli aspetti
  relativi all QoS, magari trascurando alcune
  funzionalità di contorno o di importanza minore,
  le quali potrebbero costituire un buon punto di
  partenza per eventuali sviluppi futuri
• I test eseguiti hanno consentito un buon
  debugging dellapplicazione, cercando di coprire
  il più possibile lo spettro dei possibili eventi
  di guasto