unebrêvehistoiredupair-à-pairavant. seuiltechnologique. i....

20 décembre 2012

Introduction aux systèmes pair-à-pairFabien Mathieu

M2 UPMCParis, France

Partie I

Le pair-à-pair, c’est quoi ?

Cours P2P – Le pair-à-pair, c’est quoi ? 20 décembre 2012 – 2

Carte heuristique


Définitions

Sommaire

DéfinitionsApproches classiquesLimitesAutres possibilités

Principaux conceptsFonctionnementObjectifs

Une brêve histoire du pair-à-pairAvantAprès


Définitions Approches classiques

Définition par énumeration

Le pair-à-pair, «on» sait ce que c’est :Partage de fichier BitTorrent, eMule,. . .

Diffusion TVants, PPLive,. . .Voix sur IP Skype

Ce qui n’est pas pair-à-pair aussi :Non-réseau Office, Photoshop,. . .

Réseau Apache, SSH, browsers. . .Parfois, c’est flou :Calcul distribué BOINC project (Seti@home, Folding@home. . . )

Nuages Amazon, Wuala, . . .







Réseau Apache, SSH, browsers. . .

Parfois, c’est flou :Calcul distribué BOINC project (Seti@home, Folding@home. . . )








Réseau Apache, SSH, browsers. . .Parfois, c’est flou :Calcul distribué BOINC project (Seti@home, Folding@home. . . )




Définition réseau

La plupart des applications réseauxfonctionnent en client/serveur :I D’un côté, le(s) serveur(s)

fourni(t/ssent) des ressources,I De l’autre, les clients consomment ces

ressources.

Définition réseau → casser la séparationclient/serveur : tous les pairs peuvent êtreaussi bien clients que serveurs.

Marche avec la plupart des exemples précédents ?


Définitions Limites

Définition réseau : et Skype ?Skype est l’une des application P2P les plus connues. PourquoiSkype est P2P ?

I Interaction de pair à pair ?

I Interactions entren’importe quelle paire depairs ?

I Par les créateurs de KaZaAet Joost (cf plus tard) ?

I Peut-être que la définitionréseau a ses limites ? ?

Existe depuis, très, très longtemps




I Interaction de pair à pair ?I Interactions entre

n’importe quelle paire depairs ?



Existe depuis longtemps








Retour à l’énumération








Définitions alternatives : méthodologie, structure



Interlude : une définition légale ?

Le P2P peut être utilisé à des fins non légales.DADVSI tente d’interdire tout «logicielmanifestement destiné à la mise à disposition dupublic non autorisée d’œvres ou d’objetsprotégés».

I Peut recouvrir le partage P2P (data et multimedia)I Ne recouvre pas (trop) SkypeI Couvre la plupart des applications réseaux (incluant

l’approche client/serveur) : Apache, SSH. . .



Interlude : une définition légale ?

DADVSI n’est pas vraiment applicable. Prise deconscience de la difficulté de définir (légalement)un usage P2P illégal. Passage à Hadopi.

I Surveillance de contenu cibles (pots de miel)I Preuve d’un véritable téléchargement par personne physique

impossible à grande échelleI Mise en place du délit de négligence caractériséeI Échec technique, succès politique ?


Définitions Autres possibilités

Définition méthodologique

Le P2P utilise les ressources disponibles auquel ila accès (CPU, disque, bande passante) où qu’ellessoient, et les redistribue à ceux qui en ont besoin.

Deux variantes suivant ce que recouvre «où» :I Chez n’importe quel utilisateur (inclus BOINC)I N’importe où dans les réseaux (CCN, . . . )

Skype : borderline



Définition structurelle

Structure : comment les éléments d’un système sont agencés, etpar extension, interagissent.En réseau, on peut définir par structure la réponse à la question

Qui donne quoi à qui ?

Clients/serveurs, téléphone,. . . ont généralement des structurestriviales.Définition structurelle : le P2P est caractérisé par des structuresréseaux non triviales.Exclut les interactions triviales (Skype ?)



Définitions : récapitulatif

Il existe beaucoup de définitions possibles du P2PÉnumération On sait bien ce que c’est

Légal Confond technique et légalité de l’usageRéseau N’est pas client/serveur

Méthodologique Recycle des ressources inutiliséesStructurelle Interactions non trivialesRecommandationsI Il n’y a pas de meilleure réponse (il y en a de moins bonnes)I Utilisez votre tête !I Est-ce que Skype est P2P ? C’est comme vous (et Skype)

voulez !



Définition pour le cours

I Ce cours est centré sur la distribution (illégale ?) de contenuI La plupart des définitions marchentI Étude non-exhaustive


Principaux concepts

Sommaire





Principaux concepts Fonctionnement

OverlayLe modèle OSILe réseau est souvent découpé en 7 couches :I Couche 7 (Application)I Couche 4 (Connectivité point-à-point robuste)I Couche 3 (Routage)

P2PI Créer un réseau virtuel (overlay) en surcouche du réseau

physiqueI Overlay → grapheI Émuler les couches routage / connectivité / . . . sur la

topologie virtuelleI Un voisin physique n’est pas forcément un voisin virtuel (et

réciproquement !)Cours P2P – Le pair-à-pair, c’est quoi ? 20 décembre 2012 – 15


Overlay : deux grandes familles

Graphes structurésMaintenir une certaine forme avec de bonnes propriétésI Performances garanties par la structure du grapheI Maintenance faible si réseau stableI Fragile, maintenance forte si réseau très dynamiqueI Peu adapté aux réseaux héterogènes

Graphes non-structurésBasés sur le hasard, l’auto-adaptationI RobusteI Adapté à l’hétérogénéitéI Maintenance constante (élevée si réseau stable)I Pas de garantie immédiatement déduite du graphe



Passage à l’échelleEn client/serveurI la capacité de traîtement est fixeI trop de clients → DoS

En P2PI La capacité de traîtement augmente avec le nombre de clientsI → le P2P peut gérer un nombre arbitraire de clients : Passage

à l’échelle / scalabilitéPlutôt réelle, la scalabilité n’est cependant pas une propriétéabsolue et inébranlableI Réseau physique sous-jacentI Contraintes de QoSI La taille compte en pratique (maintenance, effet

logarithmique)



Notion d’équité (fairness)

Dans l’idéalEn P2P, chaque pair peut servir et être servi par n’importe qui : leP2P est isotropique.

En pratiqueI Il n’est pas toujours possible de servir n’importe quoi à

n’importe quiI “All peers are equal, but some peers are more equal than

