Algoritmi per protocolli peer-to-peer Netgroup – Politecnico di Torino Livio Torrero – livio.torrero@polito.it

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…

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

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à

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

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

Classificazione infrastrutture peer-to-peer (tecniche di lookup): approccio centralizzato Approccio decentralizzato 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

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

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 Upload Server centrale query Server centrale Peer answer Peer Server centrale Download Peer

Classificazione infrastrutture peer-to-peer (tecniche di lookup): approccio non centralizzato Approccio centralizzato Approccio decentralizzato 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?

Approcci non centralizzati Approccio decentralizzato non strutturato strutturato 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

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

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

Gnutella(limewire): rete gerarchica (1/2) leaf leaf leaf ultrapeer ultrapeer ultrapeer ultrapeer leaf leaf leaf leaf 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

Gnutella(limewire): rete gerarchica (2/2) leaf leaf leaf ultrapeer ultrapeer ultrapeer ultrapeer leaf leaf leaf leaf 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

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

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

Host che riceve la connessione 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 <nome>:<valore1>,<valore2>… Ogni gruppo inizia con una greeting line che identifica il messaggio Handshake a 3 vie: Host che si connette Host che riceve la connessione CONNECT OK OK

Esempi di handshake Gnutella(1/2) Un nodo leaf si connette a un UltraPeer (connessione generica) 0.6 è la versione corrente di Gnutella leaf ultrapeer GNUTELLA connect/0.6 X-Ultrapeer=false GNUTELLA/0.6 200 OK 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 leaf ultrapeer 217.254.98.153 GNUTELLA connect/0.6 X-Ultrapeer=false NAT GNUTELLA/0.6 200 OK Listen-IP:68.37.233.44:9376 Remote-IP: 217.254.98.153 Un ultrapeer si connette a un ultrapeer ultrapeer ultrapeer GNUTELLA connect/0.6 X-Ultrapeer=true GNUTELLA/0.6 200 OK

Esempi di handshake Gnutella(2/2) Un nodo si connette a un ultrapeer che rifiuta la connessione L’ultrapeer deve fornire ultrapeer alternativi Nodo Gnutella generico ultrapeer GNUTELLA connect/0.6 GNUTELLA/0.6 service unavailable X-Try-Ultrapeers:68.37.233.44:9376, 172.195.105.218: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 Nodo Gnutella generico ultrapeer GNUTELLA connect/0.6 GNUTELLA/0.6 200 OK X-Try-Ultrapeers:68.37.233.44:9376, 172.195.105.218:3988…

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 1h ultrapeer leaf ultrapeer ultrapeer ultrapeer ultrapeer ultrapeer connect ultrapeer? ultrapeer ultrapeer ultrapeer ultrapeer Refuse connection ultrapeer? ultrapeer ultrapeer ultrapeer Leaf for 1h ultrapeer leaf (!) ultrapeer ultrapeer leaf connect ultrapeer

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

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

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 TTL=1 leaf TTL=1 ultrapeer TTL=1 TTL=1 leaf Answer leaf

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 leaf ultrapeer TTL=1 Answer ultrapeer TTL=1 ultrapeer TTL=1 TTL=1 Answer leaf ultrapeer

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

Ricerca TTL2 e ricerca TTL3 Leaf 1 TTL=2 TTL=1 Ultrapeer A Ultrapeer B Ultrapeer C Leaf 2 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

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

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

Kazaa: introduzione Kazaa è stato scritto da Niklas Zennstrom e Janus Friis nel 2001

Kazaa: overlay gerarchico SN SN TCP TCP ON TCP TCP TCP ON SN SN TCP 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

Kazaa: ingresso nella rete 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 L’ON inizia connessioni TCP simultanee con più SN L’ON seleziona un SN e si disconnette dagli altri SN ON UDP probe SN ON TCP connect disocnnect SN ON SN

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) SN ON Metadata

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) SN ON Lista SN alternativi

Kazaa: lookup delle risorse(1/2) Ricerca di blocchi di metadati che corrispondono alla parola chiave 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 ‘Gatto’ ? SN ON Query(‘Gatto’) Rispondo alla query Scelgo SN 3 SN Query(‘Gatto’) SN 1 SN 3 Query(‘Gatto’)

