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


locales


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…



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…



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



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



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



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



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



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 ?

http://www.porivo.com/

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


• Le calcul P2P



• 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


• Le calcul P2P



• 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



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




6

2

2

2


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


• Le calcul P2P



• 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


• Le calcul P2P



• 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.

les technologies pair-à-pair bruno richard hp laboratories grenoble

Documents