others” (Orwell, the Server Farm)

→ le P2P est isotropique a priori au moment d’intégrer le système


Principaux concepts Objectifs

Ressources et objectifs

RessourcesI CPUI Disque videI Disque rempli (contenu)I Bande passante

ObjectifsI Calcul distribuéI Distribution de contenuI Téléphonie (Skype)I Gaming



Distribution de contenuTrois grandes familles

Partage de fichiers (filesharing)Distribution géneriqueI Objectif principal : récupérer le

contenuI Objectifs secondaires :

disponibilité, temps detéléchargement




À-la-Demande N’importe quoin’importe quandI Catalogue existant a priori

(comme pour le filesharing)I Minimiser l’initialisation (start-up

delay)




Live Direct / ProgrammeI Tout le monde veut la même

chose en même tempsI Minimiser le décalage

(play-out-delay)




Famille Partage simple À-la-Demande LiveStreaming ? Non Oui OuiQualité Minimale N’importe quoi, Small delayrequise N’importe quandAvantage Trafic Contenu Comportementtechnique élastique connu homogèneDifficulté Minimale Comportement Anticipationtechnique hétérogène impossible



Indexation/Distribution

Quel soit le système (P2P) de distribution de contenu, il y a deuxquestions à résoudre :

Qui possède ce que je veux ?I Construire / maintenir un indexI Résoudre à la voléeI Utiliser une solution centralisée

Comment je récupère ce que je veux ?I Sans réfléchirI Intelligemment


Une brêve histoire du pair-à-pair

Sommaire





Une brêve histoire du pair-à-pair Avant

Pré-histoire du P2P : communications

Quelques dates-clés

-200000 ? Parole-30000 ? Peinture-7000 ? Écriture

-600→ -100 Longue distance (chevaux/pigeons/sémaphores)1454 Gutenberg1876 Téléphone1969 Arpanet1993 MP31999 ADSL (en France), DivX 3.11



Seuil technologique

I Vers 2000, on peut récupérer du contenu en temps raisonnable

I Une autre métrique intéressante : peut-on «streamer» ?

Main Impr. Modem DSL 512k DSL 20MLivre 2-3j 1

2h 1m 6s 0.15sTube (WAV) 1

2a 1-2j 1h 6m 10sFilm (DVD) 100a 1a 10j 1j <1hTube (MP3) 20j 3h 6m 30s 1sFilm (DivX) 12a 40j 1j 3h 5m



Seuil technologique

I Vers 2000, on peut récupérer du contenu en temps raisonnableI Une autre métrique intéressante : peut-on «streamer» ?

Main Impr. Modem DSL 512k DSL 20MLivre Non Oui Oui Oui Oui

Tube (WAV) Non Non Non Presque OuiFilm (DVD) Non Non Non Non OuiTube (MP3) Non Non Presque Oui OuiFilm (DivX) Non Non Non Presque Oui



Seuil technologique

Vers 2000I Les contenus numériques deviennent la norme

I CDs, MP3I DVDs, DeCSS, DivX

I Le «haut débit» rend la réception par Internet réalisteI Pas de YouTube, MegaUpload, . . .I Quelques solutions marginales

I Newsgroups (alt.binaries.*)I FTPzI IRCI Myspace



Interlude : Myspace, un MegaUpload (trop ?) précoce

SuccèsI MySpace offrait 300MB «dans le nuage»I Création illimitée de comptesI Pas de CaptchaI → Programmes automatiques

I Découpage du contenu, création de compte, envoiI Infos de reconstructions disséminées dans un petit fichier




La ChuteI Revenus :

I Pub : peu de revenus via InternetI Modèle Freemium : pas dans les mœurs

I Dépenses :I Stockage : très cherI Bande passante : extrêmement cherI Démultipliées par l’automatisation

I → situation financièrement impossible




Quelles leçons peut-on tirer de MySpace ?I Certains internautes veulent télécharger du contenu (légal ?)I Trop tôt pour qu’une solution commerciale soit intéressante

(une décade)



Des conditions idéales

En résumé, vers 2000, tout est prêt pour faire du P2PI Faisabilité : lien descendant suffisant, lien montant non utiliséI Motivation : récupérer du contenuI Opportunité : pas de réel compétiteur


Une brêve histoire du pair-à-pair Après

P2P : Logiciels clés

1998 Napster : distribution de contenu P2P(MP3)distribution

2000 Gnutella : recherche décentralisée2000 KaZaA/eDonkey : indexation hiérarchique2003 BitTorrent : distribution performante2006 Fin de Razorback 2.0 : émergence des DHTs

2006-2009 PPLive/UUSee/TVAnts/. . . : P2P streaming



Napster

I Inventé en 1998 by Shawn "Napster" Fanning (The Italian Job)et Seam Parker (appears in The social network)

I Procès en 1999 (MPAA) - fermeture en juillet 2001I Fonctionne en trois étapes :

1. Indexation : les utilisateurs envoient leur index de MP3(catalogue) à un serveur, napster.com

2. Requête : demande d’un nom de fichier auprès du serveur ;retour d’un ensemble de clients (adresses) possédant un fichiercompatible avec la requête

3. Distribution : télechargement auprès d’un client de la liste



Napster

Serveur

p1p2

p3

p4 p5

p6

A

A∈

p 4

A?A ∈ p4

A ?send A

1. Indexation

I p4 possède AI p4 informe s

2. Requête

I p6 demande à squi a A

I s répond p4 (IP)

3. Distribution

I p6 contacte p4I p4 envoie à p6



Napster

Serveur

p1p2

p3

p4 p5

p6

A

A∈

p 4

A?A ∈ p4

A ?send A

1. IndexationI p4 possède A

I p4 informe s2. Requête


I s répond p4 (IP)

3. Distribution




Napster

Serveur

p1p2

p3

p4 p5

p6

A

A∈

p 4

A?A ∈ p4

A ?send A

1. IndexationI p4 possède AI p4 informe s

2. Requête


I s répond p4 (IP)

3. Distribution




Napster

Serveur

p1p2

p3

p4 p5

p6

A

A∈

p 4

A?A ∈ p4

A ?send A


2. Requête


I s répond p4 (IP)3. Distribution




Napster

Serveur

p1p2

p3

p4 p5

p6

A

A∈

p 4

A?

A ∈ p4

A ?send A


2. RequêteI p6 demande à s

qui a A

I s répond p4 (IP)3. Distribution




Napster

Serveur

p1p2

p3

p4 p5

p6

A

A∈

p 4

A?

A ∈ p4

A ?send A



