Les technologies pair-à-pair Bruno Richard HP Laboratories Grenoble.
-
Upload
annette-paillard -
Category
Documents
-
view
106 -
download
0
Transcript of Les technologies pair-à-pair Bruno Richard HP Laboratories Grenoble.
Les technologies pair-à-pair
Bruno Richard
HP Laboratories Grenoble
brun
o.ri
char
d@hp
.com
Agenda
• Présentation du pair-à-pair (P2P)
• Le calcul P2P
• Les systèmes d'échange de fichiers P2P
• Etude de propriétés
• Conclusion
brun
o.ri
char
d@hp
.com
Exercice de mise en condition
• Etude de cas :– Je suis un utilisateur d’Internet– Je désire partager des ressources
• Quels sont mes besoins ?– Type d’applications– Fonctionnalités– Caractéristiques
brun
o.ri
char
d@hp
.com
Quelques définitions…• Il n’y a pas consensus sur une définition :
– “Sharing of Computing Resources via Direct Exchange Between Computers”• [Intel, 2000]
– “Every entity is both a client and a server”• L’isotropie n’est pas fondamentale (Kazaa)
– “Computing from the edge of Internet”• Aussi “[…] from the dark matter of Internet”
– « P2P is a class of applications that takes advantage of resources -- storage, cycles, content, human presence -- available at the edges of the Internet »
• [Shirky]
• Mardi 28 janvier, le Dauphiné Libéré– « Partager ses richesses […] gratuitement »– « Prêter un logiciel de la main à la main, […] avec des millions d’amis »
brun
o.ri
char
d@hp
.com
Définition du pair-à-pair
"Le Pair à Pair est une classe de systèmes
auto organisants qui permettent de
réaliser une fonction globale
de manière décentralisée,
en tirant parti du partage des ressources
disponibles sur un grand nombre
d'extrémités de l‘Internet"
brun
o.ri
char
d@hp
.com
Aspect social
• Le P2P nécessite un contrat communautaire moral• Coopération pour le partage de ressources
– On utilise les ressources des autres– On offre ses ressources locales
• Fichiers, CPU, stockage, bande passante
• Pas de Freeloading s.v.p. !– Récupération de données sans en partager– Rupture du contrat– Provoque un déséquilibre du système
brun
o.ri
char
d@hp
.com
Auto organisation
• Facilité d’utilisation– Et aussi d’installation et de démarrage– Pas d’administrateur local– Pas d’administrateur global
• Gestion automatique de la dynamicité– Volatilité des machines– Déconnexions violentes– Hétérogénéité
• Découverte de ressources automatique– Et annonce automatique
• Gestion du réseau– Adaptation aux conditions (modem, LAN, 802.11)– Support de la mobilité (roaming)– Accès aux ressources à distance
brun
o.ri
char
d@hp
.com
Passage à l’échelle
• Grand nombre de machines– Jusqu’à plusieurs millions
• Le système doit rester efficace– Un serveur central doit être bien dimensionné– Travail >= O(N)
• CPU• Réseau• Mémoire (dont stockage)
• Un système P2P doit être en O(log(N))– Au moins sur sa fonction essentielle
brun
o.ri
char
d@hp
.com
Aspects légaux• Est-on responsable du contenu de ses disques ?
– Certaines jurisprudences semblent le montrer• Vente d’objets nazis sur eBay• Groupes pédophiles sur Compuserve en Allemagne
• Peut-on faire une copie de ses propres documents ?– A usage personnel pour l’instant– Une tentative de limitation est en cours en France
• Mise des gens en relation– Passible de poursuites : Exemple de Napster
• Naisance en 1998 – The Killer app• Limité à une fonction d’annuaire• Rien d’illégal sur les serveurs• Attaque de Métallica – Plus de MP3 que d’albums vendus !
– 250000 adresses IP tracées• A été interdit en Mai 2002
• Digital Millenium Copyright Act (DMCA)– Emprise forte des éditeurs (Hollywood business)– Recording Industry Association of America (RIAA) (SACEM aux US)
brun
o.ri
char
d@hp
.com
Anonymat
• Réseau insaisissable– Pas le cas de Napster
• Publication anonyme
• Edition anonyme
• Récupération anonyme
brun
o.ri
char
d@hp
.com
Systèmes non P2P
• Téléphone
• NNTP
• DNS
• Microsoft .NET
• Akamai
brun
o.ri
char
d@hp
.com
Composants
Système de mise en relation
Détection et gestion des ressources
locales
Détection et gestion des ressources
locales
Détection et gestion des ressources
locales
Transport Transport
Ressources
Ressources
Ressources
• Ces composants sont essentiels au P2P• D’autres composants peuvent exister
– Sécurité– Routage
brun
o.ri
char
d@hp
.com
Direct• Gnutella, FastTrack, Napster,
eDonkey2000
Favorise la performance
Fonction de transport
Indirect• Freenet, OceanStore, SETI@home
Favorise l’anonymat
Prévient la censure
• Quel est le mode de transport entre les pairs ?
brun
o.ri
char
d@hp
.com
Système de mise en relation
• Plusieurs architectures possibles– Centralisée
• Napster, SETI@home
– Serveurs distribués• eDonkey2000
– Superpeers• Catalogues hiérarchiques• Election automatique• FastTrack, Kazaa, BearShare
– Distribuée• Gnutella, Freenet, Chord
Pure P2P
Hybrid P2P
Centralized P2P
brun
o.ri
char
d@hp
.com
Qui cherche trouve
• Systèmes à base de recherche– Search…– Gnutella, Kazaa– Search « Madonna*.mp3 »
• Systèmes d’archivage– Find…– Freenet, CAN, Chord– Find value for key « 32a48e76df26ba09 »
brun
o.ri
char
d@hp
.com
TaxonomiePair-à-pair
CalculCentré données
Centré utilisateur
Overlays Inondation
Annuaire
Déterministe
Aléatoire
brun
o.ri
char
d@hp
.com
Search…
TaxonomiePair-à-pair
CalculCentré données
Centré utilisateur
Overlays Inondation
Annuaire
Déterministe
Aléatoire•CAN, Chord, Pastry
•Clé Données
•Les données sont toujours accessiblesFind…
brun
o.ri
char
d@hp
.com
Find…
TaxonomiePair-à-pair
CalculCentré données
Centré utilisateur
Overlays Inondation
Annuaire
Déterministe
Aléatoire
•Freenet
•Clé Données
•On ne trouve pas toujours une donnée existante
•Les données sont répliquées à l’utilisation
•Résiste aux pics de charge
Search…
brun
o.ri
char
d@hp
.com
TaxonomiePair-à-pair
CalculCentré données
Centré utilisateur
Overlays Inondation
Annuaire
Déterministe
Aléatoire
•Gnutella
•Clé Données
•On recherche les données par requêtes aux voisins
brun
o.ri
char
d@hp
.com
TaxonomiePair-à-pair
CalculCentré données
Centré utilisateur
Overlays Inondation
Annuaire
Déterministe
Aléatoire
•Napster
•Recherche dans un annuaire
•Annuaire distribué dans certains systèmes•Kazaa, eDonkey2000, winXP, FastTrack
•Résistance à la censure
•Super-peers
brun
o.ri
char
d@hp
.com
TaxonomiePair-à-pair
CalculCentré données
Centré utilisateur
Overlays Inondation
Annuaire
Déterministe
Aléatoire
•Groove, JXTA (!?), ICQ, Jabber, MSN Messenger
•Importance des sémantiques de données
•Informations mutables et/ou « jetables » (voix, SMS,…)
brun
o.ri
char
d@hp
.com
TaxonomiePair-à-pair
CalculCentré données
Centré utilisateur
Overlays Inondation
Annuaire
Déterministe
Aléatoire
•SETI@home, Décrypthon
•Modèle master-workers
•Gros calcul exécuté par petits morceaux
brun
o.ri
char
d@hp
.com
TaxonomiePair-à-pair
CalculCentré données
Centré utilisateur
Overlays Inondation
Annuaire
Déterministe
Aléatoire
•Autres systèmes hors taxonomie
•Recherche sur Internet (InfraSearch)
•Evaluation de performance de sites Web
http://www.porivo.com/
Modèle de business viable ?
brun
o.ri
char
d@hp
.com
Historique
19501950 19601960 19701970 19801980 19901990
19571957Sputnik Sputnik ARPA ARPA
19621962ARPAnetARPAnetProposedProposed
19711971email Appearsemail Appears
19691969First 4-node First 4-node
ARPAnetARPAnetWWW ProposedWWW Proposed
1992199250 Web Servers 50 Web Servers on the Interneton the Internet
19931993Mosaic AppearsMosaic Appears
1994199410K Web Servers 10K Web Servers
on the Interneton the Internet
brun
o.ri
char
d@hp
.com
Internet 1ère génération
• Accès direct entre les machines (Arpanet)– telnet, ftp, gopher, wais
• Démarrage en 1970
• Les protocoles sont ouverts et amicaux
brun
o.ri
char
d@hp
.com
Internet 2ème génération
• World Wide Web– Tim Berners-Lee proposed protocols– HTTP, HTML
• Hyperliens de page a page– Internet devient une toile (Web)
• L’utilisateur est au centre du Web– Mais la publication est difficile
brun
o.ri
char
d@hp
.com
Map of the Internet, December 1998 [http://www.lumeta.com/]
brun
o.ri
char
d@hp
.com
Internet 3ème génération
• Technologies pair-à-pair
• L’information n’est plus liée au réseau– Plus de notion de serveur
• Adaptation aux conditions réelles– Administration complexe et coûteuse– Volatilité des ressources physiques
brun
o.ri
char
d@hp
.com
Les précurseurs
• Colonies de fourmis (Ant routing)– Recherches sur le routage par phéromones– Construction d’agrégats de ressources
– Le processus local ne reflète pas l’activité de la communauté
• Agents– Délégation de missions a des entités logicielles autonomes
• Prennent ensuite l’initiative sur Internet pour fournir un résultat– « Trouve moi un billet d’avion pour Barcelone, une voiture
et une chambre d’hôtel »
brun
o.ri
char
d@hp
.com
Enjeux
• Le P2P est très utile aux utilisateurs– Accès a des banques de ressources énormes– Gratuité
• Qui y trouve un intérêt ?– On vend moins de hardware
• Les serveurs ne sont plus nécessaires– Difficile de faire payer les services
• Metering, Accounting, Reputation pas au point– Qui va donc payer les développements
• Equipes de recherche• Enthousiastes, hackers
• => Business model à trouver
brun
o.ri
char
d@hp
.com
Agenda
• Présentation du pair-à-pair (P2P)
• Le calcul P2P
• Les systèmes d'échange de fichiers P2P
• Etude de propriétés
• Conclusion
brun
o.ri
char
d@hp
.com
Classes de problèmes• Grain de calcul
– Gros : Pas de communication entre machines• Sauf au début (fork) et à la fin (join)
– Moyen : Communication sporadique• Echelle : Boucle de calcul• Modèle OpenMP : Compilateurs produisant un code parallèle
– Fin : Communication continue• Supercalcul avec Linpack (inversion d’une matrice)• Modèle MPI : Passage de messages (send/receive)
• SIMD/SPMD/MIMD
• Seul le gros grain est aujourd’hui possible en P2P1. Les latences réseau sont trop grandes
– Notre transport est Internet2. L’hétérogénéité des machines est difficile à gérer
– De Pentium 66 aux supercalculateurs multiprocesseurs
• Les capacités CPU sont très supérieures aux capacités réseau
brun
o.ri
char
d@hp
.com
Historique
• I-WAY, 1995– Argonne Nat’l Labs– Fédération de ressources académiques
• GRID computing– Ian Foster, 1998– Globus
• Global computing– DES III challenge, janvier 1992.
• Cassage du DES en 22 heures• Dizaines de milliers de machines
• Metacomputing– [Larry Smarr, NCSA, 1992]– SETI@home, Décrypthon
brun
o.ri
char
d@hp
.com
Systèmes de calcul distribué
3 types de grands systèmes distribués
Les Grilles de calcul ou « GRID »
Clusters interconnectés
« Metacomputing » ou « Internet Computing »Pas de communications
entre machines
Les systèmes Pair à Pairvolatilité
Grands sitesde calcul,Clusters
(<100 x 100)
PCWindows,
Linux(~10 000 000)
brun
o.ri
char
d@hp
.com
GRID Computing
• Global Grid Forum (GGF)• Globus Toolkit
brun
o.ri
char
d@hp
.com
Metacomputing
• Calcul sur la base du volontariat
• Utilisation des ressources inexploitées
brun
o.ri
char
d@hp
.com
SETI@home• MetaComputing
– Recherche d’extraterrestres– Données provenant du télescope
d’Arecibo au Mexique– Chaque machine reçoit un job individuel et
renvoie un résultat après ses calculs
• Plus de 4 200 000 utilisateurs !– Totalisant 1 300 000 années de calcul
• Découverte des ressources pseudo-automatique
– Volontariat
• Applications figées
• Pas de communications inter-machines
brun
o.ri
char
d@hp
.com
Confinement d’exécution - Sandboxing
• Nécessité d’isolation– Fichiers/Process/Sessions utilisateur
• Pas question de risquer ses données– Process de métacalcul
• Tentatives d’accélération de SETI@home• Tricheurs
– Protection contre les fautes• Software-based fault isolation (SFI)
– Pas de hardware spécifique– Java Virtual Machine [Javelin]– Internet C++
• Machine virtuelle POSIX• Trusted code
– Ca devrait être le cas pour SETI@home– Pas de mécanisme disponible aujourd’hui
• Microsoft .NET– On attend encore
brun
o.ri
char
d@hp
.com
Perspectives
• Besoin d’environnements de programmation– Aujourd'hui les applications sont figées
• Amélioration de la sécurité– Comment se protéger des fautes– Comportements byzantins et malicieux
• Limité à quelques applications– Oui, mais un business assez juteux– Intel, AMD utilisent Netbatch
• I-Cluster– Reconnaissance de clusters de machines au repos– Un domaine de recherche original [HP Labs, INRIA]
brun
o.ri
char
d@hp
.com
Agenda
• Présentation du pair-à-pair (P2P)
• Le calcul P2P
• Les systèmes d'échange de fichiers P2P
• Etude de propriétés
• Conclusion
brun
o.ri
char
d@hp
.com
Types de systèmes
• 3 types de systèmes (rappel)– Annuaire– Inondation– Overlays
• Quelques autres systèmes précurseurs– Pas vraiment P2P toutefois…
brun
o.ri
char
d@hp
.com
FICUS et BAYOU
• Distributed file systems– Années 1990– Ces systèmes ont eu leur heure de gloire– Données mutables (read-write)
• Réplication optimiste– On réplique les données– On réconcilie les versions en cas de conflit
• Modèles de cohérence intéressants• Peu enclins à la scalabilité
– Réplication en O(N)
brun
o.ri
char
d@hp
.com
ROAM
• Topologie en anneau d’anneaux– Ward model
• Election automatique– Ward Masters– Maîtres de l’anneau local– Participent au super anneau
• Propriétés de localité– Géographique ou topologique– Support du roaming
• Scalabilité moyenne– Version vectors
• Projet pas fini– Pas d’ajout dynamique de noeuds– Pas de suppression de nœuds– Peu de documentation
Super Ward
Ward
WardWard
Ward masters
brun
o.ri
char
d@hp
.com
Architectures totalement distribuées
• Le système de mise en relation nécesite– Topologie– Routage
• Contraintes : – Minimisation de l’utilisation des liens du réseau– Temps de recherche court (diamètre faible)– Complexité de reconstruction de la topologie en présence de volatilité– Résistance des propriétés du routage en présence de volatilité– Résistance aux attaques ciblées
Méthodes de recherche :
Exploration du graphe(aléatoire ou guidée)
Routage de requêtes(par clés ou intervalles)
brun
o.ri
char
d@hp
.com
Modèle par annuaire
• OceanStore– Annuaire distribué
• Exemple de Napster– Un seul serveur central
• Annuaire• NomDeFichier <-> Pair
– Liens statiques pairs-serveur• Annonce de présence• Ressources locales• Capacités de communication• Charge en cours
– Communication continue• Heartbeat
Serveur d’annuairewww.napster.com
Pairs sur Internet
brun
o.ri
char
d@hp
.com
Recherche d’un fichier
• Le Pair A veut un fichier– Requete au serveur
central• Une liste complète est
aussi disponible
– « Search bratisla*.mp3 »– Réponse du serveur
• Fichiers sur C et D• S’assure que les machines
sont actives
Pair A
Pair C
Pair D
Requête Réponse
brun
o.ri
char
d@hp
.com
Récupération du fichier
• Connexion directe– De A à C
• « Get bratislaboys.mp3 »• Protocole de download direct• Gestion d’erreurs triviale
– Pas de gestion des reprises– Pas de hammering
• Une seule source
• Beaucoup mieux aujourd’hui– Kazaa, eDonkey2000, WinXP
Pair A
Pair C
Pair D
Demande Download
brun
o.ri
char
d@hp
.com
Modèle par inondation
• C’est un modèle isotropique– Les pairs sont libres et égaux en dignité et en droit
• Chacun dispose de données locales– Aucune notion de réplication– Chaque recherche repart de zéro
• Diffusion en vague d’une requête
brun
o.ri
char
d@hp
.com
Gnutella
• Liste de pairs– Locale à chacun– Quelques centaines– Evolutive
• En fonction d’événements divers
• Sessions permanentes– Sur 5 à 9 pairs– Routage des messages
• Continuel
brun
o.ri
char
d@hp
.com
Gnutella : Les messages
• Messages– Ping
• Annonce de présence– Pong
• Réponse au ping• IP/port du réceptionnaire attachée• File padding
– Query• Requête de recherche• Vitesse minimum du répondant
– QueryHits• Réponse au message Query• Nombre de fichiers en réponse avec leurs index
brun
o.ri
char
d@hp
.com
Gnutella : Query
• Routage par broadcast contraint
• Requête en vague (ou inondation)– Vers tous les voisins– Chacun fait une recherche locale…– …et relaie la requête à tous ses voisins– Les messages déjà reçus sont ignorés
• Evite les cycles
– Chaque message a un Time-To-Live
1
2
2
34
4
3’
brun
o.ri
char
d@hp
.com
hit
Gnutella : QueryHit
• Recherche locale– Par chaque pair lors du Query
• Relais inverse– Adresse / Descripteur de fichier– Réponses positives seulement– Aggrégation des retours
• Padding ou stuffing
• L’émetteur original choisit un fichier (et le pair associé)
• Le download se fait alors en direct
3
2
1
Download
brun
o.ri
char
d@hp
.com
Passage a l’échelle de Gnutella
• Ca ne marchera jamais !– Au passage des 20 000 utilisateurs, écroulement– Observé en été 2000– Why Gnutella Can't Scale. No, Really. [Ritter2000]
• Les leçons tirées– Nécessité de modéliser/simuler/émuler– Hubs BearShare
• SuperPeers permettant d’étendre le système• Mais pas en O(log(N)) !
brun
o.ri
char
d@hp
.com
Modèle par overlay d’arbres
• Principe des overlays :– Soit une communauté représentée par un graphe d’interconnexion– Chacun est à la racine d’un arbre de profondeur 1, d’arité variable
• Cet arbre est un plongement du graphe total du réseau– Chaque membre de la communauté (pair) possède un ID (identifiant)
unique– Un algorithme local permet le routage
• Routage de proche en proche• Routage vers un des nœuds de l’arbre local• de router globalement vers un ID quelconque de l’espace des ID
• Aussi appelé Distributed Hash Tables (DHT)• La mode : Les Plaxton Meshes (Pastry)• Ancêtre : Routage par hypercubes
brun
o.ri
char
d@hp
.com
Modèles d’overlays triviaux• Modèle client serveur
– L’arbre local est limité à la connaissance du serveur
– L’arbre du serveur est complet
• Anneau simple– L’arbre est limite au nœud suivant
• Graphe complet– L’arbre local est le graphe complet
• Ces modèles sont des cas d’école uniquement
brun
o.ri
char
d@hp
.com
Routage par hypercube• Utilisé en architectures parallèles (années 1980-90)• Cube virtuel en dimension N• 2N participants (hypercube complet)• Chaque nœud a un ID sur N bits• Chaque nœud a voisins directs• Routage très simple de X = {x0 x1 x2} vers Y = {y0 y1 y2} :
Pour i = 0 à N-1Si xi != yi
router x0..xi..xN-1 vers x0..xj..xN-1
Sortie de la boucleFinSi
FinPour
• Routage de proche en proche• Exemple en dimension 3 : De 001 a 010
– 001 -> 011– 011 -> 010
• Algorithmique simple et efficace– 65536 nœuds en dimension 16
• Mais chacun doit être présent– Pas de volatilité des nœuds possible
000
010
001
011
100
110
101
1111
0
2
brun
o.ri
char
d@hp
.com
UUIDs• Universally Unique Identifier• Identifiant de 128 bits (parfois 160)• Statistiquement unique
– Probabilité d’anniversaire 264 pour tomber sur deux UUID égaux• Généré à partir de divers composants
– Uniques• Adresse IP• Hachage du contenu d’un fichier• Nom du fichier
– Dynamiques• Estampille temporelle
– Aléatoires• Tirage au sort
• Secure Hash Algorithm (SHA-1)– Fonction non inversible en un temps non polynomial– Mieux que MD5
brun
o.ri
char
d@hp
.com
Freenet• Un système d’échange de fichiers P2P• Algorithmique très simple, voire canonique• Décentralisation complète• Isotropique• Anonymat
– Pour la publication d’informations– Pour la récupération des informations– Résistance à la censure
• Open source– Beaucoup de sous projets, contributions, analyses, recherches
• Résistance aux Hot spots (slashdot effect)– La réplication est basée sur la popularité des fichiers– Plus un fichier est récupéré, plus il est répliqué
brun
o.ri
char
d@hp
.com
Freenet : Publication d’un fichier
• Chaque pair a un ID• Le Fichier est publié sur 1201• L’ID du fichier est calculé : 3303
– Hachage du nom de fichier
• Processus récursif :– Le fichier est caché localement– Si pair avec ID plus proche
lexicalement de 3303 que l’ID local alors réplication sur ce pair
3120
2102
02001201
3022
2010
0102
3302
3303
1:Publication
3303
3303
2:Réplication
33033:Réplication
brun
o.ri
char
d@hp
.com
4:Copy file
3303
33033303
Freenet : Récupération d’un fichier
• Demande du fichier d’ID 3303 depuis 0200
• Processus récursif :– Si pair avec ID plus
proche lexicalement de 3303 que l’ID local alors requête transmise vers ce pair
– Si le fichier est trouvé il est copié vers l’appelant
3120
2102
02001201
3022
2010
0102
3302
3303
1:Get 33032:Get 3303
hit
3303
3:Copy file
brun
o.ri
char
d@hp
.com
Problème de convergence locale
• Exemple– Si 3303 est cherché à partir de
0102, il ne sera pas trouvé
• Freenet fait donc du backtrack– Essai sur le 2ème voisin
répondant le mieux– Un Time-To-Live (TTL) est
associé à chaque message• Limite la durée de vie
33033303
3120
2102
02001201
3022
2010
0102
3302
3303
1:Get 3303
2:Failed
brun
o.ri
char
d@hp
.com
Freenet : ajout d’un nœud
• L’ajout d’un nœud dans Freenet se fait par connaissance d’un seed– C’est un nœud déjà membre d’une communauté
Freenet– Il va « transférer » sa liste de voisins au nouveau– Cette liste évoluera ensuite aléatoirement
• La destruction des nœuds est automatique– Les nœuds les plus anciens ne sont plus
référencés
brun
o.ri
char
d@hp
.com
Apprentissage dans Freenet
[Georges Da Costa, ID-IMAG / INRIA]
brun
o.ri
char
d@hp
.com
Résistance aux attaques/partitions
La connaissance est bien distribuéeIl faut une grosse attaque pour poser de réels problèmes
brun
o.ri
char
d@hp
.com
Freenet
• Nécessite de connaître les clés
• Garbage collectionDisparition des vieux fichiers
• On ne trouve pas toujours un fichier existant
• Charge importante– En bande passante réseau– En stockage local (cache des fichiers)
brun
o.ri
char
d@hp
.com
Chord
• Lab of Computer science, MIT• Ressources (Key, Value)• Système complètement distribué• Ne garantit pas l’anonymat
– Mais le temps de recherche est prévisible
• Coût de communication et de gestion en log(n)• Equilibrage de charge
– Fonction de hachage distribuée équitablement
• Changement dynamique des tables– Pour le support de la volatilité des nœuds
• L’espace de clé est plat– Pas de hiérarchie
brun
o.ri
char
d@hp
.com
Chord : Placement clés-nœuds
• Les identifiants (nœud et clé) sur m bits sont ordonnés sur un cercle modulo 2^m
• La clé k est assignée au nœud k ou à son successeur• Redistribution de K/N clés
pour N nœuds volages• Exemple :
– Nœuds 0, 1, 3 disponibles– Stockage des clés 1, 2 et 6
• Propriétés :– Distribution équilibrée des clés
01
2
3
4
5
6
7
6
1
2
Successeur(2) = 3
Successeur(1) = 1
Successeur(6) = 0
brun
o.ri
char
d@hp
.com
Chord : La recherche• Identifiants (nœud et clé) sur m bits• Chaque nœud a une table de m entrées• Nœud[n].table[i] =
nœud[(n+2^i) mod 2^m].next• Exemple :
– m=3– Nœuds 0, 1 et 3 disponibles
• Caractéristiques :– Peu d’info supplémentaires– Pas de connaissance
totale (3 ne connaît pasle successeur de 1)
• Routage :– Si n ne connaît pas k :
n contacte le premier nœud précédant k.– Ce processus est récursif– Le nœud qui possède k répond à n
01
2
3
4
5
6
7
6
1
2
Start Interv Succ 1 [1,2) 1 2 [2,4) 3 4 [4,0) 0
Start Interv Succ 2 [2,3) 3 3 [3,5) 3 5 [5,1) 0
Start Interv Succ 4 [4,5) 0 5 [5,7) 0 7 [7,3) 0
brun
o.ri
char
d@hp
.com
Chord : Ajout d’un noeud
• 3 étapes :1. Construire une table en
contactant un nœud n’ déjà connu
2. Réactualiser les tables des nœuds
3. Transférer les clés dont le nouveau nœud est responsable
• Retrait :– Chacun remplace les
disparus par leur successeur
01
2
3
4
5
6
7
6
1
2
Start Interv Succ 1 [1,2) 1 2 [2,4) 3 4 [4,0) 6
Start Interv Succ 2 [2,3) 3 3 [3,5) 3 5 [5,1) 6
Start Interv Succ 4 [4,5) 6 5 [5,7) 6 7 [7,3) 0
6
2
2
2
Start Interv Succ 7 [7,0) 0 0 [0,2) 0 2 [2,6) 3
1
brun
o.ri
char
d@hp
.com
CFS au-dessus de Chord• CFS/Chord est constitué de 3 couches logicielles• Chord API:
• localise(Clé): @IP
• DHash API:• Put(clé, Data)• get(clé):Data
– Gestion de la réplication• Par le 1er successeur (sur r successeurs)
– Gestion du cache• Cache des blocs (Clé, Data)
– Authentification• CFS API:
• Insert(Filename)• lookup(Filename): Fichier
– Chunking des fichiers• Limite la taille maximale des blocs• Ajoute de la redondance (FEC ?)
– Blocs de données– Blocs de métadonnées
brun
o.ri
char
d@hp
.com
CAN (Content Adressable Networks)
• University of Berkeley• Table de hachage distribuée• Insertion, recherche et destruction de paires (clé, valeur) • Système complètement distribué• Coût de gestion indépendant du nombre de sites
brun
o.ri
char
d@hp
.com
CAN : Placement clés-nœuds• Tore cartésien virtuel
– Dimension d
• Espace partagé en zones– Un nœud responsable par zone
• Association clé-point déterministe– Fonction de hachage– K => Point P dans l’espace des
coordonnées– P => Zone Z => Responsable R– La paire (clé, valeur) est stockée
sur R
• Donc– K => Valeur
0,0
1,0
1,0
C(0-0,5 ; 0,5-1,0)
A(0-0,5 ; 0-0,5)
B(0,5-1,0 ; 0,0-0,5)
D E
(0,5-0,75 ; 0,5-1,0)
(0,75-1,0 ; 0,5-1,0)
brun
o.ri
char
d@hp
.com
CAN : Routage• Chaque nœud maintient une
table– Adresses IP de ses voisins– Zones de coordonnées
associées• A est voisin de B• B est voisin de D
– mais A n’est pas voisin de D
• Routage glouton– Dans la topologie à d dimensions
• Distance moyenne = O (n^1/d)– (pour n zones)
• Routage tolérant aux défaillances
0,0
1,0
1,0
C(0-0,5 ; 0,5-1,0)
A(0-0,5 ; 0-0,5)
B(0,5-1,0 ; 0,0-0,5)
D E
(0,5-0,75 ; 0,5-1,0)
(0,75-1,0 ; 0,5-1,0)
brun
o.ri
char
d@hp
.com
CAN : Ajout d’un nœud• Associer le nœud à une nouvelle zone
• Principe :– Trouver un nœud existant– Couper son espace en deux
1. Obtenir l’adresse d’un nœud2. Choisir un point P au hasard3. Envoyer une requête de découpage au nœud
responsable de P4. Le nœud responsable renvoie le nouveau
découpage5. Il prévient ensuite ses voisins
• Mécanisme de connectivité du graphe– Tolère les défaillances
• Exemple en 2D– Découpe selon X et Y
• Retrait d’un nœud– Agrégation de 2 zones– Si pas possible, on agrège la plus petite zone
0,0
1,0
1,0
C(0-0,5 ; 0,5-1,0)
A(0-0,5 ; 0-0,5)
B(0,5-1,0 ; 0,0-0,5)
D E
(0,5-0,75 ; 0,5-1,0)
F
brun
o.ri
char
d@hp
.com
Pastry
• Microsoft Research, University of Rice, Cambridge• « Scalable decentralized object location and
routing »• Table de hachage distribuée• Système complètement distribué• Propriétés de localité dans le routage• Applications basées sur PASTRY
– PAST (Persistent Storage utility)– SCRIBE (event notification infrastructure)– Squirrel (Decentralized web cache)
brun
o.ri
char
d@hp
.com
Pastry : Placement clés-nœuds
• Chaque nœud possède un NodeID– Identifiant unique– Aléatoire
• Espace de nœuds circulaire– 2^128 nœuds– Assignation uniforme– Des numéro adjacents concernent des
nœuds très différents
000001
010
011
100
101
110
111
brun
o.ri
char
d@hp
.com
Pastry : Routage• Routage d’une requête
– Vers le nœud qui possède le NodeID le plus proche de la clé– Nœuds vivants seulement– Routage par proximité de clé– les clés et NodeIDs sont des séquences de chiffres de base 2^b
• Dans la table chaque NodeID est associé à une adresse IP
• Exemple– b = 2 – Nœuds connus de 10233102
– Table de routage• Entrées à la ligne n partagent
n premiers chiffres avec le NodeID • (log2^b n) lignes• (2^b –1) colonnes
• Délai de routage O(log2^b n)
NodeID 10233102Smaller Larger
1023303310233001
1023302110233000
1023312010233230
1023312210233232
-0-2212102 1 -2-2301203 -3-12032030 1-1-301233 1-2-230203 1-3-02102210-0-31203 10-1-32102 2 10-3-23302102-0-0230 102-1-1302 102-2-2302 31023-0-322 1023-1-000 1023-2-121 310233-0-01 1 10233-2-32 xxxxxxxxxxxxxxxxxxxx xxxxxxxxx 102331-2-0 0
brun
o.ri
char
d@hp
.com
Pastry : Ajout d’un nœud
• Un nouveau nœud de NodeID X entre dans Pastry1. Il contacte un nœud A
2. X demande à A de router le message Join(X)
3. Pastry route le message jusqu’au nœud Z
4. Les nœuds traversés par la requête envoient leurs tables à X
5. X initialise sa table à partir de ces informations
6. X informe les autres nœuds de sa présence
• Puisque Z est proche numériquement de X, X et Z partagent les même feuilles.
brun
o.ri
char
d@hp
.com
Pastry : retrait d’un nœud
• Heartbeat entre voisins– Messages périodiques– Timeout sur inactivité– Détection des
disparitions
• Un nœud peut mourir– Ses voisins le détectent– Ils collectent les
informations des nœuds proches
– Ils remettent leur table à jour Nœuds voisins, dont 10233102
est une feuille
NodeID 10233102Smaller Larger
1023303310233001
1023302110233000
1023312010233230
1023312210233232
-0-2212102 xxxxxxxxx -2-2301203 -3-1203203xxxxxxxxxx 1-1-301233 1-2-230203 1-3-021022
…
1302102202212102
1020023022301203
1130123331203203
3130123333213321
brun
o.ri
char
d@hp
.com
JXTA• Développement par Sun• Basé sur Java (?!)
– Succès mitigé• 4 composants principaux
– Peer pipes• Connexion entre pairs• Partage d’informations sur le réseau et de manière distribuée
– Peer groups• Groupes virtuels• Dynamiques• Cohérents
– Peer Monitoring• Surveillance et mesure des interactions• Politiques de contrôle entre pairs
– Sécurité• Mécanismes d’identification, de contrôle d’accès et de confidentialité
brun
o.ri
char
d@hp
.com
Composants JXTA
brun
o.ri
char
d@hp
.com
Autres systèmes
• ICQ
• AOL Instant Messenger
• PUPS
• Clique
brun
o.ri
char
d@hp
.com
Perspectives
• Mutabilité– Mise à jour des données– Ecrivains multiples– Cohérence
• Topologie réseau– Connaissance de la localisation des machines sur le réseau– Minimalisation de la consommation réseau– Minimalisation des temps de récupération des données
• Sécurité– Authentification – Contrôle d’accès
• Observation– Simulation ou émulation– Visualisation
brun
o.ri
char
d@hp
.com
Agenda
• Présentation du pair-à-pair (P2P)
• Le calcul P2P
• Les systèmes d'échange de fichiers P2P
• Etude de propriétés
• Conclusion
brun
o.ri
char
d@hp
.com
Small World• Stanley Millgram 1967
– Diamètre des américains : 6– graphe des accointances très
connexe• Lois de distributions
– LogNormal, Power law, Zipf law, Bose-Einstein condensation law
• Université notre-Dame– Diamètre du WWW : 19
brun
o.ri
char
d@hp
.com
Les propriétés small world• Deux propriétés essentielles
– Regroupement maximal• Mes voisins se connaissent entre eux
– Chemin minimal• La distance entre deux nœuds du graphe est faible• Dans l’idéal, pour un graphe G=(E,V), max i,jV (min(Path(i,j)) est le plus petit possible
• Ces propriétés permettent de mettre en œuvre des hubs d’information– Des nœuds très communicants, connaissant beaucoup de voisins lointains– Ce sont les autoroutes (ou les avions) utiles pour aller loin
• Permet de rester « scalable », en O(log(N))
• Les systèmes P2P doivent (devraient) essayer de faire converger ces paramètres– Ce n’est pas toujours le cas
brun
o.ri
char
d@hp
.com
Lois de distribution
• Zipf law
• Extended Zipf
• Power law
• Pareto
• Exponential
• Lognormal
• Ces lois caractérisent une population
brun
o.ri
char
d@hp
.com
Sécurité
• Comment construire une chaîne de trust ?• Nécessitent des certificate authorities
– E.g. Kerberos
• Pas possible d’avoir un serveur central en P2P• Comment répudier un membre du groupe ?
– Consensus distribué
• Comment éviter le « déni de service » (DoS attacks) ?
• Des recherches en cours– Mais assez peu– Systèmes de votes statistiques, à la PGP– Ce sont des domaines difficiles
brun
o.ri
char
d@hp
.com
Réputation
• Comment juger de la qualité d’un pair ?– Volume de ressources offertes– Qualité des ressources– Détection des Freeloaders
• Problème classique eBay (auction sites)– Il est facile de tricher pour augmenter sa
réputation
• Pas de réponse satisfaisante coté recherche
brun
o.ri
char
d@hp
.com
Comptabilité
• Comment faire payer au service ?– Paiement par fichier downloadé– Par unité de calcul
• Difficile sans serveur central– Dons pas adapté au P2P isotrope
• Encore une fois, pas de bonne réponse
brun
o.ri
char
d@hp
.com
Mutabilité et cohérence
• Modification des données– Mutabilité– Cohérence
• Résilience– Checkpointing– Tolérance aux pannes
• Beaucoup de travaux en cours
brun
o.ri
char
d@hp
.com
Quelques acteurs
• Intel
• Sun
• HP
• IBM
• Microsoft
• FastTrack
• Avaki
brun
o.ri
char
d@hp
.com
Agenda
• Présentation du pair-à-pair (P2P)
• Le calcul P2P
• Les systèmes d'échange de fichiers P2P
• Etude de propriétés
• Conclusion
brun
o.ri
char
d@hp
.com
Conclusion
• Des systèmes très intéressants– Techniquement– Pour l’utilisateur
• Plein de propriétés séduisantes
• Réponse à des problèmes très communs
• Un business model qui se cherche– Quel avenir ?
brun
o.ri
char
d@hp
.com
Références
• Dejan S. Milojicic, Vana Kalogeraki, Kiran Nagaraja, Jim Pruyne, Bruno Richard, Sami Rollins, John Sontag, “Peer-To-Peer (P2P) Technology”, HP Labs technical report HPL-2002-57, http://www.hpl.hp.com/techreports/2002/HPL-2002-57.html, 2002.
• Andy Oram et al., «Peer-to-Peer: harnessing the power of disruptive technologies », O’Reilly, 2001.
• O’Reilly network: http://www.openp2p.com.