Condivisione file P2P
 All’inizio del 2004 P2P era responsabile di un volume
di traffico maggiore a qualunque altra applicazione
Internet
 Scenario di Riferimento: File Sharing
 Giulia cerca un brano MP3
 Il sistema fornisce una lista dei peer che
possiedono il brano
 Giulia richiede il brano a uno dei peer (Roberto)
 Connessione diretta TCP tra il PC di Giulia e
quello do Roberto
 Contemporaneamente Mario scarica da Giulia
un’altro brano
 Client/Server transitorio
1: Introduction
1
Architettura centralizzata
(NAPSTER)
 Directory centralizzata
 Il peer informa la
directory centralizzata
del proprio IP e degli
oggetti disponibili
 La directory deve
conoscere i peer attivi
 Unico punto di guasto
 Collo di bottiglia per le
prestazioni
 Diritti d’autore
1: Introduction
2
In sintesi
 Directory Centralizzata
Trasferimento tra peer distribuito
 Processo di localizzazione dei contenuti
centralizzato

 Query flooding (GNUTELLA)
1: Introduction
3
Query flooding (GNUTELLA)
 Approccio
completamente
distribuito per la
localizzazione dei
contenuti
 OVERLAY
NETWORK


arco tra due peer
se esiste una
comunicazione TCP
tra di essi
Solitamente meno
di 10 vicini
1: Introduction
4
Query flooding (GNUTELLA)
 Giulia vuole localizzare
“one.mp3”



Invia una Gnutella query a
tutti i suoi vicini sulla overlay
network
I vicini a loro volta inoltrano la
query ai propri vicini
I peer che possiedono
“one.mp3” generano un query
hit, che segue il percorso
inverso della Gnutella Query,
fino a Giulia
 In questo modo Giulia conosce
chi possiede “one.mp3” (anche
+ di uno) e lo può contattre
direttamente per trasferire il
file
1: Introduction
5
Scalabililtà
 Query flooding  significativa quantità di
traffico
 Query flooding a raggio limitato (TTL, #hop)
 Riduzione traffico
 riduzione peer
contattati  minor
probabilità di
trovare i files
1: Introduction
6
Problematiche di gestione dei Peer
 Devo trovare qualche peer (problema di
bootstrap)
Mantenere elenco peer connessi di frequente
 Sito Gnutella con tale elenco

 Una volta stabilità una connessione con
almeno un peer
Conscenza di altri peer (PING/PONG)
 Instaurazione di connessioni con alcuni di tali
peer per aumentare gli archi della overlay
network

1: Introduction
7
Sistemi ibridi (KaZaA)
 Prende in prestito concetti di Napster e
Gnutella
 Tecnologia proprietaria e traffico di
controllo criptato  no dettagli, ma
principi (kazaa-lite reverse engineering)
 Come Gnutella: non usa server dedicati per
localizzare i contenuti
 A differenza di Gnutella: non tutti I peer
sono uguali. Quelli dotati di maggior banda
sono designati leader di gruppo
1: Introduction
8
Sistemi ibridi (KaZaA)
 I leader di gruppo sovrintendono a
centinaia di peer ordinari che comunicano al
proprio leader i contenuti che mettono a
disposizone (tipo Napster a livello locale)
 I vari leader sono collegati tra loro da una
overlay network
1: Introduction
9
Tecniche per migliorare le
prestazioni
 Accodamento delle richieste di upload

Limita il numero di upload simultanei in modo
che la banda a disposizione per ciscun upload
abbia un limite inferiore
 Priorità di incentivo
 Chi collabora alla condivisione dei contenuti è
privilegiato nello scaricare file
 Downloading parallelo

Vengono richieste porzioni diverse di un file a
peer distinti
1: Introduction
10
Riferimenti
 http://ntrg.cs.tcd.ie/undergrad/4ba2.02-
03/Intro.html
1: Introduction
11