La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

3/11/2006 Algoritmi per protocolli peer-to-peer Netgroup – Politecnico di Torino Livio Torrero –

Presentazioni simili


Presentazione sul tema: "3/11/2006 Algoritmi per protocolli peer-to-peer Netgroup – Politecnico di Torino Livio Torrero –"— Transcript della presentazione:

1 3/11/2006 Algoritmi per protocolli peer-to-peer Netgroup – Politecnico di Torino Livio Torrero –

2 2/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Approccio client-server Paradigma molto comune Un client richiede dati o servizi, un server risponde Scalabilità e affidabilità ottenuta attraverso ridondanza e sistemi di supporto (DNS…) Single point of failure nel server Richiede un amministratore di sistema per la gestione Esempi: Web, FTP… Server Client 1 Client 3 Client 2Client 4

3 3/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Paradigma peer-to-peer (1/2) Il peer-to-peer è un paradigma Specifica come si fa, non cosa Può essere applicato in diversi contesti: file sharing, voip… Non esistono nodi centrali, tutti i nodi hanno pari dignità I nodi interagiscono direttamente per lo scambio delle risorse I nodi che mantengono la rete sono gli stessi che ne usufruiscono No single point of failure Elevata scalabilità e affidabilità Si adattano meglio a infrastrutture dinamiche Sfruttano la maggiore potenza dei nuovi computer Peer 1Peer 3 Peer 2Peer 4

4 4/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Overlay peer-to-peer I peer si organizzano in un overlay: L’overlay è una “rete sulla rete” I peer si organizzano creando dei link virtuali fra loro Normalmente nell’overlay esistono più copie della stessa risorsa per massimizzarne la raggiungibilità

5 5/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Caratteristiche delle reti peer-to-peer Tutti i nodi sono potenzialmente sia client che server I nodi in quanto tali non hanno le stesse disponibilità di risorse di un server tradizionale (banda…) Alcuni peer hanno connettività limitata (NAT, firewall…) Le reti peer-to-peer sono reti di grandi dimensioni Potenzialmente di dimensioni mondiali

6 6/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Peer-to-peer: operazioni fondamentali Un nodo p2p svolge le seguenti operazioni di base: BOOT: è la fase di ingresso nella infrastruttura peer-to-peer Cache preesistenti Configurazione statica Nodi centralizzati di bootstrap LOOKUP RISORSE: come localizzo le risorse su una infrastruttura p2p? SCAMBIO DI FILE: per queste operazioni tutti gli algoritmi sono p2p puri

7 7/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Classificazione infrastrutture peer-to-peer (tecniche di lookup): approccio centralizzato Prime implementazioni di infrastrutture peer Approccio ancora fortemente simile al client server Basate su nodi fissi Colli di bottiglia => non scalano Single point of failure => infrastruttura fragile Napster è un esempio di approccio centralizzato Infrastrutture peer-to-peer Approccio centralizzato Approccio decentralizzato

8 8/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Napster: introduzione Nato come applicativo per lo scambio di file musicali Nel 1999 le major disocgrafiche fanno causa a Napster => il bacino di utenza decolla 13,6 milioni di utenti nel febbraio 2001 Nel settembre 2001 viene ordinata la chiusura di Napster Napster si converte in servizio a pagamento Nel 2002 chiude

9 9/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Funzionamento di Napster Quando un nodo entra nell’infrastruttura si registra presso il server Upload della lista delle risorse gestite Quando un nodo cerca una risorsa fa un lookup sul server centralizzato In base ai risultati ottenuti il peer si connette a un altro peer per scaricare la risorsa Peer Server centrale Upload Peer Server centrale query answer Server centrale Peer Download

10 10/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Classificazione infrastrutture peer-to-peer (tecniche di lookup): approccio non centralizzato Implementazioni più evolute Non c’è più un nodo di lookup centralizzato Le informazioni di lookup sono distribuite direttamente sui nodi Pro: maggiore scalabilità Lookup distribuito e reti gerarchiche Contro: maggiore complessità Se non c’è più server centrale, come si trovano le risorse? Infrastrutture peer-to-peer Approccio centralizzato Approccio decentralizzato

11 11/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Approcci non centralizzati L’approccio non strutturato non fornisce un controllo stretto sulla topologia della rete peer to peer Non esiste un directory service vero e proprio Uso estensivo del flooding Agenda: Gnutella: caso di studio Kazaa: caso di studio Approccio decentralizzato non strutturato strutturato

12 12/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Gnutella introduzione Gnutella è un client p2p sviluppato nel 2000 da Justin Frankel e Tom Pepper di Nullsoft, appena acquisita da AOL Pare sia stato scritto in 14 giorni… In origine il codice sorgente doveva uscire in formato GPL Tuttavia attraverso tecniche di reverse- engineering sono stati sviluppati numerosi cloni open-source Limewire è software open-source che supporta la rete Gnutella