qui a AI s répond p4 (IP)

3. Distribution




Napster

Serveur

p1p2

p3

p4 p5

p6

A

A∈

p 4

A?A ∈ p4

A ?send A




3. Distribution




Napster

Serveur

p1p2

p3

p4 p5

p6

A

A∈

p 4

A?A ∈ p4

A ?

send A




3. DistributionI p6 contacte p4

I p4 envoie à p6



Napster

Serveur

p1p2

p3

p4 p5

p6

A

A∈

p 4

A?A ∈ p4

A ?

send A




3. DistributionI p6 contacte p4I p4 envoie à p6



Napster

InnovationI Indexation centralisée→ requêtes complexes (regexp) faisablesI Distribution d’un pair à un autre (littéralement)

LimitesI Indexation centralisée → point de vulnéralibilité (d’ailleurs. . . )I Distribution «stupide» (un vers un, fichier entier)



Gnutella

HistoireI 1er client : 2000 (nullsoft-AOL). Retiré au bout de 1 jour ( !)I Code disponible → repris en open-source (LimeWire,

Morpheus...)I Plus gros trafic IP de l’année à son époque (quasi disparu

aujourd’hui)

Idée du protocole initial (0.4)

I Totalement décentralisé : pas d’index centralI les recherches sont faites par innondationI Améliorations ultérieures (hashage, ultrapeers, chunks...)



Gnutella

p1

p2 p3p4

p5

p6

p7

A

A ?

A ?

A ?

A ?

A ?

A ?

A ?A ?

A ?

A ?

A ?

A ?

A ?

A ?A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ?A ?

A ?

A ?

A ?

A ?

A ∈ p6

A ∈ p6

A ∈p6

A ?

A ?

A ?

A ?

A ?A ?

A ?

A ?

A ?

A ?

A ∈ p6

A ∈ p6

A ∈p6

want Asend A



Gnutella

p1

p2 p3p4

p5

p6

p7

A

A ?

A ?

A ?

A ?

A ?

A ?

A ?A ?

A ?

A ?

A ?

A ?

A ?

A ?A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ?A ?

A ?

A ?

A ?

A ?

A ∈ p6

A ∈ p6

A ∈p6

A ?

A ?

A ?

A ?

A ?A ?

A ?

A ?

A ?

A ?

A ∈ p6

A ∈ p6

A ∈p6

want A

send A



Gnutella

Innovationpas d’index, regexp toujours possibles

LimitesI L’innondation, c’est MAL : à chaque requête, une seule une

fraction des pairs reçoit le messageI fraction trop petite : réponse incomplèteI fraction trop grande : surcoût en message (proportion mesurée

des messages : plus de la moitié du trafic)I Distribution toujours «stupide»



KaZaAHistoireI 2000, Niklas Zennström et Janus Friis (Skype, Joost)I Repose sur le réseau FastTrack (propriétaire)I Plus gros trafic de l’année, puis disparaît

Principale idée : indexation hiérarchiqueI Choix de supernodes : pairs avec grande bande passante et

souvent disponiblesI Chaque pair ordinaire dépend (est relié) à un supernode (ratio

100− 1000)I Les supernodes gèrent leurs pairs (indexation, gestion des

requêtes) et communiquent par innondation (Gnutella-style)I Également, distribution par chunks basée sur la réputation



KaZaA

s1

s2 s3

s4

s5

s6

s7p1a p1b p2a

p5a p5b

p6a p6b p6c

p7a p7b p7c

p4a p4b

A

A∈

p6b

A?

A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ∈ p6b

A ∈ p6b

A∈

p 6b

want Asend A



KaZaA

s1

s2 s3

s4

s5

s6

s7p1a p1b p2a

p5a p5b

p6a p6b p6c

p7a p7b p7c

p4a p4b

A

A∈

p6b

A?

A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ?

A ∈ p6b

A ∈ p6b

A∈

p 6b

want A

send A



eMule - eDonkey

HistoireI Le client eDonkey2000 sort en. . . 2000I Société MetaMachine, fermeture en 2005 (RIAA)I Protocole documenté → clones Open-source (eMule)I plus grand trafic. . . (toujours 2e en 2012)

PrincipeI Serveurs eDonkey : serveurs dédiés à l’indexation (supernodes

«professionnels»)I Distribution par chunks avec files d’attente



KaZaA/eDonkey

InnovationI Indexation hiérarchiqueI Concept de chunk («paquet» de l’overlay)

LimitesI KaZaA : ordonnanceur de chunks séquentiel → «chunk

manquant»I KaZaA Lite K++ : fausse réputation, toujours supernodeI eDonkey : files d’attente saturées → délai très grandI Serveurs/ supernodes → points faibles



KAD vs Razorback 2.0

Kad

RazorBack 2.0

Le cycle de la vie




KadI Objectif : éviter l’index (semi)-centralisé ET l’innondationI Solution : les tables de hachage distribuées (DHTs),

introduites dès 2001 (papiers académique)I L’indexation est répartie sur tous les pairsI Une des implentations, Kad, est incorporée assez vite à eMule

RazorBack 2.0

Le cycle de la vie




Kad

RazorBack 2.0I Une course au meilleur serveur eDonkey s’engage au début

des années 2000I Un vainqueur incontestable : Razorback 2.0I Les autres serveurs dépérissent (spam, catalogue et réactivité

faibles)

Le cycle de la vie




Kad

RazorBack 2.0

Le cycle de la vieI Au début, Kad très peu populaire (R2 est plus rapide)I 21 février 2006, fermeture brutale de Razorback2I Beaucoup d’utilisateurs basculent vers Kad, seule véritable

alternative. . .I . . . et ça marche ! (résiste à la montée en charge)



Les tables de hachage distribuées

InnovationIndex totalement décentralisé

LimitesI Seulement des combinaisons simples de requêtes exactes

(regexp)I Prix à payer logarithmique (delai et maintenance)



BitTorrentHistoireI Papier fondateur et client proposés en 2003 par Bram CohenI Protocole documentéI Grand nombre de clients (Générique, Azureus/Vuze, µtorrent. . . )I Plus gros trafic (de loin) pendant plusieurs années. Toujours le

plus grand trafic P2P

Idée principale : se concentrer sur le contenu et sa distributionI À chaque contenu est associé un overlay : l’essaim (swarm)I Un essaim est indexé par un trackerI Politique d’incitation au partage : donnant-donnant

(Tit-for-Tat)I + 2/3 autres idées simples et efficaces



BitTorrent

