RES240 / RES224 Peer-2

RES 240 / 224: Peer-2-peer
RES240 / RES224
Peer-2-peer: BitTorrent
Dario ROSSI
[email protected]
http://www.enst.fr/~drossi
1
RES 240 / 224: Peer-2-peer
Plan BitTorrent
• Acteurs et fonctionnement général
– Swarm, torrent, tracker, seed, leecher, chunks, pieces, …
• Algorithmes et performance
– Strict priority, Rarest first
– Tit for tat, Anti-Snubbing, End-game mode,
Chocking/Unchocking, Optimistic Unchoking, …
• Bilan
– Efficacité vs complexité
• Control de congestion BitTorrent
– Separate set of slides,
2
RES 240 / 224: Peer-2-peer
Principes du partage en P2P
• Plusieurs méthodes pour localiser les ressources:
– Méthode distribuée
• Contact direct entre chaque utilisateur
• Localisation rapide
• Utilisé par Gnutella
– Méthode centralisée
• Contact établi par une entité
• Réplication rapide
• Utilisé par Bittorrent (initiellement)
– Methode distribuée possible egalement (trackerless)
3
RES 240 / 224: Peer-2-peer
Principes du partage en P2P
• Plusieurs méthodes pour rapatrier les ressources:
– Méthode « atomique »
• Ressources rapatriées en entier à partir d'un seul peer
• Utilisé par Napster, Gnutella (initiellement)
• Peu efficace
– Méthode « parcellisé »
• Ressources rapatriées de plusieurs peers (en parallèle)
• Utilisé par BitTorrent (eDonkey, et d’autres)
• Très efficace
4
RES 240 / 224: Peer-2-peer
Le mode de fonctionnement
• En brief:
– Parcelisation: permettre plusieurs échanges simultanées
– Atomique:on ne peut partager qu’une fois le fichier totalement
téléchargé
• Parcelisation
– Le fichier partagé est divisé en plusieurs parties égales
• Appelées chunk (256Ko)
– Divisés à leur tour en plusieurs moreceaux
• Appellés pieces (15Ko)
• Avantage:
– partager les chunks dès qu’on les possède
– télécharger les chunks qu’on ne possède pas
5
RES 240 / 224: Peer-2-peer
Les acteurs
• Tracker :
– Bootstrap element
– Elément central qui permet aux peers de prendre contact les
uns avec les autres (ne possède pas la ressource)
• Swarm :
– Ensemble des peers participants au partage d’une meme
ressource
– Consititué par plusieurs types de Peers
• Leecher : Peer qui télécharge
• Seed : Peers possédant une copie complète
6
RES 240 / 224: Peer-2-peer
.torrent
• Fichier .torrent
– téléchargé par un Peer pour participer au partage d’une
ressource (e.g., fichier de données) avec Bittorrent
– en général stoqué sur serveur Web
• Ce fichier contient:
– Liste des chunks (pour savoir qu’est qu’il faut telecharger)
– Mapping entre les différents chunk (pour reconstruire le
fichier ensuite)
– Checksum des chunk (pour en vérifier l’intégrité)
– L’identifiant d’un tracker (adresse IP/numéro de port)
7
RES 240 / 224: Peer-2-peer
seed
leecher
.torrent
tracker
8
RES 240 / 224: Peer-2-peer
Tracker
• Role: connaître les adresses IP et # ports des peers:
– Restituer une liste partielle de peers pour un torrent
– Aucune préférence, environ 50 peers choisis aleatoirement
• Smarter choices are possible: last year, during the NapaWine project
we implemented a proximity-aware selection of bootstrap peer in a
BitTorrent tracker (standardized by NEC at IETF ALTO)
• Ne posséde pas d’information relative:
– Aux chunks que chaque Peer possède
– A la capacité d’upload des Peers
• Les mises à jour avec le Tracker se font par les peers :
– Périodiquement (environ 30 min)
– Au premier contact (bootstrap)
– Quand un peer quitte le systeme
– Quand un peer a besoin de nouveaux peers
9
RES 240 / 224: Peer-2-peer
Peers
• But
– améliorer les performances de téléchargement
• Pour cela, deux objectifs:
– Optimiser le temps de téléchargement du complet du fichier
• plus de seed = plus des sources potentielles
– Contraindre les leechers au téléchargement
• obliger les Peers à uploader: pas d’upload, pas de source!
• Pour cela, deux moyens
– Le choix des chunks (et des pièces) à télécharger
– Le choix des peers avec lesquels on échange
10
RES 240 / 224: Peer-2-peer
Algorithmes
• Pipelining:
– Utilisation de requêtes multiples pour soin de performance:
ouverture de plusieurs connections en parallèle (environ 5)
– Chaque connection telecharge des pieces
• Selection des pieces:
– augmenter la disponibilité (Rarest First) et la rapidité
d’obtention des chunks (Strict Priority, Random First Piece)
• Selection des peers:
– Tit for tat = résoudre le dilemme du prisonnier
• Travailler pour le bien de tous pour améliorer ces propres
performances (optimistic unchoking)
• Pénaliser ceux qui ne répondent pas à cette règle
(choke, anti-snubbing)
11
RES 240 / 224: Peer-2-peer
Pieces: Strict Priority
• But:
– Obtenir le plus vite possible des chunks complets
• Fonctionnement :
– Si on envoie une requête pour une pièce d’un chunk
– Alors on devra envoyer des requêtes pour les autres pieces
du meme chunk en priorité aux autre chunks
• Interet
– L’upload n’est possible qu’une fois le chunk totalement
téléchargé
– Enfait, seulement une fois le chunk téléchargé on peut verifier
son integrité et validité (checksum dans le .torrent)
12
RES 240 / 224: Peer-2-peer
Pieces: Rarest First
• But: minimiser les chevauchements (overlap) des chunks
Non chevauchement
Chevauchement
• Interet:
– Equalization des ressources
• pas de “hotspot” i.e., de ressource peu disponible
– Meilleur utilisation de la largeur de bande
• car il est moins probable qu’à un certain instant tous les peers soient
interessés par un meme chunk disponible chez peu des peers
13
RES 240 / 224: Peer-2-peer
Pieces: Rarest First
• Fonctionnement :
– Quand un Peer veut envoyer une requête pour un nouveau
chunk
– Il demande aux autres Peers voisins les chunk qu’ils
possèdent
– Il envoie une requête pour celui qui est le moins présent
– Note:
• Le choix Rarest First est locale, car un peer ne contacte que ses
voisins
• Au meme temps, comme le voisinage des Peers change, les
choix locales ont tendance à converger vers de choix globales
14
RES 240 / 224: Peer-2-peer
Pieces: Rarest First Exemple
On contacte les Peers
pour connaître les chunks
qu’ils possèdent et que
nous n’avons pas déjà
On comptabilise les
disponibilités de chaque
chunk
On choisit aléatoirement
parmi les plus rares :
Random(2, 3)
15
RES 240 / 224: Peer-2-peer
Pieces: Random First Piece
• Exception des algorithme précédents
– Quand on vient juste de rentrer dans le systeme,
on ne possède pas encore un chunk
– Probleme: on ne peut pas uploader, pour cela
on doit obtenir rapidement un chunk
• Fonctionnement
– Tant qu’on ne possède pas un chunk complet
– Envoie aléatoire de requête pour des pièces de chunks
16
RES 240 / 224: Peer-2-peer
Pieces: Endgame Mode
• Problemes:
– Malgré Rarest First, certains chunks peuvent rester globalement
plus rare que d’autres (Rarest First est appliqué localement)
– En fin de téléchargement, on est plus contraint sur le choix des
chunks à télécharger
• Fonctionnement:
– Pour eviter de rester bloqués, meme si toutes les pièces qu’il nous
reste à telecharger sont toutes hautement demandées
– On envoie une requête pour toutes les pièces à tous les peers avec
lesquels on communique
• Interet:
– Aider des leecher à devenir des seeds, plus de sources dans le
systeme
17
RES 240 / 224: Peer-2-peer
Peers: Choke/Unchoke
• Probleme:
– Si aucun Peer n’upload, alors le partage est impossible
• Solution:
– Enforcer la reciprocité des echanges, en arrêtant l’upload vers des
Peers dont on télécharge peu
• Fonctionnement
– Toutes les 10 secondes
• recalculer le taux de téléchargement qu’il obtient de chaque peers
• conserver les 4 meilleurs
• couper l’upload vers ceux qui ne figurent plus dans le classement
(choke)
• rétablir l’upload vers ceux qui en font à nouveau partie (unchoke)
18
RES 240 / 224: Peer-2-peer
Peers: Optimistic Unchoking
• But:
– Empêcher qu’on n’échanges que dans un groupe réduit
– Ne pas exclure les nouveaux arrivant
– Permettre de découvrir d’autres peers (possibilité d’obtenir
une meilleur taux d’upload)
• Fonctionnement:
– Toutes les 30 secondes
• choix aléatoire d’un peer parmi les 4 vers qui on upload
• on lui coupe l’upload (choke)
• on choisit un peer aléatoirement parmi ceux à qui on
upload le moins
• on lui rétablit l’upload (unchoke)
19
RES 240 / 224: Peer-2-peer
Peer: Anti-snubbing
• Probleme
– Snub = uploader sans télécharger (inverse du free-riding)
– Lié au choke, quand on ne fait pas partie des 4 meilleures
uploads des peers avec qui on échange.
• Solution
– Se créer les condition pour l’optimistic unchoke (très peu
uploader)
• Fonctionnement :
– Si un Peer a qui on permet l’upload, nous bloque (choke)
pendant plus de 1 min
– On lui coupe l’upload (choke)
– On attend un optimistic unchoke en notre faveur avant de
rétablit l’upload (unchoke)
20
RES 240 / 224: Peer-2-peer
Peer: Seeding
• Seeding
– Quand un Peer devient seed, son but est d’uploader à qui on
offre le moins de pièces.
• Fonctionnement
– Un seul algorithme proche du choke, la différence est:
continuer à uploader vers ceux auxquels il upload le plus
• Maximiser le transfer vers ceux qui peuvent devenir seeds plus
rapidement
• Note
– Ils existent d’autres algorithmes lié au seeding, surtout au
debut quand il n’existe qu’un seul seed (super-seeding)
21
RES 240 / 224: Peer-2-peer
Bilan BitTorrent: Efficacité
• Localisation:
– Connaissances des Peers qui partagent grâce
•
•
•
•
Au reseau DHT (trackerless)
À une entité centralisée (tracker)
Possibilité de plusieurs trackers au meme temps (multi-tracker)
Possibilité d’utiliser les methodes multi-tracker et trackerless au
meme temps
• Diffusion
– Diffusion rapide grace
• A la division en chunk qui permet le pipelining
• Au politiques de choix des chunks
• A la dissuasion du free-riding (reciprocation et force à l’upload)
22
RES 240 / 224: Peer-2-peer
Bilan BitTorrent: Complexité
• Beaucoup d'extension
–
–
–
–
–
Plusieurs trackers
Table de hashage (trackless)
Super-seeding
Encryption
LEDBAT congestion control
policy depuis Decembre 2008
• Beacoup de clients
Client
– µTorrent, Azureus, BitTornado,
BitTyrant, Xunlei …
• Matrice clients vs extension:
– Un seul protocole, mais
beaucoup de declinaisons
– Importance de la normalisation
(standards)
– BitTorrent Enhancement Protocol (BEP)
Extension
Supporté
Pas supporté
n/a
23