13 13/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Gnutella: evoluzione Originariamente tutti i nodi in Gnutella erano uguali I peer erano detti servent Tuttavia questo approccio non scalava Fare un flooding su tutti i nodi della rete non funziona Bisogna tenere conto del fatto che non tutti i nodi sono uguali Per meglio tenere conto delle caratteristiche della rete Gnutella è stato riorganizzato Il risultato è una rete gerarchica a 2 livelli

14 14/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero leaf Gnutella(limewire): rete gerarchica (1/2) Ultrapeer Fa da proxy per i nodi leaf Un nodo ultrapeer deve avere una connessione Internet veloce non bloccata da firewall Deve accettare connessioni TCP da nodi esterni Deve essere possibile mandare pacchetti UDP entranti limewire => upload 10kB/s, download 20kB/s ultrapeer leaf ultrapeer leaf ultrapeer

15 15/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Gnutella(limewire): rete gerarchica (2/2) Nodi leaf Es: nodi con connessioni dialup Sono fuori dall’overlay (si connettono agli ultrapeer come client) Non accettano connessioni Gnutella Se un nodo leaf vuole diventare ultrapeer, prima si disconnette dalla rete per ripresentarsi tentando di diventare ultrapeer Un nodo leaf dovrebbe restare leaf per almeno un’ora leaf ultrapeer leaf ultrapeer leaf ultrapeer

16 16/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Perché una rete a 2 livelli? La divisione tra ultrapeer e nodi normali permette solo ai nodi “migliori” entrare nell’overlay Gli host lenti rallenterebbero le prestazioni dell’intero sistema se posti nell’overlay L’overlay diventa più piccolo ma più funzionale Dal punto di vista dei nodi leaf gli ultra-peer sono dei server

17 17/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Gnutella: overlay discovery Un nodo per accedere all’overlay Gnutella deve conoscere almeno un ultrapeer Le modalità con cui questo avviene non sono oggetto di Gnutella Cache, well known nodes… Come scoprire altri nodi? Pong caching Messaggio Ping (richiesta): chi lo riceve risponde con un messaggio Pong Messaggio Pong (risposta): contiene le informazioni relative a un computer (IP + porta) Solo gli ultrapeer mandano i pong Quando un ultrapeer riceve dei messaggi pong li mette nella sua pong cache Solo gli ultrapeer hanno la pong cache Quando un ultrapeer riceve un messaggio ping risponde con tutti i pong nella sua cache

18 18/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Gnutella handshake Ogni connessione Gnutella comincia con un handshake Un nodo accede all’overlay con un messaggio GNUTELLA CONNECT che apre un socket TCP I messaggi di handshake sono costituiti da gruppi di header di formato simile ad HTTP (testo ASCII) Ogni header è nella forma :, … Ogni gruppo inizia con una greeting line che identifica il messaggio Handshake a 3 vie: CONNECT OK Host che si connette Host che riceve la connessione

19 19/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Esempi di handshake Gnutella(1/2) Un nodo leaf si connette a un UltraPeer (connessione generica) 0.6 è la versione corrente di Gnutella GNUTELLA connect/0.6 X-Ultrapeer=false GNUTELLA/ OK GNUTELLA connect/0.6 X-Ultrapeer=false GNUTELLA/ OK Listen-IP: :9376 Remote-IP: Un nodo leaf dietro un NAT si connette a un ultrapeer Listen-IP indirizzo del peer che manda messaggio Remote-IP indirizzo nodo leaf visto da UltraPeer NAT Un ultrapeer si connette a un ultrapeer GNUTELLA connect/0.6 X-Ultrapeer=true GNUTELLA/ OK leafultrapeer leafultrapeer

20 20/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Esempi di handshake Gnutella(2/2) Un nodo si connette a un ultrapeer che rifiuta la connessione L’ultrapeer deve fornire ultrapeer alternativi GNUTELLA connect/0.6 GNUTELLA/0.6 service unavailable X-Try-Ultrapeers: :9376, :3988… GNUTELLA connect/0.6 GNUTELLA/ OK X-Try-Ultrapeers: :9376, :3988… Un nodo si connette a un ultrapeer che accetta e fornisce indirizzi alternativi È consigliato fornire altri ultrapeer a cui connettersi Limewire ne fornsice 10 ultrapeerNodo Gnutella generico ultrapeerNodo Gnutella generico

21 21/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Da nodo leaf a ultrapeer I nodi decidono da soli se connettersi alla rete come Ultra peer o nodi normali Un nodo DEVE restare leaf per un ora Poi può tentare di connettersi a un ultrapeer come ultrapeer Se l’ultrapeer lo rifiuta, torna leaf per un’altra ora leaf 1h ultrapeer ultrapeer? ultrapeer ultrapeer connect ultrapeer? ultrapeer Refuse connection leaf (!) ultrapeer leaf connect Leaf for 1h

