Algoritmi per protocolli peer-to-peer

1
Algoritmi per protocolli peer-to-peer

• Netgroup Politecnico di Torino
• Livio Torrero livio.torrero_at_polito.it

2
Approccio client-server
Client 1
Client 3
Server
Client 2
Client 4

• 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

3
Paradigma peer-to-peer (1/2)
Peer 1
Peer 3
Peer 2
Peer 4

• 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

4
Overlay peer-to-peer

• I peer si organizzano in un overlay
• Loverlay è una rete sulla rete
• I peer si organizzano creando dei link virtuali
  fra loro
• Normalmente nelloverlay esistono più copie della
  stessa risorsa per massimizzarne la
  raggiungibilità

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

• Prime implementazioni di infrastrutture peer
• Approccio ancora fortemente simile al client
  server
• Basate su nodi fissi
• Colli di bottiglia gt non scalano
• Single point of failure gt infrastruttura fragile
• Napster è un esempio di approccio centralizzato

8
Napster introduzione

• Nato come applicativo per lo scambio di file
  musicali
• Nel 1999 le major disocgrafiche fanno causa a
  Napster gt 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
Funzionamento di Napster

• Quando un nodo entra nellinfrastruttura 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
query
Server centrale
Peer
answer
Server centrale
Peer
Download
Peer
10
Classificazione infrastrutture peer-to-peer
(tecniche di lookup)approccio non centralizzato
Infrastrutture peer-to-peer
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?

11
Approcci non centralizzati
Approccio decentralizzato
non strutturato
strutturato

• Lapproccio 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

12
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
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
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 gt upload 10kB/s, download 20kB/s