Une architecture minimaleI Un tracker gère l’ensemble des pairs intéresséI quand je suis intéressé, je récupère des voisinsI échange de chunks jusqu’à ce que téléchargement terminé



BitTorrent

Tracker

source

source source



BitTorrent

InnovationI Une architecture orientée contenu plutôt qu’utilisateurI Véritable optimisation de la partie distribution

LimitesI Trackers → vulnérabilitéI Durée de vie des essaims faible / rétention eMule



P2PTV

HistoireI Origine : évènements sportifsI Une flopée de clients propriétaires incompatibles (UUSee,

PPLive, TVAnts,. . . )I Principalement utilisé en Asie, et chez des communautés

«expats»

Idée : réduire le délaiI À-la-demande, commencer sans tout récupérer d’abordI Optimiser la diffusion des chunksI Booster le système à coups de serveurs



P2PTV

InnovationAlgorithmes pour optimiser le délai

LimitesI La barrière logarithmiqueI Youtube et les autres


Partie II

Les Tables de Hachage Distribuées(DHTs)

Cours P2P – Les Tables de Hachage Distribuées (DHTs) 20 décembre 2012 – 52

Principe

Sommaire

Principe

CAN

Tapestry / Pastry

Chord

Conclusions


Principe

Tables de Hachage Distribuées

MotivationLocaliser un contenu à moindre coût

Problèmes à résoudreDécentralisation le travail doit être réparti entre les pairsScalabilité la recherche doit marcher même sur les très grands

systèmesDynamicité les pairs vont et viennent, gentiment ou pas


Principe

Tables de Hachage Distribuées