22 22/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero I Connection Slot: organizzazione delle connessioni in Gnutella Un connection slot rappresenta la necessità di un nodo di creare una connessione verso un altro o la disponibilità ad accettare le connessioni Un nodo leaf ha 3 connection slot verso gli Ultrapeer Creerà fino a 3 connessioni verso ultrapeer diversi Un ultrapeer si connetterà con al più 32 altri ultrapeer questo valore è detto network degree Un ultrapeer ha 30 connection slot verso i nodi leaf Un ultrapeer non permette a più di 30 nodi foglia di connettersi a lui

23 23/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Lookup in Gnutella: introduzione L’algoritmo di lookup è il dynamic querying Obiettivo: localizzare una risorsa con il minor numero di messaggi possibile Avvio mandando pochi messaggi Intensifica alle fine Se una risorsa è popolare la trovo subito Viene eseguito solo dagli ultrapeer Si articola in 3 fasi: “Search our leaves” “Probe Query” “Controlled Broadcasting” Il dynamic querying interagisce con il Query Routing Protocol (QRP) Obiettivo: impedire che siano inviati messaggi di lookup che non ritornerebbero risultati

24 24/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero TTL=1 Dynamic Querying: search our leaves L’ultrapeer manda a tutti i suoi nodi foglia una query di lookup con TTL=1 Dopo l’invio si attende per 2,4s I nodi foglia che hanno copia della risorsa risponderanno alla query leaf ultrapeer leaf TTL=1 Answer

25 25/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero ultrapeer Dynamic Querying: probe query L’ultrapeer manda a tutti gli ultrapeer ad esso collegati una query di lookup con TTL=1 Gli Ultrapeer che hanno copia della risorsa risponderanno alla query Gli ulrapeer inoltrano la richiesta ai loro nodi leaf Reimpostano TTL=1 Questa query serve a stimare la popolarità della risorsa Se si ottengono 150 risposte positive in tutto l’algoritmo finisce TTL=1 ultrapeer TTL=1 Answer leaf TTL=1 leaf TTL=1 Answer TTL=1

26 26/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Dynamic Querying: controlled broadcasting Ogni 2.4s ultrapeer manda una query a uno solo degli ultrapeer connessi TTL=2 oppure TTL=3 a seconda del numero di risposte ottenute nella fase precedente Se si ottengono 150 risposte positive l’algoritmo finisce Se trascorrono più di 200s dall’inizio della ricerca l’algoritmo è interrotto E’ una ricerca in profondità: La probe query stimava la popolarità della risorsa presso i soli ultrapeer vicini Il controlled broadcasting effettua una ricerca approfondita partendo da uno solo degli ultrapeer vicini A seconda del valore del TTL si parla di: Ricerca TTL2 Ricerca TTL3

27 27/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Ricerca TTL2 e ricerca TTL3 A inizia la ricerca: manda query con TTL=2 SOLO a B B decrementa il TTL=> TTL=1 TTL<>0 => inoltra la query a TUTTI gli ultrapeer ad esso collegati (in figura, C è il solo connesso) C decrementa il TTL => TTL=0 TTL=0 => inoltra la query a TUTTI i leaf ad esso collegati La TTL3 funziona nello stesso modo (TTL=3) la ricerca coinvolge un numero elevato di ultrapeer Limewire non usa MAI TTL>3 Ultrapeer B Leaf 1 Leaf 2 Ultrapeer A TTL=2 TTL=1 Ultrapeer C

28 28/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Gnutella: Query Routing Protocol Nel Dynamic Querying gli ultrapeer inoltravano le query ai nodi leaf collegati Se il nodo leaf non mantiene risorse, è inutile propagare la query Se l’utente del nodo leaf non vuole rispondere alle query, è inutile propagargli la query Il QRP a questo scopo permette al nodo leaf di mandare all’ultrapeer una descrizione delle risorse gestite Le informazioni sono contenute nella QRP table Inviata dopo la connessione Appositi messaggi permettono l’aggiornamento delle informazioni della QRP table

29 29/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero QRP table Array di 65,536 byte Un nodo che non condivide nulla li setta tutti a 0 Se il nodo leaf condivide il file limewire.exe: Calcola l’hash del nome del file Setta a 1 il bit corrispondente nella QRP table Verranno inoltrate le query per limewire.exe Gli ultrapeer possono generare QRP table composite Vengono scambiate tra gli ultrapeer Sono generate a partire dalle QRP table delle foglie Se un bit è a 1 in una QRP table di una foglia, viene settato a 1 nella QRP table dell’ultrapeer Last hop saving: Se un ultrapeer riceve query con TTL=1 e la QRP table composita blocca, la query non è inoltrata