Kazaa: lookup delle risorse(2/2) Le risposte contengono i metadati relativi al file includendo le informazioni sui peer su cui si trovano 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 Se il download fallisce si cerca di nuovo il file direttamente con il contenthash (chash) ‘Gatto_bianco.txt’ ‘Gatto_nero.txt’ ON Answer SN ON Download(chash) SN ON Query(chash) SN

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 ON A chiede di iniziare attraverso il SN SN risponde con IP e porta del peer con il file Il peer con il file manda una richiesta a ON A: pin hole sul NAT ON A inizia il download come al solito NAT Kazaa peer ON A Downolad(chash) Downolad(chash) SN 1:Downolad_req 1:Downolad_req 2: peer info 3:GIVE NAT 3:GIVE Kazaa peer ON A 1:Downolad(chash) 2:Downolad(chash)

Approccio strutturato Approccio decentralizzato non strutturato 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

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 <chiave, valore> Il nodo che memorizza la coppia <chiave, valore> è 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

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.

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)

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

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 1 m=3 #bit chiave 6 2 3 4

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

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

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 1 4 3 6 2 Chiave 5 Dove si trova la chiave 5?

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! 1 4 3 6 2 Chiave 5 Dove si trova la chiave 5?

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) m=3 #bit chiave 1 Valore i entry 1 successor(2)=3 2 successor(3)=3 3 successor(5)=0 3

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

CHORD: lookup scalabile (4/6) Algoritmo di lookup: Cerco la chiave k partendo dal nodo n Cerco nella finger table di n il nodo n’ con l’identificativo più grande che sia minore di k k (n’,n’.successor] ? No n=n’ Sì n’.successor è il nodo responsabile di k

CHORD: lookup scalabile (5/6) Esempio: 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 (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 + f p n + n Finger[i].start Finger[i+1].start 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

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)

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

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

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

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

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

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)

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

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

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

Kademlia: k-buckets (1/5) Per ogni 0 i<160, ogni nodo ha una lista di <IP,porta,NodeID> per i nodi che distano tra 2^i e 2^(i+1) da se => k-buckets m=3 #bit chiave Tabella nodo 0 [1,2) 1 [2,4) 2 [4,0) nodo1 nodo2 nodo3 K-bucket nodo4 nodo5 K = numero massimo di elementi in un k-bucket: parametro di sistema fisso (qui k=2)

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):

Kademlia: k-buckets (3/5) Esempio: Tabella nodo 0 [1,2) 1 [2,4) 2 [4,0) nodo1 nodo2 nodo3 nodo4 nodo5 nodo4 m=3; k=2 6 manda un messaggio a 0, ma il k-bucket è pieno (k=2) 0 interroga 4 4 risponde e viene spostato al fondo (6 è fuori)

Kademlia: k-buckets (4/5) Esempio: Tabella nodo 0 [1,2) 1 [2,4) 2 [4,0) nodo1 nodo2 nodo3 nodo4 nodo5 nodo6 m=3; k=2 miss 6 manda un messaggio a 0, ma il k-bucket è pieno (k=2) 0 interroga 4 (nodo in testa) 4 non risponde: 6 è messo in fondo al k-bucket

Kademlia: k-buckets (5/5) Tabella nodo 0 Tabella nodo 0 1 [1,2) 1 [2,4) 2 [4,0) 1 000- 1 001- 2 01-- 2 3 2 3 4 5 6 4 5 6 k-bucket 1 k-bucket 2 k-bucket 0

Kademlia: metodi esportati Kademlia offre 4 funzioni: PING: verifica se un nodo è attivo STORE: memorizza la coppia <chiave, valore> 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 STORE(chiave) <chiave, valore>

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: 1 1 1 6 1 1 1 4 3 2 1 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)

Kademlia: node lookup (2/4) 1 1 1 6 1 1 1 5 4 3 2 1 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) Il nodo 1 manda una FIND_NODE(5) al nodo 4

Kademlia: node lookup (3/4) 1 1 1 6 1 1 1 5 4 3 2 1 Il nodo 4 risponde infine al nodo 1 dicendogli l’indirizzo del nodo 5 Il nodo 1 può contattare il nodo 5

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

Kademlia: join, leave Per fare join un nodo n deve conoscere in qualche modo un nodo w dentro l'overlay. Procedura di join: n inserisce w nel k-bucket relativo Fa un lookup di se stesso attraverso w Trova così il suo successore (nodo responsabile) 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

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

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

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

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

Limiti delle DHT (3/3) Tuttavia la distribuzione delle richieste privilegia i file più replicati Questo limita gli svantaggi delle reti non strutturate

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

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

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

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

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

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

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