Fonction de hachagefonction h : E 7→ FE = tout ! (ensemble de fichiers, noms de fichiers, adresses IP...)F = espace des clés (cercle [0, ..2n[, carré, hypercube, . . . )

Idée de base d’une DHT (Distributed Hash Table)

I Chaque pair a un numéro (clé ou hash)I Chaque donnée a un numéro (clé ou hash)I Un pair gère une zone de F (les données dont la clé est dans

la zone)I Trouver une clé trouver une route vers le pair qui gère la cléI Beaucoup de variante suivant F et le mécanisme de routage

I CAN, Pastry/Tapestry, Chord,. . .


Principe

Une chose à retenir

Gérer une clé ne veut pas direposséder le contenu ! (la bonne réponse est : savoirquels contenus ont la clé et qui les possèdent)


Principe

Exemple : indexation par plus proche

donnees

1 Espace d’adressage 1000

152

171163

3748

133

689 719

832865

965538479451

223257

262312

337

262pairs

Le pair de hashcode 152 gère/indexe les données de hashcode 37,48, 133, 163 et 171


Principe

Exemple de requête : “maverick meerkat iso”1. h(“maverick”) = 12342. recherche du pair de hash le plus proche de 12343. C’est le pair de hash 11004. On lui demande une liste de contenus5. h(“meerkat”) = 56786. rech. plus proche : 5600 → requete → contenus7. h(“iso”) = 9101 ? (trop vague)8. Intersection des listes de contenus9. Affichage10. Choix du contenu de hash 6666 par l’utilisateur11. recherche du pair de hash le plus proche de 6666 : 666712. demande d’une liste d’IPs a 666713. téléchargement depuis ces IPs


Principe

Routage par la clé

Algorithme de recherche génériqueI Le pair P recherche une donnée de clé cI Cette donnée est indéxée par le pair QI P connait quelques voisinsI Il transmet la requête au voisin le «plus proche» de cI qui transmet, etc.I finalement on arrive à Q

AnalyseI On va essayer de le faire en O(log n) demandes (sauts)I Ressemble a la recherche dichotomiqueI Plus d’inondation !


Principe

Routage par la clé

Comment faire ?I Le réseau des connaissances essaie d’avoir une certainetopologie :

I Chord [Stoica & alii, 2001] : cercleI CAN [Ratnasamy et al., 2001] : tore multidimensionnelI Pastry [Rowstron et Druschel 2001] : hypercubeI Viceroy [Malkhi et al., 2002] : papillonI Kademlia [Maymounkov Mazières 2002] : hypercubeI D2B [Fraigniaud et Gauron, 2003] : de Bruijn

I On fait une marche dans ce grapheI de voisin en voisinI à chaque étape, on progresse vers le butI Si le diamètre du graphe est O(log n)...

I On arrive donc sur le voisin recherché en O(log n) étapes


CAN

Sommaire

Principe

CAN

Tapestry / Pastry

Chord

Conclusions


CAN

Content-Addressable Network (CAN)

0 2m

2m

•(x , y)

I F : hypercube à ddimensions (d = 2)

I Chaque pair gère unrectangle

I d fonctions de hachage les clés correspondent à und-uplet (une paire) de hashs

I Routage vers le voisin de lazone la plus proche pour ladistance cartésienne


CAN

Exemple

0 8

8

1 23

45

6

7 8

9

10

2

10 •(7, 1)

24

9

10

Table de routage de 2Pair Zone2 (2, 4) à (4, 8)

1 (0, 4) à (2, 8)

3 (4, 6) à (6, 8)

4 (4, 4) à (6, 6)

6 (0, 2) à (4, 4)

I Recherche clé (7, 1)possédée par le pair 10.

I Route de 2 vers (7, 1) :2→ 4→ 9→ 10.


CAN

Départs et arrivées

I Arrivée de A : A prend une clé (X ,Y ) et contacte un pair Bquelconque (bootstrap)

I A contacte par B le pair C responsable de (X ,Y )I C partage sa zone avec A (les tables de routage sont ajustées)I A et C contactent leurs voisins pour mise à jour des tables

I Départ d’un pair A : A contacte ses voisins et détermine quidoit prendre le relais

I Envoie des mise à jour aux voisinsI la zone peut revenir à plusieurs voisins


CAN

Propriétés

I Facile à comprendre, facile à étendreI Chevauchements des zones pour plus de robustesseI Dimension d quelconqueI Ré-agencement dynamique des zones pour rééquilibrer la

chargeI Taille de la table : O(d) ¨©

I Nombre de sauts : O(dn1/d ) _©

I Bilan : bof (coûteux en messages et lent)


Tapestry / Pastry

Sommaire

Principe

CAN

Tapestry / Pastry

Chord

Conclusions


Tapestry / Pastry

Tapestry/Pastry

I Même principe, juste F et le routage changentI F = [0, ..2n[ écrit dans une certaine base (p.e. hexa)I Routage type Plaxton Mesh


Tapestry / Pastry

Routage Plaxton Mesh

I Routage incrémental, chiffrepar chiffre : à chaque coup,on se rapproche d’un chiffrede la destination.

I Exemple : 0325 veutcontacter 4598. Une routepossible est

I 0325I B4F8I 9098I 7598I 4598

I Mais il faut connaître lesbons voisins. . .


Tapestry / Pastry

Tables de routage

I Chaque voisin se construit une table qui permet d’avoir unchiffre de plus vers la destination

I Taille de la table : b logb N, où b est la base d’adressageutilisée

I Nombre de sauts : logb NI ¨© ¨© ¨©


Tapestry / Pastry

Tables de routage

I les x sont des jokers(n’importe quelle valeurmarche)

I En fait, on met souventplusieurs adresses par slot sipossible (robustesse)

I Exemple : 3642 reçoit lemessage vers 2342

I Suffixe commun : xx42 →deuxième colonne

I On prend un x342 si onen trouve un


Tapestry / Pastry

Et les trous ?

Procédure de routage PastryZone primaire : plus court suffixe uniqueI Si le message est dans ma zone

I OKI Sinon

I regarder l’entrée +1 chiffre communI Si existe, faire suivreI Sinon envoyer au plus proche (si moi, zone secondaire)


Chord

Sommaire

Principe

CAN

Tapestry / Pastry

Chord

Conclusions


Chord

Protocole Chord

I Toujours le même principe . . .I Fonction de hachage : SHA-1I F = [0, ..2m[(m = 160) vu comme un cercle modulo 2m :

l’anneau ChordI Base du routage : successeur(k) = premier pair dont la clé est

strictement supérieure à k modulo 2m


Chord

Successeurs

Un pair gère l’ensemble des clés dont il est le successeur

•p1

•p21

•p32

•p51

•k8

•k14

•k38

•k56


Chord

Un théorème

Avec forte probabilité, pour N pairs et K clés :I Chaque pair gère au plus (1+C)K

N clésI Si un pair arrive ou part, moins de O(K

N ) clés changent depropriétaire

I C = O(ln(N))


Chord

Routage par successeur

•p1

•p8

•p14

•p21

•p32

•p38

•p42

•p48•p51

•p56

•k45

I Exemple : 1 cherche45 (géré par 48)

I _©_©_©


Chord

Solution : finger table

•p1

•p8

•p14

•p21

•p32

•p38

•p42

•p48•p51

•p56

I finger(k) : successeur den + 2k−1 modulo 2m

Finger table de p8S(8 + {20, 21, 22}) p14

S(8 + {23}) p21S(8 + {25}) p32S(8 + {26}) p42


Chord

Routage avec Finger table

•p1

•p8

•p14

•p21

•p32

•p38

•p42

•p48•p51

•p56

cherche(54)


Chord

Routage amélioré

I Chaque saut raccourcit la distance de moitié (à peu près)I Théorème : avec forte probabilité, le nombre de saut

nécessaires pour trouver le responsable d’une clé est O(ln(N))


Chord

Départs et arrivées

I En arrivant, un pair N contacte un point d’entrée AI A cherche B, prédécesseur de NI N devient le successeur de BI N contacte B, récupère sa tableI N ajuste les fingerI N contacte son successeur et partage les clés

I En partant, un pair contacte ses prédécesseurs (finger inclus)pour signaler son départ. Les clés sont envoyées au successeuret le successeur est signalé au prédécesseur.


Chord

Propriétés de Chord

I Correct même en cas de finger corrompues (il reste la routedes successeurs)

I Redondance possible pour éviter la perte de donnéesI Possibilité de mettre en cache des résultats pour accélérer des

requêtes futuresI Assez simple à comprendre (si, si !)


Conclusions

Sommaire

Principe

CAN

Tapestry / Pastry

Chord

Conclusions


Conclusions

Robustesse

I Les versions simples présentées ont du mal avec les pannes /départs impolis

I Solution : redondanceI Approche passe-partout : utiliser des petits clusters de pairs

agissant comme des pairs uniques logiquesI Fusionner / séparer les clusters à la volée en fonction de l’état

du système


Conclusions

Conclusion sur DHT

Avantages des DHTI Routage rapide : O(logN)

I Tables de routage en O(logN)

I Attaques plus dures que sur un serveurI Réellement pair-à-pair, passe à l’échelle à coût nul

InconvénientsI Table de hachage seulement → pas de requêtes complexes !I Plus lent qu’un serveurI Protocoles plus complexes et bugs plus durs à corriger


Partie III

Loi de la bande passante

Cours P2P – Loi de la bande passante 20 décembre 2012 – 85

Introduction

Sommaire

IntroductionMotivationModèle

Conservation de la bande passanteFormule généraleExemple du streaming

Régime stationnaire des systèmes ouvertsModèleThéorème de surprovisionnement


Introduction Motivation

P2P = Mauvaises performances ?

I Le P2P est considéré comme low cost

I Il faut donc toujours préférer une solution centralisée ?

I Vraiment ?

I Peut-on comprendre d’où vient la performance ?I Étude sur une distribution orientée contenu (BitTorrent)




I Le P2P est considéré comme low costI Il faut donc toujours préférer une solution centralisée ?

I Vraiment ?






I Vraiment ?

I Peut-on comprendre d’où vient la performance ?

I Étude sur une distribution orientée contenu (BitTorrent)





I Vraiment ?



Introduction Modèle

Modèle complet (hybride)

On considère souvent trois types de «pairs» :Serveurs centraux (C) Composante non-P2P du systèmeLeechers (L) Veulent du contenu ; peuvent en fournir à d’autres

leechersSeeders (S) Possèdent du contenu et peuvent le fournir aux

leechers

Deux variantes du modèleI FerméI Ouvert



Modèle fermé

Leechers

Seeders

ServeursDonnées

Données

DonnéesLes leechers recoivent ducontenu de tout le mondeI Autres leechersI SeedersI Serveurs



Modèle ouvert

Leechers

Seeders

Serveurs

Arrivées

Fichier récupéré

Données

Départ

Données

Données

Cycle de vie :I Un pair arrive en temps

que leecherI Une fois le

téléchargement terminé,il devient seeder

I Au bout d’un certaintemps, il part

I Les serveurs sontstatiques



Notation

I Serveurs/leechers/seeders : C , s ∈ S, l ∈ LI Nombre de pairs : NS , NLI Upload : US , UC , ul , uSI Download : dl , dmax


Conservation de la bande passante

Sommaire





Conservation de la bande passante Formule générale


I Rien ne se perd, rien ne se crée, tout se télécharge∑l∈L

dl ≤ UL + US + UC

I Par exemple, si download infini,∑l∈L

dl = ηLUL + ηSUS + ηCUC

I η : coefficient d’efficacitéI Systèmes idéaux : η = 1


Conservation de la bande passante Formule générale


I Si partage uniforme de la bande passante

d = min(

dmax, uL + βuS +UCNL

), avec β =

NSNL

I Marche sur systèmes ouverts et fermésI Marche en trafic contraint (streaming) et en élastique

(filesharing)I Beaucoup d’améliorations possibles (η, dmax , partage

non-uniforme. . . )


Conservation de la bande passante Exemple du streaming

Exemple du streaming (système fermé)

I Pour un débit cible r , on pose αX = uXr et NC = UC

rI Pour diffuser, il faut d ≥ r , sinon. . .I αL + βαS est la capacité normalisée du système P2PI Cas 1 : αL + βαS ≥ 1

I Le système passe à l’échelle (indépendamment de NC )I Les serveurs ne sont pas nécessaires pour la bande passante

(mais bootstrap/delai/securité)I Cas 2 : αL + βαS < 1

I NL ne peut dépasser NC1−(αL+βαS )

I → Effet de levier : la capacité serveur est multipliée par1

1−(αL+βαS )



Exemple du streaming (système fermé)

PreuveI On part de la condition à vérifier :

UC + US + UL ≥ NLr

UC + NLuL + NS uS ≥ NLr

UC + NLr(αL + βαS) ≥ NLrNCNL

+ (αL + βαS) ≥ 1

I αL + βαS ≥ 1 → toujours vérifiéI αL + βαS < 1 → NL ≤ NC

1−(αL+βαS )



Interlude : Joost

Histoire d’un fiasco monumentalI Après KaZaA (2000), Niklas Zennström et Janus Friis veulent

révolutionner le monde (du P2P).I Le monde n’est pas prêt, donc ils font un petit projet en

attendant : SkypeI 2005 : vente de Skype à eBay. Retour au grand projet (avec

des soux).I 2007 : Lancement de Joost, le programme P2P ultime (fait

aussi le café)I 2008 : abandon de la partie P2P de Joost ; fonctionnement

sur navigateur (type Youtube). . .I 2009 : Clé sous la porte ; fin de l’histoire



Interlude : Joost

I Joost n’était pas ouvertI En mesurant le rapport upload/download ratio, α = 1

6I Si β = 0, l’effet de levier P2P est de 20%I Si β = 1, on passe à 50% (most likely behavior)I Si β = 2, 100%I . . .I Le passage à l’échelle nécessite β ≥ 5 (même en heure de

pointe)I Conclusion : Joost n’utilisait le P2P que comme levier


Régime stationnaire des systèmes ouverts

Sommaire





Régime stationnaire des systèmes ouverts Modèle

Modèle de système ouvert

I On fixe un fichier de taille k comme objectifI Les pairs arrivent à un taux λ (arrivées par unité de temps)I Un pair l télécharge en TL(l), puis il seedeI Après TS(s), le seeder s quitte le systèmeI Système ouvert, donc dynamique. . .I . . . on ne regarde que le régime stationnaire


Régime stationnaire des systèmes ouverts Modèle

Régime stationnaire

I Les pairs qui arrivent avec un upload p(u) :

u =

∫up(u)

I Un pair télécharge pendant TL(l) = kd(l) . Si d lié à u

TL =

∫TL(u)p(u), pL(u) =

TL(u)p(u)

TL, uL =

∫upL(u)

I Un seeder reste TS(s). Si TS lié à u, alors

TS =

∫TS(u)p(u), pS(u) =

TS(u)p(u)

TS, uS =

∫upS(u)

I Si pas de corrélation avec u, uL = uS = u


Régime stationnaire des systèmes ouverts Théorème de surprovisionnement

Théorème de surprovisionnement

I Donne une condition suffisante pour qu’un système optimalatteigne dmax dans la limite fluide du régime stationnaire :

TS uS +UCλ

> k(1− udmax

)

I Par exemple, la condition est vérifiée si

I TS uS + UCλ ≥ k : tout débit cible peut être atteint.

I TS uS ≥ k : tout débit cible peut être atteint, indépendammentde la popularité λ et de UC . Par exemple

I TS(u) = ku

I TS = ku





TS uS +UCλ

> k(1− udmax

)

I Par exemple, la condition est vérifiée siI TS uS + UC

λ ≥ k : tout débit cible peut être atteint.

I TS uS ≥ k : tout débit cible peut être atteint, indépendammentde la popularité λ et de UC . Par exemple

I TS(u) = ku

I TS = ku





TS uS +UCλ

> k(1− udmax

)


λ ≥ k : tout débit cible peut être atteint.I TS uS ≥ k : tout débit cible peut être atteint, indépendamment

de la popularité λ et de UC . Par exemple

I TS(u) = ku

I TS = ku





TS uS +UCλ

> k(1− udmax

)



de la popularité λ et de UC . Par exempleI TS(u) = k

u

I TS = ku





TS uS +UCλ

> k(1− udmax

)



de la popularité λ et de UC . Par exempleI TS(u) = k

uI TS = k

u



Conclusions sur la bande passante

I Des règles de dimensionnement valables pour tous types dedistribution de contenu

I C’est du premier ordre (faisabilité / ordre de grandeur)I Deuxième ordre : dépend du contexte

I Latences réseauI Gouleaux cœur, pertes paquetsI Comportement des protocoles underlay (TCP/µTP, AQM)I Propagation / disponibilité de l’information (chunk)I OverheadI . . .


Partie IV

Streaming

Cours P2P – Streaming 20 décembre 2012 – 104

Problématique

Sommaire

Problématique

Streaming

Structuré

Non-structuré


Problématique

Rappel

On veut diffuser un contenu le plus rapidement possible.Un diffuseur, N pairs.

Temps différé (diffusion)ExemplesI 1ere diffusion d’un fichier (release). Une source, beaucoup de

téléchargeurs (flashcrowd)I Vidéo à la demande (VoD)

Temps réel (streaming)

I Exemple : télévisionI Des contraintes temporelles s’ajoutent


Problématique

Delai : transmission point-à-point

I Combien de temps dans l’underlay pour communiquer del’information entre deux voisins dans l’overlay ?

I Approche stripes (flux continu de données) :latence réseau (≈ RTT/2)

I Approche chunks (unité atomique de données) :Négociation+latence+TailleChunk/Bandwidth

I Pour les “gros” chunks :TailleChunk/Bandwidth


Problématique

Délai de propagation P2P

I Rappel : décalage (play-out delay)I Temps entre un évènement et son affichageI Spécifique au direct

I Rappel : délai d’initialisation (start-up delay)I Temps pour commencer à regarderI Contrainte générique pour le streaming

I Délai de propagationI Temps pour qu’une donnée atteigne tous les pairs une fois

injectéeI Borne inf pour le décalageI Bonne estimation pour l’initialisation


Problématique

Un exemple simple

I Une source uniqueI Direct (durée inconnue)I Ne peut transmettre qu’une copie du flux

I n spectateurs (pairs)I Veulent voir le fluxI Chaque pair a la bande passante pour retransmettre un flux

I Comment faire ?


Problématique

Approche chunks

I Le flux est découpé en morceaux à la voléeI La source injecte le flux chunk après chunkI Les pairs peuvent envoyer les chunks (complètement) reçus


Problématique

Solution #1 : transmission linéaire

I Envoi à la queue leu leuI Ça marche : tout le

monde regardeI Délai de propagation

horrible (O(n))I Pas très robuste (un

départ crée 50% depertes en moyennes)


Problématique

Simple chunk : transmission optimaleQuelle est la manière la plus rapide ?I Un client reçoit le chunk (t = 0)I Ceux qui l’ont donnent aux autresI individuellement séquentiel, globalement parallèleI C’est optimal :

I Temps de propagation en log2(n),I Une panne touche log2(n) pairs en moyenne


Problématique

Multiple chunks : transmission optimaleSi flux de chunksI Pour être optimal, il faut permuter sur l’optimal d’un simple

chunkI Il faut éviter les contentions

I à l’envoi (rouge)I à la réception (vert) si download critique

I Faisable sur l’exemple simple !


Problématique

Cas général

La propagation du bloc simple est une borne infI Cas homogène : valeurs identiques

I stripes

D = τ logd

(⌈NLNC

⌉), avec

τ : latence ; d : degré sortantI Gros chunks

D =cu log2

(⌈NLNC

⌉), avec

c : taille du chunkI Extension au cas hétérogène : compliqué


Problématique

Délai constant ?

I Le délai est logarithmique en NLNC

I Si NLNC

est borné, le délai aussiI Obligé si pas de scalabilité

NLNC≤ 1

1− (αL + βαS)

I Même si, un gros NC est bénéfique pour le délai.


Problématique

Propagation simple

Différents facteurs peuvent affecter la propagationI Parallélisme individuelI Nombre de copies par pair limitéI Effet retard

Le délai est toujours augmenté par rapport à l’optimal. L’origine deces facteurs est :I à cause de contraintesI pour gagner ailleurs


Problématique

Exemple : arbre de FibonacciI Il faut une unité de temps pour être prêt à émettreI Il faut une unité de temps pour émettre un blocI Totalement coopératif : tous participentI Tous ont la même borne passanteI Borne inférieure au temps de diffusion : Φn ' φn avecφ = 1+

√5

2 et n rounds d’émission → n = O(logN)

1

1

2

3

5

8

13


Streaming

Sommaire

Problématique

Streaming

Structuré

Non-structuré


Streaming

Rappel : problématique

Minimiser le délai entre l’émission d’un bloc et sa réceptionI Temps légèrement différé : quelques secondes au plus

(football...)I Donc pas beaucoup de relaisI Mais alors, problème de bande passante !

Maximiser la qualitéEn cas de données manquantesI Redemander ? Prend du tempsI Ignorer ? Dégrade l’image (exemple : TNT)

Éviter l’enregistrement pirate ?Protocoles propriétaires cryptés...


Streaming

Une bonne idée : l’arbre binaire

AvantageDélai court : logN


Streaming

Remarque sur l’usage des câbles

vrai MulticastLe routeur reçoit un flux et en renvoie k (implémenté dans IP).Exemple : télé par ADSL

DSLAMflux entrantflux sortant 1flux sortant 2

paire torsadee

ordi. pair

Remarque importante : faisable seulement par les FAI !

Multicast P2PC’est le pair qui doit s’en charger

DSLAMflux entrantflux sortant 1flux sortant 2

paire torsadee

ordi. pair


Streaming

Une bonne idée : l’arbre binaire

InconvénientsI déconnection racine = déconnection de dizaines de clients !I gérer la hiérachieI bande passante des feuilles inutilisée !I au contraire chaque nœud interne émet 2 fois plusI Si flux TCP : protocole inadapté au temps réel (peut tout

bloquer pour 1 paquet perdu)I free riders → feuilles


Streaming

Meilleure idée : deux arbres binaires !


Streaming

Meilleure idée : deux arbres binaires !

ComparaisonI Délai aussi court : logNI Plus de bande passante gaspillée : émission = réception chez

tout le monde (ou presque)I mais toujours : TCP, free riders, déconnections et gestion de

la topologieCours P2P – Streaming 20 décembre 2012 – 124

Streaming

Mieux que TCP ?

force et faiblesse de TCPProduire un flux sans erreur → réemissions → délais

Alternative UDPRedondance : Envoyer 1 + ε fois plus.Exemple : envoyer A, B, C , D, et A⊕ B ⊕ C ⊕ D

Multiplexage temporel : StripesI Couper le flux en k sous-flux : stripesI La réception de r stripes suffit pour recevoirI Si moins que r : dégradé mais possible


Streaming

Mieux que TCP ?


Alternative UDPRedondance : Envoyer 1 + ε fois plus.Exemple : envoyer A, B, C , D, et A⊕ B ⊕ C ⊕ DPerte de B ?



Streaming

Mieux que TCP ?


Alternative UDPRedondance : Envoyer 1 + ε fois plus.Exemple : envoyer A, B, C , D, et A⊕ B ⊕ C ⊕ DPerte de B ? A⊕ C ⊕ D ⊕ (A⊕ B ⊕ C ⊕ D) = B ! !Ici redondance : 20%. Mieux que XOR : Reed-Solomon,...



Structuré

Sommaire

Problématique

Streaming

Structuré

Non-structuré


Structuré

Splitstream [Castro & al 2004]

HypothèseLes pairs n’ont pas tous le même uploadI Beaucoup → fort degréI Peu → faible degré

ArchitectureI k StripesI donc k arbres de diffusion : un par stripeI On aimerait bien :

I qu’un sommet soit nœud interne dans un arbre seulement(et donc feuille dans les k − 1 autres)

I Donc ratio feuilles / nœuds internes = k − 1→ arbres k-aires complets, idéalement


Structuré

Stratigraphie de Splitstream

PastryUne DHT parmi d’autres (topologie : hypercube comme Kademlia)

ScribeMaintient un arbre de diffusion grâce à Pastry

SplitstreamA première vue, semblable à k fois Scribe pour maintenir k arbres.


Structuré

Architecture de Splitstream

I Chaque stripe reçoit un hash → numéros “uniforméments”répartis dans [0, ..2128[

I Chaque pair aussi a un hashI Un pair va transmettre prioritairement la stripe de hash la

plus proche du sienI Le responsable de la stripe est le pair le plus proche

(indexation DHT normale)I Chaque pair doit se connecter à k autres

(pour avoir toutes les stripes) k : paramètre globalI Chaque père accepte f fils et leur redistribue ses stripes

f dépend de la capacité d’upload


Structuré

Protocoles de connectionDu côté du pèreI Accepte jusqu’à f filsI Si trop de fils : rejette ceux à qui il ne transmet pas sa stripe

prioritaireI Si encore trop : rejette les plus loin de lui (en distance de

hash)

Du côté d’un filsI Doit se connecter à un père par stripeI Essai par parcours en profondeurI On part du père de la stripe, qui est connu grâce a la DHTI Si rejet : un de ses filsI etc etc (parcours en profondeur)


Structuré

Analyse

AvantagesI Preuve (probabiliste) que la transmission se fait (si f ≥ k)I Délai courtI Bande passante bien répartie : émission = réception (optimal)

InconvénientsI Problème si f < k en moyenne : plus assez de nœuds internes,

trop de feuilles → effondrementI Maintenir cette toplogie compliquée : durI Toujours le problème des free riders (f = 0)


Non-structuré

Sommaire

Problématique

Streaming

Structuré

Non-structuré


Non-structuré

Abandonner la structure ?

Maintenir la topologie est coûteux et complexeEssayer des réseaux non-structurés !

TopologieLe graphe des connections entre pairs est “n’importe quel”sous-graphe du graphe des connaissances

Algorithme de diffusionEssentiellement une inondation intelligente !


Non-structuré

Propagation épidémique

Propagation épidémique = inondation intelligenteÉtudient plusieurs stratégies : donner1. Un bloc au hasard à un voisin au hasard2. Le bloc le plus récent à un voisin au hasard3. Le bloc le plus récent à un voisin qui ne l’a pas4. À un voisin le bloc le plus récent qu’il n’a pas

Efficacité3 et 4 sont à un facteur constant de l’optimal (délai et débit) !

InconvénientI Il est trop facile d’être free-rider !I Attention à l’overhead


Non-structuré

Propagation épidémique : simulationsOn peut évaluer numériquement différentes stratégies

0 10 20 30 40 500

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Delay

Rat

e

lumdmdlulurulbrurplumdrurplb


Non-structuré

Propagation épidémique : simulations

Plusieurs facteurs sont àprendre en compte :I Bande passanteI HétérogénéitéI Type d’overlayI Fraicheur des mapsI . . .

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 20

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Upload relative speed

Diff

usio

n ra

te

lumdmdlulurulbrurplumdrurplb

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 25

10

15

20

25

30

35

40

45

50

Upload relative speed

Del

ay

lumdmdlulurulbrurplumdrurplbTheoretical limit


Non-structuré

BitTorrent à fenêtre

Avantages de BitTorrentI Protocole efficace.I Le graphe des échanges est non-structuré.I Grâce à l’incitation à l’émission (tit-for-tat) la bande

passante est bonne

Faiblesse pour le temps réelLa politique de téléchargement du bloc le plus rare “garantit”même équirépartition des blocs. Ce qu’on ne veut pas : si chunksinfinis, start-up = TL !

PatchModifier la priorité des blocs


Non-structuré


Approche par tronçons [PPLive, RedCarpet, ...]

I La source découpe le flux en gros blocsI On télécharge le bloc B(t) (découpé en petits sous-blocs) en

BitTorrentI Pendant qu’on regarde B(t) on télécharge B(t + 1)

I Puis on passe aux blocs B(t + 2), B(t + 3)...I La source peut gérer le démarrage de chaque pair en donnant

un sous-bloc du bloc B(t) à chacun, puis ils se débrouillentI Inconvénient : temps de démarrage = temps d’un bloc ou deuxI Le délai est aussi le temps d’émettre deux blocs


Non-structuré


Approche par fenêtre glissante [Pulse, BASS, ...]

I Petits blocs (très vite échangeables)I La priorité est une fonction de la rareté et de l’urgence

(temps avant l’affichage du bloc)I Problème : si on veut un petit délai, tous les blocs sont très

urgents !I Même si la connection est très rapide, le buffering ne sert à

rienI Les déconnections font perdre du temps : moins intérêt qu’en

BitTorrent


Non-structuré


Approche par scheduler modifiéµ-torrent possède une fonction fluxI Idée : changer les priorités des chunks (fenêtre/rarest)I Avantage : permet de lancer la vidéo assez vite dès qu’il y a

assez de mondeI Inconvénients :

I Risque de perturbation de la distribution des chunksI Syndrome du chunk lentI VoD, pas Live ;)


Non-structuré

Arbre de clusters : Prefixstream [Gai Viennot 2003]

Topologie hybrideI Localement : non-structuré (cluster de plusieurs nœuds)I Globalement : les clusters forment des arbres

nœuds-internes-disjoints

ProtocoleI Dans un cluster : diffusionI Entre les clusters : suit la topologieI Incitations à l’émission (échanges bidirectionnels)→ plus de free riders

I Basé sur le graphe de De Bruijn


Conclusion générale

Domaine très récent, en plein essorI Donc beaucoup de nouvelles applications

I partage de fichiers personnels www.peerple.netI radio, télévisionI Sauvergarde coopérativeI Petites annonces, jeux, VoD etc etc...

I Et aussi de domaines de recherche en plein essorI DHT (recherches plus puissantes, robustesse...)I AnonymatI Incitations à la coopération (à la BitTorrent)I Protocoles etc etc

Stagiaires, doctorants et chercheurs recherchés !

Cours P2P – Conclusion 20 décembre 2012 – 141

RemerciementsCe cours doit beaucoup àI Laurent ViennotI Fabien de MontgolfierI Franck PetitI Yang Guo et Christophe NeumannI Jon CrowcroftI Jim KuroseI Matthew AllenI Manan Rawal


Questions


unebrêvehistoiredupair-à-pairavant. seuiltechnologique. i....

Documents