30 30/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kazaa: introduzione Kazaa è stato scritto da Niklas Zennstrom e Janus Friis nel 2001

31 31/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kazaa: overlay gerarchico Basata sul protocollo Fast Track Rete gerarchica a 2 livelli SuperNodi (SN) Nodi Ordinari (ON) Le connessioni tra SN e ON e tra SN e SN sono su TCP Si utilizza HTTP per il download dei dati Tutto il traffico di segnalazione (connessione + lookup) è criptato TCP ON SN TCP SN TCP ON TCP

32 32/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kazaa: ingresso nella rete 1. Ogni nodo mantiene una cache di SN (SN cache list) Esistono default server se la cache è vuota All’inizio un ON prova tutti i SN nella sua cache con pacchetti UDP 2. L’ON inizia connessioni TCP simultanee con più SN 3. L’ON seleziona un SN e si disconnette dagli altri SN ON UDP probe SN ON TCP connect SN ON disocnnect

33 33/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kazaa: metadata Quindi manda in upload al suo SN metadati circa i file che contiene Manda IP della macchina ON, metadati sui file stessi I metadati per un file includono: nome file dimensione contenthash che identifica la risorsa (hash del file) E’ come se ogni SN fosse un piccolo server Napster Ogni SN tiene informazioni solo sui suoi ON (non su quelli dei SN vicini) ON Metadata SN

34 34/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kazaa: neighbor selection Ogni SN manda ai suoi ON una lista con 200 altri SN alla connessione Queste informazioni sono usate per popolare la SN cache List I SN nella cache list sono quasi tutti nodi “vicini” al nodo Vicinanza valutata sulla base dell’RTT (il 60% dei nodi in cache list RTT<50ms) ON Lista SN alternativi SN

35 35/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kazaa: lookup delle risorse(1/2) 1. Ricerca di blocchi di metadati che corrispondono alla parola chiave 2. I SN inoltrano ad altri SN le richieste di lookup Algoritmo non noto, forse dynamic querying: SN sceglie a caso un vicino e gli passa la richiesta Migliorabile parallelizzando richieste ON Query(‘Gatto’) SN ‘Gatto’ ? SNSN 1SN 3 Query(‘Gatto’) Scelgo SN 3 Rispondo alla query

36 36/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kazaa: lookup delle risorse(2/2) 3. Le risposte contengono i metadati relativi al file includendo le informazioni sui peer su cui si trovano 4. ON sceglie un file e fa una richesta di download con il contenthash del file come parametro (simile a HTTP GET) La connessione per il download è diretta Per incrementare le prestazioni il download è fatto scaricando in parallelo il file a frammenti dall’insieme di nodi che lo contengono 5. Se il download fallisce si cerca di nuovo il file direttamente con il contenthash (chash) ON SN Answer ‘Gatto_bianco.txt’ ‘Gatto_nero.txt’ ON Download(chash) SN ON Query(chash) SN

37 37/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kazaa: download con firewall Se il peer richiedente è dietro NAT/firewall, inizia lui il trasfrerimento Se il peer con il file è dietro NAT/firewall, inizia lui il trasferimento 1. ON A chiede di iniziare attraverso il SN 2. SN risponde con IP e porta del peer con il file 3. Il peer con il file manda una richiesta a ON A: pin hole sul NAT 4. ON A inizia il download come al solito Kazaa peer 2:Downolad(chash)1:Downolad(chash) 3:GIVE NATNAT Kazaa peer NATNAT Downolad(chash) ON A 1:Downolad_req 2: peer info SN 1:Downolad_req ON A

38 38/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Approccio strutturato I peer si organizzano secondo una topologia precisa Esiste un directory service distribuito Ricerche efficienti, ma quanto costa mantenere il directory service? Programma: Le infrastrutture DHT CHORD Kademlia Approccio decentralizzato non strutturato strutturato

39 39/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Le infrastrutture DHT: introduzione (1/2) Le distributed hash table offrono le funzionalità tradizionali delle tabelle di hash su un insieme di nodi Memorizzazione coppia Il nodo che memorizza la coppia è detto nodo responsabile della chiave Le DHT nelle infrastrutture peer-to-peer sono usate per realizzare un name service distribuito Sono completamente decentralizzate Sono scalabili Hash table

40 40/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Le infrastrutture DHT: introduzione (2/2) La DHT è realizzata su uno spazio delle chiavi astratto Solitamente chiavi a 160 bit Lo spazio degli identificatori delle chiavi coincide con quello dei nodi Le DHT espongono i messaggi put e get Put(chiave, valore): inserisce la coppia su un nodo dell’infrastruttura Il messaggio può essere inviato a qualsiasi nodo della DHT: il messaggio viene inoltrato fino al nodo responsabile per la chiave che memorizzerà il valore Get(chiave): recupera il valore associato alla chiave Il messaggio può essere inviato a qualsiasi nodo della DHT: il messaggio viene inoltrato fino al nodo responsabile per la chiave non viene raggiunto.

