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