15
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 dalloverlay (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
  unora

16
Perché una rete a 2 livelli?

• La divisione tra ultrapeer e nodi normali
  permette solo ai nodi migliori entrare
  nelloverlay
• Gli host lenti rallenterebbero le prestazioni
  dellintero sistema se posti nelloverlay
• Loverlay diventa più piccolo ma più funzionale
• Dal punto di vista dei nodi leaf gli ultra-peer
  sono dei server

17
Gnutella overlay discovery

• Un nodo per accedere alloverlay 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
Gnutella handshake

• Ogni connessione Gnutella comincia con un
  handshake
• Un nodo accede alloverlay 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 ltnomegtltvalore1gt,ltvalore
  2gt
• 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
19
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-Ultrapeerfalse
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-Ultrapeerfalse
NAT
GNUTELLA/0.6 200 OK Listen-IP68.37.233.449376 Re
mote-IP 217.254.98.153

• Un ultrapeer si connette a un ultrapeer

ultrapeer
ultrapeer
GNUTELLA connect/0.6 X-Ultrapeertrue
GNUTELLA/0.6 200 OK
20
Esempi di handshake Gnutella(2/2)

• Un nodo si connette a un ultrapeer che rifiuta la
  connessione
• Lultrapeer deve fornire ultrapeer alternativi

ultrapeer
Nodo Gnutella generico
GNUTELLA connect/0.6
GNUTELLA/0.6 service unavailable X-Try-Ultrapeers
68.37.233.449376, 172.195.105.2183988

• Un nodo si connette a un ultrapeer che accetta e
  fornisce indirizzi alternativi
• È consigliato fornire altri ultrapeer a cui
  connettersi
• Limewire ne fornsice 10

ultrapeer
Nodo Gnutella generico
GNUTELLA connect/0.6
GNUTELLA/0.6 200 OK X-Try-Ultrapeers68.37.233.44
9376, 172.195.105.2183988
21
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 lultrapeer lo rifiuta, torna leaf per
  unaltra 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
22
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
Lookup in Gnutella introduzione

• Lalgoritmo 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
Dynamic Querying search our leaves

• Lultrapeer manda a tutti i suoi nodi foglia una
  query di lookup con TTL1
• Dopo linvio si attende per 2,4s
• I nodi foglia che hanno copia della risorsa
  risponderanno alla query

leaf
leaf
ultrapeer
leaf
Answer
leaf
25
Dynamic Querying probe query

• Lultrapeer manda a tutti gli ultrapeer ad esso
  collegati una query di lookup con TTL1
• Gli Ultrapeer che hanno copia della risorsa
  risponderanno alla query
• Gli ulrapeer inoltrano la richiesta ai loro nodi
  leaf
• Reimpostano TTL1
• Questa query serve a stimare la popolarità della
  risorsa
• Se si ottengono 150 risposte positive in tutto
  lalgoritmo finisce

ultrapeer
leaf
Answer
ultrapeer
ultrapeer
Answer
leaf
ultrapeer
26
Dynamic Querying controlled broadcasting

• Ogni 2.4s ultrapeer manda una query a uno solo
  degli ultrapeer connessi
• TTL2 oppure TTL3 a seconda del numero di
  risposte ottenute nella fase precedente
• Se si ottengono 150 risposte positive lalgoritmo
  finisce
• Se trascorrono più di 200s dallinizio della
  ricerca lalgoritmo è 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
Ricerca TTL2 e ricerca TTL3
Leaf 1
TTL1
TTL2
Ultrapeer B
Ultrapeer A
Ultrapeer C
Leaf 2

• A inizia la ricerca manda query con TTL2 SOLO a
  B
• B decrementa il TTLgt TTL1
• TTLltgt0 gt inoltra la query a TUTTI gli ultrapeer
  ad esso collegati (in figura, C è il solo
  connesso)
• C decrementa il TTL gt TTL0
• TTL0 gt inoltra la query a TUTTI i leaf ad esso
  collegati
• La TTL3 funziona nello stesso modo (TTL3)
• la ricerca coinvolge un numero elevato di
  ultrapeer
• Limewire non usa MAI TTLgt3

28
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 lutente del nodo leaf non vuole rispondere
  alle query, è inutile propagargli la query
• Il QRP a questo scopo permette al nodo leaf di
  mandare allultrapeer una descrizione delle
  risorse gestite
• Le informazioni sono contenute nella QRP table
• Inviata dopo la connessione
• Appositi messaggi permettono laggiornamento
  delle informazioni della QRP table

29
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 lhash 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 dellultrapeer
• Last hop saving
• Se un ultrapeer riceve query con TTL1 e la QRP
  table composita blocca, la query non è inoltrata

30
Kazaa introduzione

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

31
Kazaa overlay gerarchico
SN
SN
ON
ON
SN
SN

• 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

32
Kazaa ingresso nella rete

• Ogni nodo mantiene una cache di SN (SN cache
  list)
• Esistono default server se la cache è vuota
• Allinizio un ON prova tutti i SN nella sua cache
  con pacchetti UDP
• LON inizia connessioni TCP simultanee con più SN
• LON seleziona un SN e si disconnette dagli altri

SN
ON
SN
33
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
34
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 dellRTT (il 60
  dei nodi in cache list RTTlt50ms)

SN
ON
Lista SN alternativi
35
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
SN 1
SN 3
Query(Gatto)
Query(Gatto)
36
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
  dallinsieme 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
Answer
SN
ON
37
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
SN
1Downolad_req
3GIVE
3GIVE
NAT
Kazaa peer
ON A
38
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

39
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 ltchiave, valoregt
• Il nodo che memorizza la coppia ltchiave, valoregt
  è 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
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 dellinfrastruttura
• 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
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
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
  lindirizzo IP del nodo responsabile per la
  chiave
• CHORD si basa sul consistent hashing

43
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 luniformità della distribuzione
  delle chiavi sui nodi
• Il consistent hashing organizza i nodi in un
  cerchio modulo
• (m bit ID)
• Lalgoritmo 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

0
1
m3 bit chiave
6
2
3
4
44
Metrica di distanza in CHORD (1/2)

• La chiave k è assegnata al primo nodo n il cui
  identificatore è uguale o maggiore
  allidentifcatore di k nello spazio degli
  identificatori
• La metrica di distanza in CHORD è la differenza
  lineare
• Si dice nsuccessor(k)
• n, il nodo responsabile di k è detto successore
  di k
• CHORD espone la chiamata find_successor per
  localizzarlo

45
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
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

47
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!

48
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 lID del nodo e il suo IP
• il primo finger è limmediato successore del nodo
  sullanello

Finger table(1)
0
m3 bit chiave
1
Valore i entry
1 successor(2)3
2 successor(3)3
3 successor(5)0
3
49
CHORD lookup scalabile (5/6)

• fingeri.start (n ) mod
• La entry iesima della finger table copre
  lintervallo fingeri.start, fingeri1.start)
• succ è il successore di (n )mod

m3 bit chiave
50
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
lidentificativo più grande che sia minore di k
No
nn
Sì
n.successor è il nodo responsabile di k
51
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

52
CHORD lookup scalabile (6/6)

• Si dimostra che con buona probabilità il numero
  di nodi da contattare per trovare successor(k) è
  O(log(N)) (Nnum totale nodi)
• Dimostrazione
• Sia n il nodo che cerca k e ppredecessore (k)
• f -iesima finger

f
p
n
Fingeri.start
Fingeri1.start
gt Al massimo d(p,f) (1/2)d(p,n)
gt A ogni passo la distanza da p si dimezza
gt Se d(p,n) e a ogni passo si dimezza,
in m passi si arriva
53
CHORD join dei nodi (1/2)

• Lentrata o luscita dei nodi nelloverlay 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
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
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
Stabilizzazione (2/2)