41 41/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero DHT: caratteristiche Assegnazione delle chiavi ai nodi con load- balancing Le chiavi sono assegnate a nodi “vicini” alle chiavi nello spazio degli ID A prescindere dal nodo che riceve la richiesta di lookup, viene localizzato sempre lo stesso nodo Ogni algoritmo DHT è caratterizzato da una funzione distanza fra i nodi Ogni nodo ha una sua routing table La routing table è costruita in modo da adattarsi alle variazaioni della rete (join e leave dei nodi)

42 42/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD CHORD realizza un DHT con le seguenti caratteristiche: Load balance: CHORD distribuisce uniformemente le chiavi fra i nodi Scalabilità: le operazioni di lookup sono efficienti Robustezza: CHORD è in grado d modificare dinamicamente le routing table dei nodi per riflettere i mutamenti della rete (nodi che entrano o escono) CHORD fornisce il metodo lookup(key) che ritorna l’indirizzo IP del nodo responsabile per la chiave CHORD si basa sul consistent hashing

43 43/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Consistent hashing in CHORD Se N è il numero di nodi presenti sulla rete, al variare di N si desidera che: La quantità di dati da rimappare nel sistema sia bassa Si garantisca l’uniformità della distribuzione delle chiavi sui nodi Il consistent hashing organizza i nodi in un cerchio modulo (m = #bit ID) L’algoritmo di hash usato è SHA1 Gli ID dei nodi sono i codici hash ottenuti dagli indirizzi IP Gli ID delle chiavi sono i codici hash ottenuti dalle chiavi NOTA: gli ID dei nodi e gli ID delle chiavi sono nello stesso spazio m=3 #bit chiave

44 44/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Metrica di distanza in CHORD (1/2) La chiave k è assegnata al primo nodo n il cui identificatore è uguale o maggiore all’identifcatore di k nello spazio degli identificatori La metrica di distanza in CHORD è la differenza lineare Si dice n=successor(k) n, il nodo responsabile di k è detto successore di k CHORD espone la chiamata find_successor per localizzarlo

45 45/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Metrica di distanza in CHORD (2/2) La metrica di distanza è unidirezionale Data una distanza D e un nodo x, esiste un solo nodo y per cui d(x,y) = D Tutti i lookup per una stessa chiave convergono sullo stesso path E’ utile fare caching dei risultati dei lookup sui nodi intermedi

46 46/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD: lookup scalabile (1/6) Per fare le ricerche ogni nodo in teoria ha bisogno solamente di conoscere il nodo che segue CHORD assicura la validità di questi puntatori Tuttavia questo è un approccio non ottimale Ricerca lineare Chiave 5 Dove si trova la chiave 5?

47 47/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD: lookup scalabile (2/6) Si suppone che il nodo abbia informazioni su TUTTI gli altri nodi (routing table completa) Impraticabile: richiede N entry nella routing table! Chiave 5 Dove si trova la chiave 5?

48 48/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD: lookup scalabile (3/6) Per ottimizzare CHORD mantiene le finger table -iesima entry = identità di s = successor(n + ) con Al più m nodi, a regime O(log(n)) distinti in finger table s è detto –iesima finger del nodo n La entry contiene l’ID del nodo e il suo IP il primo finger è l’immediato successore del nodo sull’anello Finger table(1) Valore ientry 1successor(2)=3 2successor(3)=3 3successor(5)= m=3 #bit chiave

49 49/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD: lookup scalabile (5/6) finger[i].start = (n + ) mod La entry –iesima della finger table copre l’intervallo [finger[i].start, finger[i+1].start) “succ” è il successore di (n + )mod m=3 #bit chiave

50 50/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD: lookup scalabile (4/6) Algoritmo di lookup: Cerco la chiave k partendo dal nodo n k (n’,n’.successor] ? Cerco nella finger table di n il nodo n’ con l’identificativo più grande che sia minore di k n’.successor è il nodo responsabile di k n=n’ No Sì

51 51/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Nodo 3 vuole trovare chi gestisce la chiave 1 (= successor(1)) 1 [7,3) : quindi 3 manda una query al nodo 0 (entry #3 della finger table) 1 [1,2): il nodo 0 conosce successor (1) e lo dice a 3 CHORD: lookup scalabile (5/6) Esempio:

52 52/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD: lookup scalabile (6/6) Si dimostra che con buona probabilità il numero di nodi da contattare per trovare successor(k) è O(log(N)) (N=num totale nodi) Dimostrazione: Sia n il nodo che cerca k e p=predecessore (k) f = -iesima finger n Finger[i].start n + Finger[i+1].start fp d(f,n),d(p,f) => Al massimo d(p,f) = (1/2)*d(p,n) => A ogni passo la distanza da p si dimezza => Se d(p,n) = e a ogni passo si dimezza, in m passi si arriva

53 53/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD: join dei nodi (1/2) L’entrata o l’uscita dei nodi nell’overlay può avvenire in qualsiasi momento Perché tutto funzioni si DEVE garantire che: Il successore di ogni nodo sia noto Per ogni chiave k, successor(k) ne è responsabile Inoltre è auspicabile che le finger table siano corrette Ogni nodo mantiene anche un puntatore al nodo che lo precede (predecessore)

54 54/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD: join dei nodi (2/2) Per garantire tutto questo, al join di un nodo n si deve: Inizializzare predecessore e finger di n Aggiornare le finger e i predecessori degli altri nodi per tenere conto di n Il nodo n deve entrare nelle finger table degli altri Muovere sul nodo n tutte le chiavi di cui è responsabile N diventa responsabile solo per parte delle chiavi contenute nel suo successore Basta contattare un solo nodo

55 55/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Stabilizzazione (1/2) Un join di un nodo richiede una serie di operazioni complesse Le finger table dei nodi possono risultare compromesse I puntatori a successore dei nodi possono risultare compromessi Cosa può succedere a un lookup dopo la join di un nuovo nodo? Niente, tutte le finger table sono già coerenti… Complessità O(log(N)) … oppure il lookup è lento Finger table non aggiornate, ma puntatori ai successori corretti … o peggio il lookup fallisce Finger table e puntatori ai successori non coerenti

56 56/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Stabilizzazione (2/2) Soluzione: la stabilizzazione La join inserisce il nodo nell’anello SENZA informare gli altri della sua presenza Ogni nodo esegue periodicamente la procedura di stabilizzazione La stabilizzazione consente di rilevare la presenza del nuovo nodo Questa procedura serve a garantire la coerenza dei puntatori a successore Vengono riverificate le entry dei nodi successori delle finger table con delle operazioni di lookup Questo garantisce la coerenza delle finger table

57 57/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD: uscita dei nodi L’uscita dei nodi si potrebbe trattare come una failure degli stessi e non fare nulla La stabilizzazione gestirebbe l’uscita automaticamente: approccio inefficiente Per ottimizzare, quando un nodo esce dall’overlay (graceful leave): Trasferisce le chiavi di cui è responsabile al suo successore Aggiorna il puntatore al nodo che lo precede del nodo che lo segue sull’anello Aggiorna il puntatore al nodo che lo segue del nodo che lo precede sull’anello

58 58/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero CHORD: ridondanza informazioni Perché CHORD funzioni occorre che ogni nodo conosca il suo immediato successore sull’anello Per evitare problemi dovuti a failure dei nodi, ogni nodo mantiene una lista dei nodi che lo seguono (lista di successori) Nel caso in cui un nodo non è utilizzabile attraverso la lista di successori è possibile individuare percorsi alternativi. Per tenere conto delle liste di successori occorre modificare opportunamente le operazioni svolte durante la stabilizzazione

59 59/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia Sistema di lookup che utilizza una metrica di distanza basata su XOR Date due chiavi x e y la loro distanza è d(x,y)=x xor y Xor bit a bit Realizza una topologia ad albero basata sulla metrica Kademlia utilizza query parallele asincrone Gli identifcatori delle risorse sono chiavi su 160 bit (SHA-1)

60 60/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Proprietà della metrica Lo XOR è unidirezionale Data una distanza D e un nodo x, esiste un solo nodo y per cui d(x,y) = D Tutti i lookup convergono sugli stessi path E’ utile fare caching dei risultati dei lookup sui nodi intermedi Lo XOR è simmetrico d(x,y) = d(y,x) La metrica viene usata per popolare le routing table dei nodi Se x è nella routing table di y, x è nella routing table di y I refesh delle routing table sono eseguiti direttamente durante le operazioni normali fra i nodi La stabilizzazione è meno problemantica

61 61/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: binary tree Kademlia tratta i nodi come foglie di un albero binario La posizione di un nodo è determinata dal suo prefisso univoco più corto Il primo sottoalbero a sinistra è la prima metà che non contiene il nodo e così via, recursivamente Kademlia garantisce che il nodo con prefisso univoco 000 conosca almeno un nodo in ciascuno degli altri sottoalberi

62 62/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: binary tree Grazie alla conoscenza di tutti i sotto alberi ogni nodo può trovare qualsiasi altro nodo dell’albero Un nodo attraverso la sua routing table riesce a localizzare in una serie di passaggi successivi qualsiasi nodo sull’albero in modo ottimale La routing table è organizzata come un insieme di k-bucket

63 63/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: k-buckets (1/5) Per ogni 0 i per i nodi che distano tra 2^i e 2^(i+1) da se => k-buckets 0 [1,2) 1 [2,4) 2 [4,0) m=3 #bit chiave nodo1 K-bucket nodo2nodo3nodo4nodo5 K = numero massimo di elementi in un k-bucket: parametro di sistema fisso (qui k=2) Tabella nodo 0

64 64/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: k-buckets (2/5) Quando un nodo riceve un quasliasi messaggio, aggiorna il k- bucket corrsipondente Algoritmo (il nodo A riceve un messaggio dal nodo B):

65 65/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: k-buckets (3/5) Esempio: 0 [1,2) 1 [2,4) 2 [4,0) nodo4 Tabella nodo 0 nodo5nodo4 nodo2nodo3nodo1 1.6 manda un messaggio a 0, ma il k-bucket è pieno (k=2) 2.0 interroga risponde e viene spostato al fondo (6 è fuori) m=3; k=2

66 66/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: k-buckets (4/5) Esempio: 0 [1,2) 1 [2,4) 2 [4,0) nodo4 Tabella nodo 0 nodo5nodo6 nodo2nodo3nodo1 m=3; k=2 miss 1.6 manda un messaggio a 0, ma il k-bucket è pieno (k=2) 2.0 interroga 4 (nodo in testa) 3.4 non risponde: 6 è messo in fondo al k-bucket

67 67/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: k-buckets (5/5) 0 [ 1,2) 1 [2,4) 2 [4,0) 1 23 Tabella nodo Tabella nodo 0 45 k-bucket 2 k-bucket 0 k-bucket 1 66

68 68/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia offre 4 funzioni: PING: verifica se un nodo è attivo STORE: memorizza la coppia nel nodo più vicino alla chiave Le informazioni vengono replicate FIND_NODE: data una chiave ritorna (IP, porta, NodeID) per i k nodi più vicini alla chiave. I k nodi possono provenire da più k-bucket se il k- bucket più vicino non è pieno FIND_VALUE: variante della precedente per ottenere un valore data una chiave Kademlia: metodi esportati STORE(chiave)

69 69/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: node lookup (1/4) Obiettivo: localizzare il nodo più vicino a un Node ID A. Se il nodo 1 vuole contattare il nodo 5: Nodo 1 manda FIND_NODE(5) a uno dei nodi nel k-bucket 1--. (perche il bucket 1– è il più vicino a 5) (si suppone che 5 non sia nei k-bucket di 1)

70 70/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: node lookup (2/4) Il nodo 6 ritorna al nodo 1 l’indirizzo del nodo 4 (il più vicino a 5) (si suppone che 5 non sia nei k-bucket di 6) 3.Il nodo 1 manda una FIND_NODE(5) al nodo 4

71 71/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: node lookup (3/4) Il nodo 4 risponde infine al nodo 1 dicendogli l’indirizzo del nodo 5 5.Il nodo 1 può contattare il nodo 5

72 72/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: node lookup (4/4) E’ possibile dimostrare che il numero di passi per localizzare un nodo è logaritmico Nell’algoritmo reale vengono inviate più richieste in parallelo Si manda un numero di richieste < k In questo modo si evitano problemi con i timeout dei nodi offline Le risposte alle richieste contengono i k nodi più vicini L’algoritmo recursivo termina quando i k nodi più vicini al nodo destinazione hanno risposto

73 73/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: join, leave Per fare join un nodo n deve conoscere in qualche modo un nodo w dentro l'overlay. Procedura di join: 1) n inserisce w nel k-bucket relativo 2) Fa un lookup di se stesso attraverso w Trova così il suo successore (nodo responsabile) 3) farà un refresh di tutti i suoi k bucket effettua ricerche nei range degli ID gestiti da ogni k-bucket L’uscita di un nodo non richiede operazioni aggiuntive

74 74/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Kademlia: refresh periodico i k-bucket sono rinfrescati periodicamente dal passaggio delle richieste attraverso i vari nodi. Può tuttavia accadere che uno specifico k- bucket non sia rinfrescato per un certo periodo mancanza di richieste sui nodi del range coperto dal k-bucket Per questa ragione un refresh viene effettuato entro un'ora si prende a caso un ID all'interno del range del bucket e se ne fa il lookup

75 75/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Confonto tra CHORD e Kademlia In CHORD la routing table è rigida Richiede costose operazioni per essere mantenuta in caso di failure di un nodo Kademlia offre una routing table flessibile Metrica di distanza simmetrica oltre che unidirezionale Esiste sempre più di un percorso alternativo Le ricerche sono parallelizzate La manutenzione della routing table è più bassa I k-bucket sono liste di nodi: maggiore robustezza E’ possibile dimostrare che il numero di entry nella routing table di Kademlia è logaritmico

76 76/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Limiti delle DHT (1/3) I client p2p sono transienti per natura Il tempo di connessione media per un nodo è di 60min In Gnutella se un nodo perde tutti i vicini prova semplicemente a riconnettersi Nelle DHT il problema è più grave (almeno in CHORD) L’uscita di un nodo graceful (=“annunciata”) comporta in genere O(log(n)) operazioni per mantenere coerenti le strutture dati Un uscita graceless (senza annuncio è trasferimento preventivo di informazioni di stato) ha esiti peggiori Richiede tempo per: Rilevare la failure Replicare i dati persi dal peer disconnesso

77 77/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Limiti delle DHT (2/3) Le ricerche di parole chiave sono più numerose delle ricerche esatte Le DHT si prestano a ricerche esatte Dato il nome esatto di un file lo localizzano E’ possibile implementare richerche per parole chiave nelle DHT, ma è costoso Le p2p non strutturate non hanno di questi problemi: perché le ricerche si fanno sulla base di informazioni contenute nei singoli nodi Le DHT trovano un ago in un pagliaio, i p2p non strutturati no Gnutella non può garantire di poter trovare una singola copia di un file a meno che la query non raggiunge tutti i nodi

78 78/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Limiti delle DHT (3/3) Tuttavia la distribuzione delle richieste privilegia i file più replicati Questo limita gli svantaggi delle reti non strutturate

79 79/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Bittorent (1/2) La rete Bittorrent si basa su tracker Spesso integrato con servizio di lookup Il tracker è un web server che offre supporto per il download I Bittorrent indexer localizzano i file Per condividere un file il client creano un torrent Il torrent è un metadata che descrive il file La pubblicazione di un file su Bittorrent richiede: Creazione di un file “.torrent” che descrive un file Creare un tracker per quel file sul webserver locale Creare una copia “seed” per quel download La copia seed altro non è che una copia integrale del file

80 80/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero BitTorrent Scopo: razionalizzare le risorse di rete = banda e spazio sui dischi Gli algoritmi visti fino ad ora mirano ad un lookup il più veloce possibile BitTorrent mira a garantire la massima replicabilità delle risorse Componenti base: Torrent = descrittore del file Tracker Entità centralizzata che gestisce il download Peer: Seeders: hanno una copia integrale del file Leechers: non hanno ancora una copia intera

81 81/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero BitTorrent: funzionamento di base Un peer ricava in qualche modo un torrent Tipicamente da web server Il torrent contiene l’indirizzo del tracker Il peer contatta il tracker e fa la join del torrent Il tracker ritorna gli indirizzi di almeno 50 peer che gestiscono il file Il peer mantiene connessioni con almeno 20 Se fallisce ricontatta il tracker Ogni peer che ha fatto la join ogni 30 minuti invia un report al tracker

82 82/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero BitTorrent: tecniche di swarming Il file è suddiviso in chunk Tipicamente da 256 kB I chunk sono scambiati tra i peer In questo modo è possibile scaricare in parallelo i chunk Download paralleli di chunk diversi da peer diversi Ogni volta che un peer ottiene un chunk, informa i peer a lui collegati

83 83/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero BitTorrent: choke e unchoke Un peer manda dati a peer che ne hanno mandati a lui Tit-for-tat Ogni peer serve al più 4 peer Se seeder cerca i 4 migliori downloader In termini di bit rate Se leecher cerca i 4 migliori uploader Questo è realizzato con choke/unchoke Choke: mi rifiuto di servire un peer Un leecher si collega i 4 migliori uploader e fa choke con gli altri Un seeder si collega i 4 migliori downloader e fa choke con gli altri Optimistic unchoke: Ogni 30 s un peer scarta uno dei 4 peer ottimali Posso scoprire così nuovi peer

84 84/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero BitTorrent trackerless Ogni client diventa un un tracker leggero I client sono organizzati in una DHT L’algoritmo DHT usato è Kadmelia Kadmelia permette di memorizzare e localizzare ontatti per interagire con altri peer

85 85/71 3/11/2006 Algoritmi per protocolli peer-to-peer - Torrero Conclusioni Le reti peer-to-peer permettono un miglior sfruttamento delle risorse delle reti Partite da un approccio parzialmente client/server si sono evolute verso un peer- to-peer puro Le DHT hanno migliorato le caratteristiche di scalabiltà delle reti gerarchiche Tuttavia vanno incontro a un certo overhead di gestione Attraverso successivi sviluppi le DHT stanno riducendo l’overhead, fornendo una sempre più una alternativa concreta alle reti non strutturate


Scaricare ppt "3/11/2006 Algoritmi per protocolli peer-to-peer Netgroup – Politecnico di Torino Livio Torrero –"

Presentazioni simili


Annunci Google