Post on 23-Feb-2019
BitTorrent
Davide ChiarellaCorso di Sistemi Distribuiti P2P
a.a. 2005/2006
Cos’è BitTorrent?
BitTorrent è un sistema per la distribuzione e condivisione di file.
Scritto in Python da Bram Cohen, presentato al CodeCon nel 2002: il software è completamente free e open source.
Cerca di combattere il fenomeno del free-riding, implementando all’interno dei suoi algoritmi una strategia tit-for-tat.
E’ uno dei sistemi P2P più diffusi ed è responsabile di almeno il 35% del traffico internet (fonte CacheLogic).
Nasce dall’ultima esperienza lavorativa di Bram in un’azienda, dove si conservavano i file dei progetti divisi in parti crittografate, distribuite fra vari computer. Pensa di adattare l’idea al P2P.Il successo fu enorme: a dicembre del 2005 i download del software arrivarono a 40 milioni.
Definizioni
Le definizioni che seguono si possono ritenere una convenzione
all’interno di questo documento (alcune sono anche adottate
universalmente).
peer e client: un peer è un qualsiasi BitTorrent client che partecipa
alla diffusione del file; quando ci riferiamo a client intendiamo un
peer residente sulla macchina locale
seeder: un peer che possiede tutte le parti di un file
leecher : un peer che possiede qualche o nessuna parte di un file e
cerca il completamento del file
tracker: entità intermedia che informa il client dei peer connessi al
torrent
Definizioni II
torrent: file che contiene l’URL del tracker e le hash SHA1 delle
parti del file da scaricare
swarm: insieme di tutti i peer (compreso il client) che formano il
torrent
parte e blocco: un file nel protocollo BitTorrent è diviso in parti,
che a loro volta sono divise in sottoparti chiamate blocchi
ottimo paretiano o efficienza paretiana: si realizza l’ottimo
paretiano quando l’allocazione delle risorse è tale che non è
possibile migliorare la condizione di un soggetto senza peggiorare
la condizione di un altro
Definizioni III
bencode: è un modo di specificare e organizzare i dati, supporta i
tipi di dati:
stringhe <lunghezza>:<stringa> (e.g. 4:spam è la stringa spam)
interi i<intero>e (e.g. i3e è l’intero 3)
liste l<tipo bencode>e
dizionari d<stringa bencode><tipo bencode>e
screen scraping: attualmente è l’atto di “parsare” pagine HTML per
ottenere dati/informazioni contenute in esse
soffocare una connessione: quando si soffoca una connessione non
vengono trasferiti più parti e blocchi, ma solo dati di controllo della
connessione, che viene tenuta aperta
La genesi I
Scenario:
distribuzione di file di grandi dimensioni
1° problema: tutto il carico del trasferimento del file risiede sulla
macchina che lo ospita (client)
2° problema: la maggioranza delle linee degli utenti dei sistemi
P2P sono linee asimmetriche (più banda dedicata al download che
all’upload), quindi anche nel caso di due utenti con la stessa
connessione (ad esempio 4 Mbit/s di downlink e 600Kbit/s di uplink)
essi, anche volendo cooperare, non potranno mai scaricare con tutta
la loro banda di download disponibile, perché l’uplink del loro
partner risulta il bottleneck
La genesi II
come?
D 2Mb/ U 1Mb
D 2Mb/ U 1Mb
D 2Mb/ U 1Mb
tu scarichi da me se io scarico da te, il vecchio do ut des
idea principale: redistribuire il carico dell’upload su tutti i computer
che concorrono allo scaricamento del file. Una volta che un utente ha
parte del file incomincia lui stesso a fornire quella parte agli altri
utenti, alleggerendo il carico del detentore del file completo (seeder) e
permettendo così un possibile totale sfruttamento della banda di
download
BitTorrent: schema
Web server Tracker
Client
!!!!
BitTorrent: interfaccia
L’interfaccia uomo-sistema è stata scelta il più semplice possibile. Il
sistema non ha un motore di ricerca basato su metadati, ma si
appoggia su siti con hyperlink a file .torrent
8:announce
35:http://books.no-ip.org/announce.php
7:comment
78:A.Practical.Guide.to.Linux.Commands.Editors.and.Shell.Programming.Jul.2005.chm
10:created by
19:TorrentSpy/0.2.4.26
13:creation date
BitTorrent: il torrent I
L’utente incomincia il download del file dopo aver scaricato un file
.torrent contenente metadati come la lunghezza del file da scaricare, il
suo nome, informazioni di hashing e l’url del tracker. Il file .torrent è
scritto in bencoding ed utilizza il tipo di dato dizionario.
Inizio tipo dato dizionario
Inizio sequenza di semplici stringhe di byte
d
BitTorrent: il torrent IIi1147792122e
4:info
6:length
i3786069e
6:md5sum
32:f627b59a6148cc6e1ac1da5d74da3804
4:name
78:A.Practical.Guide.to.Linux.Commands.Editors.and.Shell.Programming.Jul.2005.chm
12:piece length
i262144e
6:pieces
300:zt� Vaá etc etc fino a 300 caratteri
7:private
i1e e
Un dizionario può contenere un altro dizionario: in caso di più file il dizionario info ha una lista di dizionari al suo interno, uno per ogni file
Tipo dato intero
Concatenazione delle hash SHA1
(20 byte ognuna => 15 parti)
d
e
Md5sum dell’intero file
Lunghezza intero file (bytes)
Sono parti da 256KB
BitTorrent: tracker
Il tracker è colui che tiene traccia di tutti gli utenti coinvolti nel
torrente di bit: il tracker comunica con gli altri peer tramite http e
https. Durante la loro comunicazione il client fornisce il nome del file
a cui è interessato, il suo indirizzo IP, la porta su cui è in ascolto e le
eventuali parti di file di cui è già in possesso. Il tracker risponde in
text/plain indicandogli una lista casuale di peer.
A questo punto il nuovo arrivato contatta gli altri peer e crea delle
connessioni dirette con essi e incomincia a scaricare il file.
BitTorrent: tracker e seeder II
Oltre a questa funzionalità il tracker fornisce anche un servizio di
monitorizzazione dello stato dei torrent chiamato “scrape page”, che
evita al client di fare screen scraping sulla pagina HTML del tracker:
ottiene subito i dati interessanti tramite HTTP GET direttamente da
esso.
E’ ovvio che almeno uno dei peer deve avere il file completo e
fornire della banda di upload agli altri utenti: questo “benefattore”
viene chiamato seeder.
Ma come avviene la pubblicazione di un file da parte di un seeder?
BitTorrent: pubblicazione
Per pubblicare un torrent si utilizzano dei programmi appositi che
creano il file dei metadati, riempendo tutti i campi. Una volta creato il
.torrent, esso si sottomette al tracker. Ovviamente bisogna rimanere
connessi con il file originale per un discreto periodo di tempo per
permettere il diffondersi di almeno tutte le parti del file.
Nei client che non hanno molta banda a disposizione si utilizza
l’algoritmo di super-seeding, per lo meno nel primo periodo di
attività del torrent.
BitTorrent: struttura dei file
BitTorrent divide i file in parti di una dimensione fissata, di solito
256 KB. Ogni frammento di file viene identificato da una funzione
hash SHA1: il risultato della funzione è noto poiché pubblicato sul
file .torrent. I dati vengono trasferiti tramite connessioni TCP: è
importante quindi avere sempre delle richieste in coda per evitare
grossi tempi d’attesa tra un invio e l’altro dei pezzi. Questo viene
evitato suddividendo ulteriormente le parti dei file in sottoparti di 16
KB, chiamate blocchi. In pipeline vengono sempre tenute almeno 5
richieste. Ogni volta che viene ricevuta una sottoparte ne viene subito
richiesta un’altra agli altri membri del swarm.
BitTorrent: selezione delle parti I
Selezionare le parti da inviare per prime è un compito per niente
banale per ottenere una buona performance del sistema. Si potrebbe
infatti arrivare ad una situazione in cui tutte le parti del file che uno
offre non siano richieste dai peer da cui stiamo scaricando.
A questo proposito BitTorrent applica una chiara politica di selezione
delle parti dei file.
BitTorrent: selezione delle parti II
Si segue una rigida politica per lo scaricamento delle parti del file
Strict priority (o policy): una volta che un blocco viene richiesto ad
un peer tutte le future richieste a quel peer riguarderanno i restanti
blocchi della parte. Questo permette di completare velocemente parti
intere del file.
Rarest First: quando il peer seleziona quale parte scaricare sceglie
sempre quella con la minore occorrenza all’interno del swarm.
Questa regola permette al peer di essere concorrenziale, possedendo
delle parti di file molto richieste egli può scambiarle più facilmente
con altri ricevendo in cambio altre parti di file. Questo metodo risulta
particolarmente utile sopratutto nel momento dell’introduzione di un
nuovo torrent, alleggerendo di molto il carico sul seeder originario.
BitTorrent: selezione delle parti III
Random first piece: l’unica eccezione alla regola del rarest first
accade quando si inizia il download di un file. Infatti le parti più rare
è facile che siano in possesso di pochi peer e, se si applicasse la
politica RF il download risulterebbe rallentato. Per questa ragione la
prima parte da scaricare viene scelta in modo casuale e solo dopo il
completamento del download di questa si applica la RF
Endgame mode: risulta molto utile quando il client ha un download
rate basso. Nel mezzo dello scaricamento fa parte del gioco, ma sul
finale può rallentare notevolmente la fine dello scaricamento. In
questo caso, quando il client ha ormai richiesto tutti i blocchi
mancanti, manda in broadcast a tutti i peer la richiesta e quando uno
di essi risponde avvisa che la richiesta per quel blocco è scaduta. Così
il finale del download risulta sempre veloce.
BitTorrent: esempio end-game
5 11
File diviso in 12 parti, da 10 blocchi ciascuna: esempio 5.1 il primo
blocco della quinta parte del file
5!
disi.mpg
BitTorrent: esempio end-game
File diviso in 12 parti, da 10 blocchi ciascuna: esempio 5.1 il primo
blocco della quinta parte del file
5.3
5.3 5.1
5.1
5 11 disi.mpg
BitTorrent: choking algorithm
In BitTorrent ogni client cerca di massimizzare il suo download rate
(dilemma del prigioniero). Cooperare = dare upload, defezionare =
soffocare l’upload. Il choking algorithm si occupa appunto di fare
questo: cerca di raggiungere l’ottimo paretiano.
L’atto del choking è un temporaneo rifiuto di upload: in ogni caso il
download può continuare e la connessione non deve essere
rinegoziata quando il soffocamento termina.
Ogni client coopera (fa l’unchoke) con un fissato numero di altri peer
(default 4), così il problema rimane nella selezione di chi non
soffocare. La decisione si basa sui vari download rate del client con i
peer connessi (e.g: a quanto sto scaricando dal peer A?).
BitTorrent: choking algorithm
Calcolare tuttavia il download rate corrente da un peer non è un problema banale. BitTorrent calcola la media per ciascuna connessione ogni 20 secondi (nelle prime versioni dell’algoritmo aveva un periodo di calcolo più lungo, ma ne risentiva l’efficienza a causa dell’alta variabilità della connessione TCP). Ogni dieci secondi si calcola la lista dei peer da soffocare e quelli con cui cooperare e si lascia la situazione com’è fino ai dieci secondi successivi: ergo ogni dieci secondi avviene il rechoking.
calcolo chi soffocare
applico la lista di
soffocamento
calcolo µ
BitTorrent: choking algorithm
La scelta di agire ogni dieci secondi è per evitare situazioni in cui
vengono sprecate risorse a causa dell’overhead di soffocamento e
cooperazione (10s in termini di connessione TCP sono un tempo
relativamente lungo per permettere il pieno sfruttamento del canale di
comunicazione).
Agendo solo in questo modo il client però non può scoprire se sul
mercato c’è qualcuno che può offrire più upload: è qui che entra in
gioco l’optimistic unchoking.
BitTorrent: optimistic unchoking
Ogni tre periodi di rechoke (30s), il client BitTorrent fa una mossa di
cooperazione gratuita (un TFT ritardato): in trenta secondi abbiamo
una situazione abbastanza stabile, poichè l’upload si è stabilizzato
reciprocando il download.
Questa regola viene chiamata optimistic unchoking.
?
client
BitTorrent: anti-snubbing
A volte però può accadere che un client venga soffocato da tutti i peer
da cui sta scaricando e che esso continui comunque a fornire upload.
Che accade in questa situazione? Normalmente questo evento
causerebbe una drastica diminuzione, se non un annullamento, del suo
download rate. Per mitigare questo problema un client che non riceve
da un dato peer parti/blocchi di un file per più di un minuto soffoca
subito la connessione, assumendo di essere stato snobbato dal peer in
questione, e da il via ad un optimistic unchoking.
Potrebbe continuare a cooperare con il peer snoob, solo se il peer
risultasse essere il bersaglio dell’optimistic unchoking o ricominciasse
a ricevere dati da esso.
BitTorrent: nuovo seeder e upload
Una volta che il client ha terminato lo scaricamento del file diventa da
leecher un seeder: il cooperatore per eccellenza.
A questo punto però il client non ha più i suoi valori di download rate
su cui basare le sue scelte.
Come agisce?
Sceglie di fare upload ai peer più “leecher”: potremmo chiamare
questo principio il principio di “leechest first”.
BitTorrent: miglioramenti?
Dalla versione 4 del protocollo è stata aggiunta una funzionalità più
business-friendly: tutto il traffico di rete creato da BitTorrent è segnato
come bulk. Questo permette a programmi di traffic-shaping di
riconoscerlo abbastanza facilmente e di adottare nel caso alcune
precauzioni (saturazione della banda a causa di molti download e
degradamento delle prestazioni).
Un punto debole nell’architettura di BitTorrent è il tracker, se il tracker
viene attaccato o, molto più semplicemente, si rompe tutti i file che
riferivano a lui vengono “persi”. Per questo motivo dalla versione 4.1
in poi è stata prevista la funzionalità di un tracker decentralizzato
(trackerless mode): la soluzione è basata su una DHT, in particolare sul
protocollo Kademlia, un’evoluzione di Chord. Tuttavia solo alcuni
client supportano il trackerless mode (Azureus e BitTorrent).
BitTorrent: strategie II
Com’è meglio scaricare i torrent?
Supponiamo di aver alcuni documenti con nome da A a Z e di doverne
scaricare una parte. Possiamo avere vari scenari.
I file sono contenuti ognuno in un torrent. Due strategie possibili:
MTCD (Multi-Torrent Concurrent Downloading): situazione in cui
il client scarica più torrent nello stesso momento
MTSD (Multi-Torrent Sequential Downloading): situazione in cui il
client scarica più torrent in modo sequenziale
BitTorrent: strategie III
Altro scenario.
Tutti i file sono contenuti in un solo torrent: in questo caso alcuni
client BitTorrent ci permettono di selezionare i file interessanti
contenuti nel torrent.
Due strategie:
• MFCD (Multi-File Torrent Concurrent Downloading): il client
selezionati i file interessanti all’interno del torrent si comporta come se
il torrent fosse composto solo da quelli e agisce nel modo standard,
richiedendo parti di tutti i documenti, senza alcun ordine.
BitTorrent: strategie IV
• CMFSD (Collaborative Multi-File Torrent Sequential Downloading):
è un nuovo approccio proposto da Tian et al. Sviluppa MFCD con la
considerazione che, a meno di stranezze, i file che sono contenuti
all’interno di un torrent sono in qualche modo correlati, hanno un’area
di interesse comune e che molto probabilmente verranno richiesti tutti
o almeno buona parte dagli utenti. Dividendo quindi il torrent in
subtorrent (uno per ogni file), un client può essere considerato un
seeder se finisce di scaricare un subtorrent, anche se non possiede gli
altri file. E’ una fusione di MFCD con MTSD, dove un peer ottiene
vantaggi, anche se scarica file solo collegati fra loro dall’argomento di
interesse.
BitTorrent: strategie e risultati
Da alcuni studi si è visto che nel campo del multi-torrent abbiamo i
seguenti risultati:
sia MTCD che MTSD hanno un tempo di completamento del
download proporzionale al numero di torrent richiesti.
MTSD risulta migliore di MTCD soprattutto quando i file richiesti
sono correlati fra di loro
Nel campo del multi-file:
CMFSD risulta migliore di MFCD quando i file richiesti sono
correlati fra di loro, ma porta a trattamenti di favore in caso di scarsa
correlazione dei file (preferendo chi possiede file di interesse a chi non
ne ha)
BitTorrent: identità fake
Quando un peer si presenta al tracker esso gli assegna una stringa
(lunga 20 byte) che lo identificherà in futuro. Ogni client quindi ha
un’identità per ogni tracker a cui ha fatto o fa riferimento (un’identità
per ogni swarm di cui fa parte). Quando un client riceve una richiesta
di un peer avviene un handshaking: il peer aspetta che il client mandi
la sua identità per controllarla fra quelle che ha ricevuto dal tracker. In
caso negativo, interrompe la connessione.
Risulta chiaro che un peer può quindi avere due identità:
una per il tracker e per i peer che lo contattano
una per i peer che lui stesso contatta
BitTorrent: una teoria I
Perché BitTorrent è divenuto così popolare? In molti studi si è visto
che l’utente nella maggior parte dei software P2P risulta molto più
egoista di quanto risulti in BitTorrent. Perché accade?
Hales e Patarin cercano la causa di questo comportamento nella
mancanza di un motore di ricerca centralizzato dei file. Mancando
esso, i file .torrent possono essere trovati su siti, su forum o mandati
via e-mail: tutti questi luoghi elettronici prevedono però interazione
sociale fra gli individui coinvolti nel swarm, creando uno spirito di
gruppo che rende l’utente meno “greedy”.
BitTorrent: una teoria II
Queste comunità, chiamate da Hales e P. tribù, inoltre si auto-
selezionano, espellendo membri che non si comportano secondo le loro
regole (rapporto Up/Down, presenza sul forum etc. etc.). Questo
meccanismo inoltre porta alla dissoluzione delle tribù composte per la
maggior parte da defezionatori, poiché, come già visto
precedentemente, se la popolazione ha una percentuale elevata di
defezionatori tutti i peer tenderanno, prima o poi, ad imbrogliare il
prossimo portando la tribù alla degradazione di performance e quindi
al suo scioglimento. Chi vuole far parte di un gruppo da cui non si
ottiene niente e a cui si da solo? Risulteranno vincenti le tribù
composte principalmente da “bravi ragazzi”, poiché risulteranno avere
migliori performance.
BitTorrent: situazione attuale
Negli ultimi tempi sono nati parecchi client che utilizzano il sistema
BitTorrent (BitTorrent, BitComet, BitTornado, Azureus...).
Esso viene utilizzato per la diffusione di alcune distribuzioni di linux e
incomincia a muovere alcuni passi anche nel campo di aziende private,
come la Blizzard Entertainment Inc. (gli aggiornamenti di World of
Warcraft, gioco di punta della casa di videogiochi, vengono distribuiti
con un client BitTorrent).
In un futuro, forse, la maggioranza degli update su computer
avverranno con torrent, alleggerendo di molto i server di release.
Bibliografia
Bram Cohen. Incentives Build Robustness in BitTorrent.
Proceedings of the First Workshop on the Economics of Peer-to-Peer
Systems, Berkeley, CA, June 2003.
http://wiki.theory.org/BitTorrentSpecification
BitTorrent, Wikipedia.
Jahn Arne Johnsen, Lars Erik Karlsen e Sebjørn Sæther Birkeland.
Peer-to-peer networking with BitTorrent.
Ye Tian, Di Wu e Kam-Wing Ng. Analyzing Multiple File
Downloading in BitTorrent. The 2006 International Conference On
Parallel Processing.
David Hales e Simon Patarin. How to cheat BitTorrent and why
nobody does. Technical Report UBLCS-2005-12