• Soluzione la stabilizzazione
• La join inserisce il nodo nellanello 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
CHORD uscita dei nodi

• Luscita dei nodi si potrebbe trattare come una
  failure degli stessi e non fare nulla
• La stabilizzazione gestirebbe luscita
  automaticamente approccio inefficiente
• Per ottimizzare, quando un nodo esce dalloverlay
  (graceful leave)
• Trasferisce le chiavi di cui è responsabile al
  suo successore
• Aggiorna il puntatore al nodo che lo precede del
  nodo che lo segue sullanello
• Aggiorna il puntatore al nodo che lo segue del
  nodo che lo precede sullanello

58
CHORD ridondanza informazioni

• Perché CHORD funzioni occorre che ogni nodo
  conosca il suo immediato successore sullanello
• 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
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
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
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
Kademlia binary tree

• Grazie alla conoscenza di tutti i sotto alberi
  ogni nodo può trovare qualsiasi altro nodo
  dellalbero
• Un nodo attraverso la sua routing table riesce a
  localizzare in una serie di passaggi successivi
  qualsiasi nodo sullalbero in modo ottimale
• La routing table è organizzata come un insieme di
  k-bucket

63
Kademlia k-buckets (1/5)

• Per ogni 0 ilt160, ogni nodo ha una lista di
  ltIP,porta,NodeIDgt per i nodi che distano tra 2i
  e 2(i1) da se gt k-buckets

m3 bit chiave
Tabella nodo 0
0 1,2)
1 2,4)
2 4,0)
K-bucket
K numero massimo di elementi in un k-bucket
parametro di sistema fisso (qui k2)
64
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
Kademlia k-buckets (3/5)

• Esempio

Tabella nodo 0
0 1,2)
1 2,4)
2 4,0)
nodo5
nodo4
m3 k2

1. 6 manda un messaggio a 0, ma il k-bucket è pieno
   (k2)

1. 0 interroga 4

1. 4 risponde e viene spostato al fondo (6 è fuori)

66
Kademlia k-buckets (4/5)

• Esempio

Tabella nodo 0
0 1,2)
1 2,4)
2 4,0)
nodo5
nodo6
m3 k2
miss

1. 6 manda un messaggio a 0, ma il k-bucket è pieno
   (k2)

1. 0 interroga 4 (nodo in testa)

1. 4 non risponde 6 è messo in fondo al k-bucket

67
Kademlia k-buckets (5/5)
Tabella nodo 0
Tabella nodo 0
1
0 1,2)
1 2,4)
2 4,0)
1
0 000-
1 001-
2 01--
k-bucket 1
k-bucket 2
k-bucket 0
68
Kademlia metodi esportati

• Kademlia offre 4 funzioni
• PING verifica se un nodo è attivo
• STORE memorizza la coppia ltchiave, valoregt 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

ltchiave, valoregt
STORE(chiave)
69
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

0
1
1
0
1
0
0
1
0
1
0
1
6
0
1
2
3
4
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
Kademlia node lookup (2/4)
0
1
1
0
1
0
6
0
1
0
1
0
1
0
1
2
3
4
5

• Il nodo 6 ritorna al nodo 1 lindirizzo 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

71
Kademlia node lookup (3/4)
0
1
1
0
1
0
6
0
1
0
1
0
1
0
1
2
3
4
5

• Il nodo 4 risponde infine al nodo 1 dicendogli
  lindirizzo del nodo 5
• Il nodo 1 può contattare il nodo 5

72
Kademlia node lookup (4/4)

• E possibile dimostrare che il numero di passi
  per localizzare un nodo è logaritmico
• Nellalgoritmo reale vengono inviate più
  richieste in parallelo
• Si manda un numero di richieste lt k
• In questo modo si evitano problemi con i timeout
  dei nodi offline
• Le risposte alle richieste contengono i k nodi
  più vicini
• Lalgoritmo recursivo termina quando i k nodi più
  vicini al nodo destinazione hanno risposto

73
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
• Luscita di un nodo non richiede operazioni
  aggiuntive

74
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
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
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)
• Luscita 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
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
Limiti delle DHT (3/3)

• Tuttavia la distribuzione delle richieste
  privilegia i file più replicati
• Questo limita gli svantaggi delle reti non
  strutturate

79
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
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
BitTorrent funzionamento di base

• Un peer ricava in qualche modo un torrent
• Tipicamente da web server
• Il torrent contiene lindirizzo 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
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
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
BitTorrent trackerless

• Ogni client diventa un un tracker leggero
• I client sono organizzati in una DHT
• Lalgoritmo DHT usato è Kadmelia
• Kadmelia permette di memorizzare e localizzare
  ontatti per interagire con altri peer

85
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 loverhead, fornendo una sempre più una
  alternativa concreta alle reti non strutturate