Les protocoles de routage dans les réseaux pair a-pair - master informatique-s§r- 2016 -

République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université de Larbi Tébessi –Tébessa-
Faculté des Sciences Exactes et des Sciences de la Nature et de la Vie
Département : des mathématiques et informatique
MEMOIRE DE MASTER
Domaine: Informatique
Filière: Informatique
Option: Sécurité et réseaux
Thème:
Présenté par:
Brakni Tahar
Bentahar Atef
Devant le jury :
Mahmoudi Rachid M.A Université Tébessa Président
Abdelghafour Azzeddine M.A Université Tébessa Rapporteur
Ghrieb Nawel M.A Université Tébessa Examinateur
Date de soutenance: 29/05/2016
Note : ……..Mention :………..………………
Les protocoles de routage
dans les réseaux pair-à-pair

‫ملخص‬
‫شبكة‬P2P )‫الند‬‫للند‬)‫هي‬‫شبكة‬‫افتراضية‬‫ث‬ُ‫ت‬‫بت‬‫فوق‬‫طبقة‬‫شبكة‬IP‫او‬‫ما‬‫يسمى‬‫الشبكة‬‫العنكبوتية‬.‫تحتوي‬‫هذه‬
‫الشبكة‬‫على‬‫اجهزة‬‫اإلعالم‬‫االلي‬‫ا‬‫لنهائية‬‫كالحواسيب‬،‫ويجب‬‫أن‬‫يكون‬‫كل‬‫واحد‬‫منهم‬‫على‬‫قدم‬‫المساواة‬‫مع‬‫ن‬‫ظ‬‫يره‬.
‫ويعمل‬‫كل‬‫نظير‬‫بمثابة‬‫زبون‬‫و‬‫مقدم‬‫خدمات‬‫في‬‫نفس‬‫الوقت‬.‫يسمح‬‫ن‬‫ظ‬‫ام‬‫الند‬‫با‬ ‫للند‬‫ل‬‫المركزية‬‫و‬‫توزيع‬‫الموارد‬‫على‬‫كل‬
‫االقران‬،‫و‬‫كذلك‬‫االتصال‬‫والتعاون‬‫بطريقة‬‫مباشرة‬.
‫علينا‬‫أن‬‫نميز‬‫ثالث‬‫بنيات‬‫من‬‫شبكة‬P2P‫البنية‬،‫المركزية‬‫البنية‬‫الالمركزي‬‫ة‬‫التي‬‫يمكن‬‫ان‬‫تكون‬‫مركبة‬‫بانتظام‬
‫او‬‫ال‬.
‫بالنسبة‬‫للبنية‬‫الالمركزي‬‫ة‬‫المن‬‫ظ‬‫مة‬‫هناك‬‫العديد‬‫من‬،‫البروتوكوالت‬‫لكل‬‫منها‬‫خوارزميات‬‫ل‬‫لبحث‬‫تختلف‬‫من‬
‫آلخر‬ ‫بروتوكول‬.‫ولكل‬‫بروتوكول‬‫تطبيقاته‬‫الخاصة‬‫به‬،‫هاته‬‫االخيرة‬‫تعتمد‬‫على‬‫جدول‬‫التوزيع‬DHT،‫وهو‬‫ن‬‫ظ‬‫ام‬‫توزيع‬
‫الموارد‬‫على‬‫االقران‬‫باستعمال‬‫طريقة‬‫التشفير‬. Hachage
‫ومن‬‫بين‬‫البروتوكوالت‬‫التي‬‫تستعمل‬‫هذه‬‫الطريقة‬.‫نجد‬‫في‬‫هذه‬‫المذكرة‬:
Chord ,Tapestry Pastry, CAN, Kademlia, Viceroy‫و‬.Ulysses
‫معظم‬‫الدراسات‬‫السابقة‬‫تقيم‬‫أداء‬‫البروتوكول‬‫بشكل‬‫فردي‬،‫في‬‫حين‬‫يركز‬‫عدد‬‫قليل‬‫من‬‫الباحثين‬‫على‬‫المقارنة‬
‫بين‬‫البروتوكوالت‬‫مع‬‫عدد‬‫محدود‬‫من‬‫العوامل‬.
‫لمعرفة‬‫البروتوكول‬‫األمثل‬‫من‬‫حيث‬‫األداء‬،‫فإننا‬‫سوف‬‫نقوم‬‫بدراسة‬‫مقارنة‬،‫شاملة‬‫وباألخص‬
Chord،Kademlia‫و‬Pastry،‫هذا‬‫االخير‬‫لم‬‫يتم‬‫إدراجه‬‫في‬‫اي‬‫دراس‬‫بحوث‬ ‫أو‬ ‫ات‬‫من‬‫هذا‬‫النوع‬.
‫وقد‬‫تم‬‫بناء‬‫السيناريوهات‬‫في‬‫برنامج‬‫المحاكاة‬Oversim.

Abstract
The P2P is a virtual network over an existing IP network (overlay), such as the
Internet. Terminals of P2P network are called nodes or peers and they are all equals. A peer
acts as a client and server at the same time. P2P systems allow decentralization, sharing
resources, communication and directly collaboration.
We distinguish three families of P2P architectures: The centralized and the distributed,
the latter can be structured or unstructured, and the hybrid architecture.
For structured decentralized architectures, there are many implementations, integration
algorithms and search are differents for each one of implémentations.
These algorithms are based on a distributed hash table (DHT) that representes the
decentralized version of the table classic structure that allows to combining between the
hash value and data structure. This combinition is shared between all the actived elements in
distributed system.
Among them we find mainly in this memory: Chord, Pastry Tapestry, CAN,
Kademlia, Viceroy, and Ulysses .
Most previous studies evaluate the performance of different DHTs individually while
few others focus on the comparison between the protocols with a limited number of
parameters.
To know what is the most efficient and optimal protocol in terms of performance, we
will make a comprehensive comparative study, particularly chord, Kademlia and pastry where
the last one has never been included in this kind of study.
The scenarios of the simulation will be built with the OverSim simulator.
Key words : Peer to peer (P2P), routing protocol, DHT, Chord, Kademlia and Pastry.

Résumé
Le réseau P2P est un réseau logique au-dessus d'un réseau IP existant (overlay), tel
qu’Internet. Les systèmes P2P permettent la décentralisation, le partage de l'ensemble des
ressources du réseau P2P, la communication et collaboration des nœuds de manière directe.
Nous distinguons trois familles d’architectures P2P : L’architecture centralisée,
L’architecture décentralisée qui peut être structurée ou non structurée et L’architecture
hybride.
Pour les architectures décentralisées structurées, Il existe de nombreuses
implémentations, les algorithmes d’insertion et de recherche étant différents pour chacun.
Ces algorithmes basés sur Une table de hachage distribué dit DHT représente la
version décentralisée de la structure classique d’un tableau qui permet l’association d’une
valeur de hachage à une structure de données, qui est partagée entre tous les éléments actifs
d’un système réparti.
Les protocoles de routage dans les réseaux P2P utilisant des DHTs sont dits DHTs
tout simplement. Parmi eux nous en trouvons principalement dans ce mémoire : Chord
,Tapestry Pastry, CAN, Kademlia, Viceroy et ulysses.
La plupart des travaux antérieurs évaluent la performance de diférents DHTs
individuellement alors que peu d’autres concentrent sur la comparaison entre les protocoles
avec un nombre limité des paramètres.
Pour connaitre quelle est le protocole le plus efficace (optimal) en termes de
performance, nous allons mener une étude comparative exhaustive, particulièrement pour les
protocoles : Chord, Kademlia et Pastry qui n’a jamais fait l’objet d’étude de ce genre.
Les scénarios de la simulation ont été construits avec le simulateur OverSim .
Mots clé : paire à pair (P2P), protocoles de routage, DHT, Chord, Kademlia, Pastry.

Les mots les plus simples étant les plus forts
A La source de grande affection et le goût de la vie ma mère
A mon âme et la joie de ma vie ma chère femme
A mes yeux et ma bonheur, mes deux enfants « Achref et Yasser »
A mon aide et soutien dans la vie, mes chères sœurs et mes chers frères.
A l’âme de mon cher défunt père « Cherif » , avec la plus grande douleur
de ne plus l'avoir parmi nous, pour l'amour et le soutien incomparable dont il m'a fait
preuve depuis ma naissance.
Je dédié ce modeste travail
Brakni Tahar
A tous ceux et celles qui de près ou de loin nous ont apporté l'aide et
l'encouragement,
Je dédié ce modeste travail
Bentahar Atef
Dédicace

Remerciements
Tout d’abord, nous tenons à remercier Allah, le clément et le
miséricordieux de nous avoir donné la force et le courage de mener à bien
ce travail.
Nous voudrions exprimer nos vifs remerciements à notre encadreur
Monsieur « Abdelghafour Azzedine » pour avoir accepté de nos diriger
patiemment, de son soutien constant, de sa grande disponibilité et son suivi
sérieux pendant toute la période d’élaboration de ce travail.
Nos remerciements aux membres du jury qui ont accepté d'évaluer
notre travail.
Nous souhaitons exprimer nos gratitudes Pour ses aides et leurs
conseils envers :
Mr « Mahmoudi Rachid » (Université de Tébessa)
Mr « nezzar rafik » (Université de batna)
Nous voudrions aussi remercier tous les professeurs qui ont contribué
à notre formation (Master Informatique : réseaux et sécurité).
Nous remercions très vivement tous les membres du département des
mathématiques et Informatique à l’université de Tébessa (les enseignants,
les étudiants et les employés)
Nos remerciements vont également à tous ceux et celles qui de près
ou de loin nous ont apporté l'aide et l’encouragement.

I
Table des matières
‫ملخص‬
Abstract
Résumé
Dédicace
Remerciements
Table des matières
Liste des tableaux
Liste des figures
Liste des abréviations
Introduction Générale 1
Chapitre 1 : Les réseaux Pair-à-Pair
I. Introduction 4
II. Définition 4
III. Domaines d’application des systèmes pair-à-pair 5
1. Les plates-formes de développement 6
2. Le partage et la distribution de contenu 6
3. La collaboration 7
4. Le calcul distribué 7
IV. Les modèles d’architecture des réseaux Pair-à-Pair 8
1. L’architecture centralisée 9
2. L’architecture décentralisée 10
2.1. Architecture décentralisée non structurée 10
2.2. Architecture décentralisée structurée 11
3. Architecture hybride 11
V. Caractéristiques des réseaux pair-a-pair 12
1. Décentralisation 13
1.1. L’équilibre de la charge et du trafic 13
1.2. Le passage à l’échelle 14
1.3. La répartition des coûts 14
1.4. La tolérance aux fautes 14
2. Auto-organisation 14
2.1. Aspect fonctionnel 15
2.2. Aspect communautaire 15
2.3. Aspect topologique 15
3. Connectivité Ad Hoc 16
4. Un réseau virtuel 17
5. Anonymat 17
VI. Avantages et limites des réseaux pair-à-pair 18
1. Avantages 18
2. Limites 19
VII. Conclusion 20
Chapitre 2 : Les protocoles de routage dans un réseau Pair à Pair décentralisé
I. Introduction 22
II. Les Tables de hachage distribuées (DHTs) 22

II
1. Définitions 22
1.1. La fonction de hachage 22
1.2. La table de hachage 23
1.3. La table de hachage distribuée 23
2. Le principe des tables de hachage distribuées 23
3. Bilan De DHTs 24
III. Architectures et protocoles pair-à-pair décentralisés et structurés 24
1. Architecture en anneau : 24
1.1. La table de hachage distribuée Chord 24
1.1.1. Définition 24
1.1.2. Routage dans Chord 25
1.1.2.1. Routage simplifié 25
1.1.2.2. Le routage optimal 26
1.1.3. L’arrivée et le départ d’un nœud 27
1.1.4. Applications Basées Sur Chord 27
2. Architecture Maillée De Plaxton 28
2.1. La table de hachage distribuée Tapestry 28
2.1.2. Routage dans Tapestry 29
2.1.3. Applications basées sur Tapestry 29
2.2. La table de hachage distribuée Pastry 29
2.2.2. Le routage dans Pastry 30
2.2.3. L’Arrivée et le départ d’un nœud 31
2.2.4. Applications basées sur Pastry 32
3. Architecture Torique 32
3.1. La table de hachage distribuée CAN 32
3.1.2. Arrivée d’un nœud 33
3.1.3. Départ d’un nœud 33
3.1.4. Le routage 34
4. Architecture en arborescence 34
4.1. La table de hachage distribuée Kademlia 35
4.1.2. Description 35
4.1.3. Localisation d’un nœud dans le réseau 35
4.1.4. Distance entre deux nœuds : métrique XOR 37
4.1.5. L’arrivée et le départ d’un nœud 37
4.1.6. Applications basées sur Kademlia 37
5. Architecture en papillon 37
5.1. La table de hachage distribuée Viceroy 37
5.2. La table de hachage distribuée Ulysses 38
IV. Comparaison Et Analyse 38
V. Conclusion 39
Chapitre 3 : Influence des paramètres DHT sur la performance des protocoles

III
I. Introduction 41
II. Etat de l’art 41
1. Évaluation de Chord 41
1.1. Le type de Protocole implémenté 41
1.2. L’équilibrage de la charge 41
1.3. Longueur du chemin 42
1.4. Échec des nœuds simultanément 42
1.5. La recherche des ressources au cours de stabilisation 42
1.6. L’expérience pratique sur l’Internet 43
2. Évaluation de Kademlia 43
2.1. Les effets de paramètres DHT 43
2.1.1. Méthodologie expérimentale 43
2.1.2. Résultats de l’expérience 44
2.1.2.1. Effets de nexchange sur le taux de réussite 45
2.1.2.2. Effets de kvalue sur le taux de réussite 45
2.1.2.3. Les effets de la recherche en parallèle sur taux de réussite 45
2.1.2.4. Les effets de la réplication sur taux de réussite 45
2.1.2.5. Les effets de nparallel et nreplication sur taux de réussit 45
2.2. La performance de kademlia en termes de trafic 46
2.2.1. L'effet de la recherche parallèle 46
2.2.2. L'effet de l’intervalle de stabilisation 46
3. Évaluation de Pastry 46
III. Travaux connexes 47
IV. Conclusion 47
Chapitre 4 : Comparaison des performances des DHTs
I. Introduction 49
II. Les simulateurs pair-à-pair existants 49
III. Le simulateur OverSim 50
1. L’outil de simulation OMNET++ 50
1.1. Présentation 50
1.2. L’architecture de OMNet++ 50
2. INET 51
3. Le simulateur OverSim 52
3.1. Description 52
3.2. Caractéristiques principales 52
3.3. Architecture d’OverSim 53
4. Critères de choix 54
IV. Environnement de Simulation 54
1. Environnement matériel 54
2. Environnement logiciel 54
V. Définition des paramètres 55
1. Paramètres du fichier default.ini 55
2. Création des Fichiers de configuration 56
3. Les paramètres de la simulation 57
3.1. Le choix de paramètres et de DHTs 57
3.2. Les paramètres d’entrée 58

IV
3.2.1. Le temps de la Simulation 58
3.2.2. Le nombre de nœuds 58
3.2.3. Le temps de rejoint/quitte le réseau overlay 58
3.3. Les paramètres de sortie 58
VI. Les scénarios de la simulation 59
1. Premier scénario 59
2. Deuxième scénario 59
3. Collection des statistiques 59
VII. Résultats et discussion 60
1. Longueur du chemin 60
1.1. En fonction de nombre de nœuds et en fonction de temps
rejoint/quitte
60
1.2. La probabilité de nombre de sauts 61
2. Taux du succès 63
3. Temps de latence de la recherche 64
4. Le nombre moyen de Requêtes échouées 65
5. Le Trafic (bytes/s) 66
6. Nombre d’entrées stockées dans le DHT 67
VIII.Conclusion 68
Conclusion Générale 69
Bibliographie 70
Annexes

V
Liste des tableaux
PageTitreTableau N°
13Comparaison des infrastructures client-serveur et P2PTableau 1.1
39
Comparaison le degré et le diamètre de quelques
protocoles de routage P2P utilisant des DHTs
Tableau 2.1
44Notations et leur significationTableau 3.1
49-50Quelques simulateurs des réseaux pair-à-pairTableau 4.1
54Configuration de l'ordinateur de développementTableau 4.2
54L’environnement logiciel de simulationTableau 4.3
55Quelques Paramètres de default.iniTableau 4.4
56Description de paramétrés OverSimTableau 4.5
58Description de paramétrés de sortieTableau 4.6
59Première ScenarioTableau 4.7
59Deuxième ScenarioTableau 4.8
62
La probabilité de la longueur du chemin dans le cas
d'un réseau overlay avec 600 nœuds
Tableau 4.9

VI
Liste des figures
Figure N° Titre Page
Figure 1.1 Classification des domaines d’applications P2P 6
Figure 1.2 Les modèles d’architecture P2P. 8
Figure 1.3 Architecture P2P Centralisée 9
Figure 1.4 Architecture P2P décentralisée 10
Figure 1.5 Architecture P2P Hybride 12
Figure 1.6 Topologies Gnutella. (a) Topologie non-structurée.
(b) Topologie s’approchant du modèle Small World
16
Figure 2.1 DHT et mécanisme de routage overlay 23
Figure 2.2 Topologie de Chord (le réseau virtuel au-dessus du réseau
physique)
25
Figure 2.3 Routage simple 25
Figure 2.4 Routage optimale 26
Figure 2.5 exemple de retrouver très rapidement un utilisateur dans Chord 27
Figure 2.6 Exemple de suffixe routing 28
Figure 2.7 Exemple des niveaux hiérarchiques dans Tapestry (map of node
5642)
29
Figure 2.8 Le routage d’un message de proche en proche dans Pastry 30
Figure 2.9 Exemple d’une table de routage d’un nœud Pastry 31
Figure 2.10 Exemple de routage dans Pastry 31
Figure 2.11 Espace de coordonnées cartésiennes de dimensions 2 partagé
entre 6 nœuds CAN
32
Figure 2.12 Espace de coordonnées cartésiennes avant que le nœud F arrive 33
Figure 2.13 Espace de coordonnées cartésiennes avant que le nœud D quitte 34
Figure 2.14 Exemple de routage dans CAN 34
Figure 2.15 Localiser un nœud par son ID 36
Figure 2.16 Arbre binaire de Kademlia 36
Figure 2.17 Illustration simplifiée de l'architecture de Viceroy 38
Figure 4.1 Exécution d’une simulation sous OMNeT++ 51
Figure 4.2 Architecture d’OverSim détaillé 53
Figure 4.3 Un échantillon de réglage de fichier de configuration pour une
exécution
57
Figure 4.4 Présentation graphique d’un exemple de statistique de nombre
de sauts d’après le fichier scalars (.sca)
60
Figure 4.5 La longueur de chemin en fonction de la taille du réseau 60

VII
Figure 4.6 La longueur de chemin en fonction du temps rejoint/quitte du
nœud
61
Figure 4.7 La longueur de chemin dans un réseau overlay avec 600 nœud
en fonction du temps (de la seconde 720 jusqu’à 740)
61
Figure 4.8 La probabilité de la longueur du chemin dans le cas d'un réseau
overlay avec 600 nœuds
62
Figure 4.9 Le taux du succès en fonction de la taille du réseau 63
Figure 4.10 Le taux du succès en fonction du temps rejoint/quitte du nœud 63
Figure 4.11 Le temps moyen de Latence de recherche (seconde) en fonction
de la taille du réseau
64
Figure 4.12 Le temps moyen de Latence de recherche (seconde) en fonction
du temps rejoint/quitte du nœud
64
Figure 4.13 Le nombre moyen de Requêtes échouées par seconde en
fonction de la taille du réseau
65
Figure 4.14 Le nombre moyen de Requêtes échouées par seconde en
fonction du temps rejoint/quitte du nœud
65
Figure 4.15 Le nombre moyen d’octets par seconde en fonction de la taille
du réseau
66
Figure 4.16 Le nombre moyen d’octets par seconde en fonction du temps
rejoint/quitte du nœud
66
Figure 4.17 Le nombre moyen d’entrés stockées dans le DHT en fonction de
la taille du réseau
67
Figure 4.18 Le nombre moyen d’entrés stockées dans le DHT en fonction du
temps rejoint/quitte du nœud
67

VIII
Liste des abréviations
P2P: Peer To Peer
DNS: Domain Name Service
CFS: Cooperative File System
NNTP: Network News Transfer Protocol
DHT: Distributed Hash Table
CAN: Content Adressable Network
NS : Network Simulator
P2PSIM : Peer To Peer Simulator
PEERSIM : Peer Simulator
OMNET++ : Objective Modular Network Tested in C++
INET : Internet Network
OVERSIM : overlay Simulator
GNU : General Public License
GUI: Graphical user interface
NED : Network Description
IP : Internet Protocol
IPv4 : Internet Protocol version 4
IPv6 : Internet Protocol version 6
TCP: Transmission Control Protocol
UDP: User Datagram Protocol
RIP: Routing Information Protocol
OSPF: Open Shortest Path First
PPP : Protocol Point To Point
KIT : Karlsruhe Institute of Technology
RPC: Remote Procedure Call
API : Application Programming Interface
KBR: Key Based Routing

Introduction générale
1
Introduction Générale
L’architecture pair-a-pair (en anglais Peer to Peer) a été popularisée par le système de
partage de fichiers Napster [53], initialement publié en 1999. Il s’agissait d’un service qui
permettait aux utilisateurs « de partager » des fichiers de musique. Le modèle pair à pair a
attiré l'attention des acteurs de la communauté des réseaux et des applications distribuées. Les
scientifiques et les industriels voient ce modèle comme une véritable alternative au modèle
client-serveur qui devient non satisfaisant aux besoins des applications informatiques en
réseaux.
L’idée à l’origine de ce système était le stockage décentralisé des fichiers au niveau
des points terminaux (plutôt qu’au niveau des serveurs). Cette idée ; pourtant simple et à la
base du concept de l’Internet ; a rencontré un succès énorme.
Cette nouvelle génération de systèmes de partage de fichiers a complètement été
décentralisée en termes à la fois de stockage et de récupération des ressources.
L’évolution des réseaux pair-à-pair présente des nombreux avantages qui repoussent
les limites induites par le modèle client-serveur :
 l’absence d’élément central permet d’augmenter considérablement la tolérance aux
fautes des services car, si la disparition d’un serveur engendre l’indisponibilité du service
oﬀert, la disparation d’un pair est sans conséquence.
 la répartition équitable des données et des tâches à exécuter permet d’équilibrer le
traﬁc du réseau sous-jacent ainsi que la charge attribuée à chaque participant.
 l’agrégation potentielle des puissances de calcul et espaces de stockage de millions de
machines offre aux usagers une puissance qui dépasse celle de toutes les infrastructures
centralisées existantes.
 l’utilisation de machines appartenant aux différents propriétaires permet de réduire les
coûts liés à l’achat et la maintenance d’équipements.
Tous ces facteurs rendent possible et favorisent alors l’utilisation des applications
décentralisées. De manière générale, ce sont toutes les technologies connues sous le nom de
P2P, qui se trouvent ainsi favorisées.
Un réseau P2P est un réseau logique (overlay network [29]) au-dessus d'un réseau IP
existant, chaque réseau P2P logique (structuré ou non structuré) emploie sa propre topologie
et son protocole de routage pour permettre à chaque nœud d’avoir des informations
concernant les autres nœuds du réseau, afin de créer et de maintenir sa table de routage, ces
informations sont utilisé pour soumettre des requêtes et recherche des données à travers le
réseau P2P.

Introduction générale
2
Les réseaux P2P attirent l'attention des acteurs de la communauté des réseaux et des
applications distribuées pour l’utilisés avec succès dans plusieurs domaines comme :
 Le partage de fichiers (Gnutella [55], eMule[3], KaZaA[4], BiTtorren[5] )
 Le partage de capacité de calcul (SETI@home [9])
 La messagerie instantanée, la voix et la vidéo (ICQ[6], Skype [7], PPLive [8] )
Les réseaux P2P structurés donnent plusieurs types de réseaux chacun avec sa propre
topologie de routage qui va changer les performances des systèmes P2P, cela nous pousse à
poser la question : quelle est le protocole le plus efficace et optimal en terme de
performance ?
L’objectif de ce mémoire est de faire une étude comparative exhaustive, particulièrement sur
les protocoles (Chord [38], kademlia [41] et Pastry [39] qui n’a jamais fait l’objet d’étude de
ce genre, ainsi que la plupart des travaux antérieurs évaluent la performance de différents
DHTs individuellement alors que peu d’autres se concentrent sur la comparaison entre les
protocoles avec un nombre limité des paramètres. Pour cela nous allons choisir de faire cette
étude avec nombreux paramètres intéressants.
Ce travail est organisé en quatre chapitres comme suit :
Le premier chapitre « Les réseaux pair-à-pair » : donne une vue globale sur les réseaux
Pair-à-Pair, et les différents concepts.
Le deuxième chapitre « Les protocoles de routage dans un réseau P2P décentralisé » :
ce chapitre détaille les Tables de hachage distribués DHT (Distributed Hash Table) comme
mécanisme de routage au sein d’un réseau P2P décentralisé et les différentes topologies et
protocoles utilisés pour implémenter les DHT.
Le troisième chapitre « Influence des paramètres DHT sur la performance des
protocoles »: ce chapitre on va présenter la majorité des paramètres DHT qui influent sur la
performance des protocoles de routage P2P. on va se concentrer sur les DHTs : Chord ,
Kademlia et Pastry .
Le dernier chapitre « Comparaison des performances des DHTs » : ce chapitre est
réservé à la simulation et l’analyse des performances des trois protocoles de routage (Chord ,
Kademlia et Pastry) , et la comparaison entre eux. On va présenter l’environnement de
simulation (logiciels, matériels), les paramètres de simulation, les fichiers de configuration,
l’analyse et la discussion de résultats.
Enfin, une conclusion va résumer l’essentiel de notre travail et présentation de
quelques perspectives et questions de recherche ouvertes dans ce cadre.

Les Réseaux Pair-A-Pair
Chapitre 1:

Chapitre 1 Les Réseaux Pair-A-Pair
4
I. Introduction
Les réseaux Pair-à-Pair sont en plein essor depuis plusieurs années. Ce paradigme
permet de concevoir des systèmes de très grande taille à forte disponibilité, tout cela à faible
coût.
La technologie des réseaux pair-à-pair peut être utilisée à de nombreuses fins telles
que le travail collaboratif, les réseaux de proximité ou de secours etc. Mais son succès auprès
du grand public est dû à la liberté d'échanger des fichiers musicaux, audiovisuels ou des
logiciels en dehors des circuits de distribution traditionnels.
Les premières applications des systèmes Pair-à-Pair étaient exclusivement liées à
l’échange et le partage de fichiers « file sharing », Plusieurs logiciels de partage de fichiers se
sont succédés, nous citons Gnutella[55], eMule[3], KaZaA[4], BiTtorren [5].
Aujourd’hui il y a des nouveaux applications pour les systèmes Pair-à-Pair qui sont les
résultats des nombreux projets de recherche qui s’intéressent pour des applications
collaboratives dont le stockage, la distribution de contenu, la communication, ou encore le
calcul distribué.
Les applications Pair-à-Pair collaboratives proposent à des communautés d’usagers
des services de communication et d’échange de données. Différents moyens de
communications sont souvent offerts, notamment avec la messagerie instantanée, la voix et la
vidéo (ICQ [6], Skype [7], PPLive[8] ). Le calcul distribué permet la distribution par un
serveur central, d’un calcul sur un ensemble de participants, Un des projets les plus célèbres
est SETI@home[9].
Toutefois, le partage et la distribution de contenu reste aujourd’hui l’utilisation
principale des systèmes Pair-à-Pair.
Ces réseaux étaient définis par plusieurs caractéristiques et diverses architectures que
nous soumettrons dans ce chapitre.
II. Définition
En cours de la recherche bibliographique de ce mémoire, nous avons trouvées
plusieurs définitions au réseau P2P qui sont proposées par différents acteurs de la
communauté P2P, nous citons trois parmi eux :
Définition 1 : « Peer-to-peer is a class of applications that take advantage of
resources (storage, cycles,content, human presence) available at the edges of the Internet.
Because accessing these decentralized resources means operating in an environment of
unstable connectivity and unpredictable IP addresses, peer-to-peer nodes must operate
outside the DNS and have significant or total autonomy of central servers » [10] .
Définition 2 : « A distributed network architecture may be called a Peer-to-Peer
network, if the participants share a part of their own hardware resources (processing power,
storage capacity, network link capacity, printers, . . .). These shared resources are necessery
to provide the Service and content offered by the network. They are accessible by other peers
directly, without passing intermediary entities. The participants of such a network are thus
resource providers as well as resource requestors » [11].

5
Définition 3 : « Peer-to-peer systems are distributed systems consisting of
interconnected nodes able to self-organize into network topologies with the purpose of
sharing resources such as content, CPU cycles, storage and bandwidth, capable of adapting
to failures and accommodating transient populations of nodes while maintaining acceptable
connectivity and performance, without requiring the intermediation or support of a global
centralized server or authority » [12].
Ces définitions différentes introduisent plusieurs concepts généraux qui sont :
 Le partage des ressources (définitions 1, 2 et 3).
 Le caractère dynamique des participants (définitions 1 et 3)
 La capacité à s’auto-organiser (définitions 1 et 3).
 L’absence d’élément central (définitions 1, 2 et 3).
De notre côté, la définition du modèle P2P que nous adoptons fait l’abstraction de ces
concepts:
« Le Système P2P est une architecture d'applications distribuées qui partitionne les
tâches ou les charges de travail entre les nœuds. Ces derniers sont équi-privilégiés et
participent de façon équivalente dans l'application. »
Ces nœuds interconnectés et auto-organisés capables de distribuer les ressources en
topologies de réseau dans le but de les adapter à des défaillances et accueillir d'autres nœuds.
Les pairs font partie de leurs ressources, telles que la puissance de traitement, le
stockage sur disque ou la bande passante du réseau, ces ressources sont directement
accessibles aux autres participants du réseau sans la nécessité d'une coordination centrale par
les serveurs ou hôtes stables.
L’accès à ces ressources décentralisées signifie le fonctionnement dans un
environnement de connectivité instable dans lequel les adresses IP sont imprévisibles, les
nœuds ont une autonomie importante par rapport à l’architecture client-serveur.
Les pairs sont des fournisseurs et des consommateurs de ressources, contrairement au
modèle client-serveur classique dans lequel la consommation et la fourniture sont séparées.
Ces systèmes P2P révèlent la collaboration de telle façon que tous les participants
partagent les ressources, et recherchent divers pairs qui peuvent apporter d'autres ressources
.ainsi un tel système livre des plus grandes tâches relativement à ceux qui peuvent être
accomplies par les pairs individuels qui sont bénéfiques pour tous les pairs.
III. Domaines d’application des systèmes pair-à-pair
Actuellement, on distingue quatre grands domaines d’applications couverts par le
modèle P2P. Nous les avons représentés sur la figure 1.1 qui les classifie. Il s’agit des :
 Plateformes de développement (JXTA [14], .net My Services [15])
 Partage et distribution de contenu (Napster, Gnutella, Freenet [16] Publius [33], Free
Haven[32])
 Collaboration et communication ( Groove[17], Jabber[18]).
 Calcul distribué (seti@home)

6
Figure 1.1 : Classification des domaines d’applications P2P
Dans ce qui suit, nous présentons chacun d’eux :
1. Les plates-formes de développement
Les applications de partage de fichiers qui ont popularisé le modèle P2P ont aussi mis
en évidence un besoin fort d’interopérabilité pour ce type d’application. C’est pourquoi,
plusieurs propositions de plates-formes génériques de développement qui permettent cette
interopérabilité ont vu le jour. Celles-ci permettent aux développeurs d’applications de
s’abstraire des mécanismes de bas niveau du modèle P2P et de proposer des applications
toutes construites sur les mêmes fondements.
Jxta, est l’une des premières propositions de plate-forme générique et est actuellement
une des plus complètes et déployées. Microsoft, de son côté propose deux infrastructures pour
le développement des applications P2P. Le premier est une extension de la plate-forme de
développement de services web .NET qui présente une manière d’intégrer des services P2P a
cette infrastructure. Cette proposition s’apparente plus à l’adaptation d’une plate-forme
initialement dédiée à un fonctionnement centralisé plutôt qu’a une véritable proposition de
plate-forme qui intègre les mécanismes de base du modèle P2P. La seconde proposition
s’appelle Windows P2P [19] et propose un ensemble de mécanismes utilisables par les
concepteurs d’applications Windows pour développer des services P2P.
2. Le partage et la distribution de contenu
Le modèle P2P connaıt son succès actuel grâce aux applications de partage de fichiers.
Initié par Napster , ce type d’application consiste à créer des communautés de pairs qui
partagent des fichiers qui sont stockés sur leur machine. Les protocoles et implantations
d’applications de partage de fichiers sont nombreux. Parmi les plus connues, on trouve
Gnutella, , Kazaa, Emule, Bit-Torrent . Souvent aucune interopérabilité n’existe entre celles-
ci. Pour pallier ce problème, on trouve maintenant des applications qui implantent plusieurs
protocoles et permettent aux usagers de se connecter à plusieurs communautés, augmentant
ainsi le volume de données accessibles.

7
Un des principaux problèmes mis en évidence par les applications de partage de
fichiers concerne le free riding [20], un comportement qui consiste à télécharger des données
sans en partager aucune. Pour le résoudre, les applications de partage de fichiers les plus
récentes mettent en place des mécanismes apparentés à l’autogestion. Les principaux reposent
sur un classement régulier des pairs qui dépend de leur comportement : les pairs les plus
stables, fiables et généreux vont ainsi voir leurs recherches de données être traitées plus
efficacement et pouvoir télécharger plus de données, plus rapidement.
Le second type d’application relatif aux fichiers et à leur accès par le biais du modèle
P2P concerne le stockage de fichiers. On trouve plusieurs applications telles que CFS [21],
PAST [22] ou OceanStore [23] qui sont toutes construites sur des tables de hachage
distribuées et qui proposent de construire un système de fichiers de type Unix qui soit
distribué parmi une communauté de pairs. L’objectif est de fournir un service similaire à NFS
(Network File System) qui ne nécessite aucune architecture centralisée.
3. La collaboration
Les applications P2P collaboratives proposent à des communautés d’usagers des
services de communication et d’échange de données. Différents moyens de communiquer sont
souvent offerts, avec notamment le chat, la messagerie instantanée, la voix et la vidéo par le
biais de la visioconférence ou des webcams. L’échange de données, selon le contexte
d’utilisation, va des photos ou vidéos personnelles aux documents d’un projet de travail. Deux
types d’usagers sont visés par ce type d’application qui sont le particulier et les entreprises.
On trouve aujourd’hui une multitude d’applications qui ciblent ces deux catégories,
avec par exemple Jabber , ICQ ou Skype pour la communication et Groove pour le travail
collaboratif.
4. Le calcul distribué
La possibilité de pouvoir utiliser la puissance de calcul de millions de machines
connectées à l’Internet intéresse fortement les acteurs de la communauté du calcul distribué.
En 1999, l’université de Berkeley lance le projet Seti@Home qui a pour objectif d’analyser
des données transmises par des récepteurs du projet SETI qui écoutent l’univers afin de
détecter une quelconque forme de communication. Etant donné un grand nombre de données
à analyser, l’équipe propose de développer une application assimilable à un économiseur
d’écran qui, lorsque l’ordinateur sur lequel elle est hébergée est inefficace, télécharge un
morceau de données sur un serveur dédié, les analyse et lui retourne le résultat. Cette
application connait un très grand succès et est actuellement utilisé par des milliers
d’utilisateurs, motivés par des classements réguliers de participations et par la possibilité
d’être celui qui aura traité le bloc qui contient un extrait de communication extra-terrestre. En
outre, des clones sont aujourd’hui utilisés dans de nombreux autres domaines. On considère
ainsi Seti@Home comme le précurseur d’une problématique de recherche à part entière qui
concerne la manière de distribuer un calcul sur une infrastructure P2P.

8
IV. Les modèles d’architecture des réseaux Pair-à-Pair
Plusieurs modèles d’architecture P2P existent. D’ordinaire, c’est le degré de
décentralisation qui est retenu pour leur classification, puisque c’est là l’idée de base du P2P.
Ce degré de décentralisation de l’architecture caractérise aussi l’index de référence des
ressources.
La première génération des applications P2P était à architecture centralisée. Une
deuxième génération à architecture décentralisée non structurée a vite vu le jour, suivie par
une troisième génération d’applications à architecture hybride.
Au niveau de l’infrastructure P2P, des protocoles et des architectures décentralisées
structurées se sont développées en parallèle aux applications P2P, à partir de la deuxième
génération.
Nous distinguons donc trois familles d’architectures P2P (figure 1.2) :
 L’architecture centralisée.
 L’architecture décentralisée, qui peut être structurée ou non structurée.
 L’architecture hybride.
Figure 1.2 : Les modèles d’architecture P2P.

9
1. L’architecture centralisée
L’architecture centralisée est caractérisée par un index central pour repérer les
ressources. Cet index reçoit tous les messages de contrôle et toutes les requêtes, mais par la
suite, l’échange se fait directement entre les pairs concernés. C’est ce qui distingue
principalement cette architecture d’une architecture traditionnelle de type client-serveur.
Figure 1.3 : Architecture P2P Centralisée
Ce serveur centralisé ne dispose pas des fichiers. Il contient principalement deux
types d’informations : celles sur le fichier (nom, taille, ...), et celles sur l'utilisateur (nom
utilisé, IP, nombre de fichiers, type de connexion, ...).
Comme toute architecture centralisée, cette architecture facilite la gestion des
différentes ressources de l’index et offre une bonne performance de découverte des ressources
(le coût de localisation des ressources est faible), ainsi que Le confort d'utilisation peut être
amélioré, puisqu'il n'y a pas de soucis de connexion au bon serveur. Cependant la
centralisation représente un goulot d’étranglement au niveau de l’index, tant par la charge de
son utilisation que de sa mise à jour. De plus, au niveau de la sécurité, l’index est le talon
d’Achille de ce type d’architecture et aussi aucun anonymat n'est possible, puisque chaque
utilisateur est identifié sur le serveur. Alors ce type est sensible au partitionnement du réseau
et aux attaques.
L’exemple type d’une telle architecture est Napster (1999-2002) qui a déclenché le
phénomène P2P. Il a aussi été le modèle le plus spectaculaire de la réussite technologique du
P2P.

10
2. L’architecture décentralisée
Dans l’architecture P2P décentralisée, tous les pairs sont fonctionnellement
parfaitement équivalents. C’est un modèle P2P pur (Figure 1.4) Cette architecture est
caractérisée par une décentralisation de l’index, qui devient local à chaque pair, faisant effet
de table de routage. La décentralisation rend le système autonome et répartit la charge
équitablement. L’architecture décentralisée est donc plus robuste que l’architecture
centralisée, mais le temps de découverte des ressources est évidemment plus long.
Figure 1.4 : Architecture P2P décentralisée
On distingue dans ce type d’architecture deux sous catégories :
 L’architecture décentralisée non structurée
 L’architecture décentralisée structurée.
2.1. Architecture décentralisée non structurée
Une architecture P2P décentralisée [1] est dite non structurée lorsqu’aucune contrainte
topologique n’existe.
Un système P2P à architecture décentralisée est aussi dit : système P2P pur. Aucune
connaissance de la topologie n’est donc disponible au préalable et chaque pair dans le réseau
est autonome. La maintenance et la mise à jour des connexions se font par sondage périodique
du voisinage, et la découverte des ressources se fait par une technique d’inondation associant
un champ TTL (Time To Live) à chaque message de recherche envoyé, afin de comptabiliser
le nombre de retransmissions restantes.
L’architecture décentralisée et non structurée permet de pallier les points faibles de la
centralisation. Elle est simple et flexible, et ne requiert pas des requêtes exactes ou des
demandes de recherches très précises. Néanmoins, cette architecture ne peut pas être gérée
(par un opérateur de réseau ou fournisseur de services). Elle présente aussi certains
inconvénients résultant de l’utilisation de la technique d’inondation et du TTL :

11
 La génération d’un nombre important de messages, dont découlent :
o une consommation importante de la bande passante et donc une consommation
des ressources du réseau.
o la visite des pairs par des messages (requêtes ou réponses) non sollicités.
 l’absence de garantie de résultat et de connectivité.
 un passage à l’échelle assez limité.
L’exemple type d’une architecture P2P décentralisée non structurée est Gnutella dans
sa version initiale, Le TTL y était typiquement fixé à 7. De ce fait, une mise hors réseau
(panne ou déconnexion) d’un nombre aléatoire de pairs scinderait le réseau en deux.
Gnutella est le premier réseau pur pair-à-pair, il succède Napster et son architecture
centralisée jugée vulnérable. Gnutella est un protocole ouvert décentralisé pour des recherches
distribuées sur un ensemble de pairs non hiérarchisés. Tous les utilisateurs sont des «
servent » c'est-à-dire qu’ils jouent le rôle de clients et de serveurs en même temps. A
n’importe quel moment les pairs peuvent se connecter et intégrer le réseau selon certaines
règles, ils n’ont aucune connaissance de la topologie ou de la localisation des données, c’est
pour cette raison qu’un index est créé en local au fur et à mesure. Lorsqu’un pair effectue une
requête, elle est propagée à ses voisins qui la propagent à leur tour aux leurs. Ce mécanisme
qui se base sur la technique de broadcast est appelée « flood », cette approche passe mal à
l’échelle (risque de saturation du réseau). Pour limiter cette surcharge, la requête se voit
attribuer une durée de vie déterminée TTL décrémentée à chaque passage par un pair [1].
2.2. Architecture décentralisée structurée
On parle de réseau décentralisé structuré lorsque la topologie du réseau est connue et
que l’emplacement des données est choisi dans le but d’optimiser les recherches. Les fichiers
sont donc stockés à des emplacements spécifiques. Les pairs sont reliés entre eux selon des
règles bien définies suivant un algorithme de recherche déterministe de telle sorte que pour
une source donnée, correspond un endroit fixé au préalable. L’emplacement est choisi de telle
sorte qu’il soit le plus simple d’accès aux pairs. Ceci permet à n’importe quel pair de se
joindre au réseau ou de le quitter (auto-organisé), Un autre avantage de cette architecture est
la garantie qu’elle offre sur les résultats des requêtes. Cette section sera détaillée dans le
chapitre suivant.
3. Architecture hybride
L’architecture hybride est une architecture décentralisée dont chaque nœud est
l’élément central d’une architecture centralisée. Ces éléments centraux sont des super-pairs
par rapport à l’architecture globale.
Pour une homogénéité entre les super-pairs, c’est souvent le critère de la bande
passante – identifiée suivant le type de connexion (e.g. par modem ou haut débit) qui est pris
en compte. Mais d’autres critères peuvent aussi entrer en jeu, comme la puissance de calcul,
l’espace de stockage, etc. Un nœud peut, avec le temps, à plusieurs reprises gagner et perdre
le statut de super-pair.

12
Figure 1.5 : Architecture P2P Hybride
L’architecture hybride tire avantage simultanément de l’architecture centralisée et de
l’architecture décentralisée. Le nombre de pairs mis en jeu dans la découverte des ressources
est aussi réduit, et avec lui, le trafic global entre les pairs. Ceci permet une économie de bande
passante et facilite le passage à l’échelle.
Un super-pair a cependant les mêmes faiblesses que l’index d’une architecture P2P
centralisée. Une amélioration possible est d’assurer une redondance en choisissant, pour un
même sous-groupe, un ou plusieurs partenaires au super-pair. L’architecture sera dite à super-
pairs redondants.
Des supers-pairs partenaires ont les mêmes connexions aux autres pairs et possèdent
des index identiques de toutes leurs ressources. Pour une répartition de charge équitable entre
les super-pairs partenaires, Chaque Super-Pair réfère une recherche aux autres Super-Pairs. La
recherche est donc plus rapide car elle ne se fait que dans les fichiers indexés par le Super-
Pair auquel on est connecté, les pairs d’un sous-groupe envoient leurs requêtes selon le
principe d’ordonnancement round Robin.
Voici quelques exemples d’applications basées sur un réseau P2P hybride : Gnutella (à
partir de la version 0.6) , FastTrack[24] , eDonkey/eMule , Skype .
Il est à noter que les architectures hybrides et les architectures centralisées sont parfois
regroupées au sein d’une même classe dite architecture à serveurs.
V. Caractéristiques des réseaux pair-a-pair
Le modèle P2P apporte une nouvelle manière de concevoir et mettre en œuvre les
applications réseaux. De par ses caractéristiques intrinsèques, il permet de résoudre certains
problèmes posés par le modèle client-serveur, comme par exemple, la limite du passage à
l’échelle ou le coût important pour l’achat et la maintenance des équipements. Toutefois, il en
induit d’autres, liés par exemple à la sécurité ou la pérennité des ressources.

13
Le tableau 1.1 met en évidence plusieurs différences fondamentales entre les modèles
client-serveur et P2P. D’une manière générale, on constate que le modèle client-serveur est
associé à un fonctionnement, un environnement et des ressources statiques et connues, alors
que le modèle P2P est lié au concept de dynamicité. Dans cette section, nous passons en revue
l’ensemble des caractéristiques que présente le modèle P2P ainsi que les différentes propriétés
qu’elles lui confèrent.
Critère Modèle Client-Serveur Modèle P2P
Gestion Supervisé Auto-organisé
Présence Permanente Ad Hoc
Accès aux ressources Recherche Découverte
Organisation Hiérarchique Distribuée, Equitable
Mobilité Statique Mobile
Disponibilité Dépendante du serveur Indépendante des pairs
Nommage Reposant sur le DNS Indépendant
Modèle de programmation RPC Asynchrone
Tableau 1.1- Extrait de [25]. Comparaison des infrastructures client-serveur et P2P
1. Décentralisation
La décentralisation est la caractéristique du modèle P2P. Elle s’applique à différentes
fonctions et aux trois sous-modèles. Dans le cas du modèle P2P centralisé, seules les
ressources sont décentralisées mais les mécanismes de recherche et de localisation restent
centralisés. Par contre, dans le cas du modèle pur, tout est décentralisé, des ressources aux
mécanismes de découverte, localisation, sécurité, routage, . . . Quelle que soit sa nature, cette
décentralisation confère au modèle P2P un ensemble de propriétés que nous détaillons
maintenant.
1.1. L’équilibre de la charge et du trafic
La première conséquence induite par la décentralisation sur les applications P2P,
concerne l’équilibre de la charge et du trafic. Dans le cas du modèle client-serveur, le serveur
de l’application concentre tout : les données, l’ensemble des mécanismes qui assurent l’accès
à celles-ci et leur manipulation, mais aussi le trafic généré sur le réseau qui héberge le
serveur. Au contraire, le modèle P2P permet de repartir et équilibrer au mieux la charge
induite par l’exécution du service ainsi que le trafic généré sur le réseau.
Pour une ressource particulière, le Pair qui l’héberge agit comme un serveur central.
Une bonne répartition des ressources, nécessitant éventuellement l’utilisation de mécanisme
de dissémination et de duplication, permet d’éviter que le système bascule dans un
fonctionnement client-serveur avec des pairs qui ne sont pas dédiés à cette fonction.

14
1.2. Le passage à l’échelle
Le bon équilibre de la charge et du trafic des services P2P se répercute directement sur
le passage à l’échelle des applications qui, comparativement au modèle client-serveur, s’en
trouve fortement amélioré. Par exemple, les applications P2P de partage de fichiers comptent
un très grand nombre de participants et fonctionnent sans aucun problème. D’après une étude
menée en 2001 [26], Gnutella compte en moyenne dix mille participants simultanés et
OceanStore , une application P2P de stockage de fichiers, permet de gérer 1010
utilisateurs
stockant au total plus de 1014
fichiers.
Le modèle P2P centralisé possède lui aussi un très bon passage à l’échelle car il ne
centralise pas les ressources mais un index de références. Ainsi la charge et le trafic qui lui
sont attribués sont acceptables et permettent un bon passage à l’échelle des applications qui
reposent sur ce modèle. Les deux exemples-phares qui ont révèle cette bonne propriété sont
Napster , qui permit à plusieurs dizaines de milliers d’usagers d’utiliser simultanément son
service, et Seti@Home , une application de calcul distribué qui compte plusieurs milliers
d’utilisateurs simultanés.
1.3. La répartition des coûts
Déployer une infrastructure centralisée de services en réseaux qui puisse prendre en
compte des milliers d’utilisateurs répartis sur tout l’Internet, a un coût qui peut être lourd pour
l’organisation qui la déploie. Ce coût se répartit sur l’ensemble du cycle de vie de
l’infrastructure et comprend la conception, l’achat d’équipements, la mise en œuvre, la
supervision, la maintenance, la formation des usagers, la mise à jour des composants logiciels,
. . . Le modèle P2P permet de réduire fortement ce coût par l’utilisation de machines situées
en bordure de l’Internet. Ces machines appartiennent toutes à des propriétaires différents qui
peuvent être par exemple des particuliers, des universités, des entreprises ou des
administrations et qui sont toutes achetées, mises en œuvre et maintenues par ces différentes
organisations. L’utilisation du modèle P2P permet donc à un fournisseur de service de réduire
fortement les coûts d’équipements et, au-delà de l’aspect financier, de concentrer son action
sur l’aspect logiciel de l’infrastructure qu’il propose.
1.4. La tolérance aux fautes
Dans l’architecture client-serveur la disponibilité d’un service repose intégralement
sur celle du serveur. Si celui-ci s’écroule, le service qu’il fournit devient indisponible. Dans
un contexte P2P, il n’existe potentiellement aucun point central de faute. Si un pair disparait,
le service continuera d’être fourni par ceux qui restent. En d’autres termes, la disponibilité
d’un service n’est plus liée aux pairs mais à la communauté de pairs qui le fournissent.
2. Auto-organisation
L’absence d’´élément central dans les applications P2P nécessite la mise en place de
mécanisme d’auto-organisation qui permettent à une communauté de d´délivrer son service
quels que soient les allers et venues des pairs et la disponibilité des ressources.

15
Cette auto-organisation couvre plusieurs aspects qui peuvent être fonctionnels,
communautaires et topologiques.
2.1. Aspect fonctionnel
Le modèle P2P hybride montre clairement que certains pairs peuvent se charger de
l’exécution de fonctions particulières, segmentant ainsi une communauté en pairs spécialisés.
Jxta est une bonne illustration d’organisation fonctionnelle avec l’utilisation de pairs
minimaux qui sont de simples consommateurs d’une communauté, de pairs simples qui n’ont
pas de rôle particulier, de pairs de rendez-vous qui assurent les fonctions de découverte et de
localisation, et de pairs relais qui s’occupent du routage. En outre, les applications P2P
possèdent souvent la capacité d’assigner ou de supprimer par elles-mêmes les fonctions
attribuées aux pairs pour garantir le bon fonctionnement de son service.
2.2. Aspect communautaire
Ensuite, les applications P2P sont capables de regrouper leurs pairs par centres
d’intérêts communs créant ainsi des communautés qui peuvent elles-mêmes contenir des sous-
communautés. On trouve ce type d’organisation dans les services de communication et
d’échange de données personnelles telles que Jabber qui regroupe les pairs en fonction des
sujets sur lesquels ils souhaitent échanger comme par exemple, le sport, le cinéma ou la
politique.
2.3. Aspect topologique
Le dernier aspect pour lequel les applications P2P proposent des mécanismes
d’organisation concerne la topologie. De manière générale, il existe deux grandes classes de
topologies P2P qui sont les topologies structurées et non structurées. Les topologies
structurées sont construites à l’aide d’un algorithme reposant souvent sur un modèle
mathématique ou un graphe particulier. Les topologies non structurées, quant à elles, ne
respectent aucune règle de construction particulière. Gnutella , dans sa première version 6,
reposait sur une topologie non structurée. On peut néanmoins remarquer que les topologies
non-structurées, du fait des différences de comportement des pairs, peuvent tendre au fil du
temps à s’organiser selon une topologie de type Small World [27], un modèle topologique
comportant quelques nœuds à fort degré de connexion et de nombreux autres à faible degré de
connexion et connectés à ces premiers . La figure 1.6 illustre ce propos avec deux
représentations de topologies Gnutella. La première (figure 1.6 a) montre une topologie non
structurée et la seconde (figure 1.6 b) en montre une autre qui tend à s’organiser selon le
modèle Small World.

16
Figure 1.6 : Topologies Gnutella. (a) Topologie non-structurée. (b) Topologie s’approchant
du modèle Small World. Extrait de [68]
3. Connectivité Ad Hoc
Le modèle P2P se caractérise par une connectivité intermittente des pairs qui le
composent. Cette nature Ad Hoc est principalement due à deux phénomènes. Le premier
concerne le comportement des usagers qui utilisent les services P2P. Les pairs sont en effet
exécutés dans un cadre de travail ou personnel sur des machines d’utilisateurs qui peuvent se
connecter et se déconnecter de manière spontanée et donc imprévisible.
Le second phénomène concerne la mobilité. Les ordinateurs portables munis
d’interfaces de communication sans fil sont de plus en plus courants. Les usagers disposant de
cette technologie ont souvent un comportement nomade, se trouvant certaines fois sur des
sites qui permettent de se connecter à l’Internet, et d’autres fois pas. En outre, la manière dont
ils atteignent une passerelle de connexion varie. Elle peut être directe ou n´nécessiter le
routage des données à travers différents terminaux mobiles qui forment un réseau Ad Hoc.
Cette présence dynamique des pairs se répercute directement sur la disponibilité des
ressources qui se trouve être variable. Pour garantir une bonne disponibilité des ressources
offertes à une communauté, les infrastructures P2P doivent ainsi mettre en place des
mécanismes de duplication et de synchronisation qui peuvent pallier ce problème. En outre,
l’absence d’une ressource ou d’un pair censé être présent ne doit pas être considérée comme
une faute. D’ailleurs, dans Tapestry [28], une infrastructure de routage et de localisation de
ressources, l’absence de réponse d’un pair inscrit dans une table de routage n’entraîne pas son
retrait de la table. L’infrastructure tente de contacter le pair plusieurs fois. Après plusieurs
tentatives, si aucune réponse n’est donnée, le Pair est supprimé de la table mais une référence
est tout de même conservée.

17
4. Un réseau virtuel
Les pairs participant à un service P2P forment souvent un réseau virtuel, appelé
overlay [29] construit au-dessus de la couche transport. Un exemple d’overlay est représenté
sur la figure 2.2 (Voir chapitre 2). Généralement, un tel réseau virtuel présente une propriété
de transparence qui s’applique à plusieurs points. Tout d’abord, il permet de faire abstraction
des différences de nature des pairs.
Une communauté peut être composée de pairs dont les caractéristiques différentes sur
les plans :
 matériel : avec par exemple des stations de travail, des téléphones mobiles, des
assistants personnels, ou un cluster de machines.
 logiciel : au niveau des systèmes d’exploitation et langages de programmation.
 communication : avec l’utilisation de technologies et de piles de protocoles
différentes.
La transparence s’applique aussi sur le routage effectué au niveau sous-jacent , deux
voisins de la topologie virtuelle ne le sont pas forcément physiquement ; ils peuvent être
situés dans des espaces physiques et sur des réseaux différents. L’overlay rend ainsi
transparent le routage effectué au niveau physique. Enfin, concernant les ressources, un
overlay rend transparent leur accès, leur localisation et leur duplication. Lorsqu’un pair
accède à une ressource, il ne sait pas si cette ressource est locale ou distante. Dans le cas où la
ressource est distante, il n’a pas de connaissance de l’hôte qui l’héberge, et si elle est
dupliquée, il ne sait pas à quel réplica il accède.
L’utilisation d’un overlay n´nécessite toutefois la mise en œuvre des mécanismes de
nommage et routage dédiés. Les pairs ne sont donc plus représentés par leur adresse de niveau
transport ou adresse physique mais par un identifiant défini dans le cadre de l’overlay. En
outre, pour pouvoir découvrir et accéder à des ressources, des services de routage, calcul de
routes, découverte et accès sont mis en place.
Remarque :
Un réseau P2P ne constitue pas obligatoirement un overlay [2]. Des applications
reposant sur les protocoles NNTP [30] ou RIP [31] sont construites selon le modèle P2P en
ce sens qu’elles ne présentent aucune centralisation et que chacun de leurs éléments agit
comme un client et un serveur sans pour autant constituer un réseau virtuel au-dessus du
réseau IP.
5. Anonymat
L’anonymat est une fonction qui permet de cacher son identité. Dans le cadre des
systèmes distribués relatifs au partage de documents. L’anonymat est utilisé dans plusieurs
applications qui voient dans le modèle P2P une infrastructure qui se prête particulièrement à
cette fonction. Tout d’abord, Freenet utilise une forme de routage qui garantit l’anonymat du
serveur, de l’auteur et du lecteur en ne permettant à aucun nœud de savoir quelle est la source
et la destination d’une requête. Ensuite, FreeHaven et Publius mettent explicitement en œuvre

18
des mécanismes d’anonymat qui ont pour rôle principal d’assurer la persistance et la
disponibilité de documents dans un environnement soumis à la censure.
Enfin, on trouve maintenant des infrastructures P2P dont le but est simplement de
fournir un service d’anonymat à des applications P2P ou centralisées. Parmi les différentes
propositions, nous en retenons trois qui sont Crowds [34], Morphmix [35] et Tarzan [36] que
nous présentons. Tarzan est une infrastructure qui rend anonyme la couche réseau IP. Pour ce
faire, elle utilise un modèle P2P pur où les pairs forment des tunnels construits de manière
pseudo-aléatoire. La manière dont les tunnels se forment est quasi-impossible à d´détecter et à
compromettre et le trafic qu’ils transportent est crypté. De plus, chaque pair est associé à
quelques autres, appelés mimes, qui vont effectuer les mêmes opérations. Par ce biais, Tarzan
empêche la d´détection de la source d’un message.
VI. Avantages et limites des réseaux pair-à-pair
1. Avantages
Les architectures P2P présentent beaucoup d’avantages parmi eux :
 Répartition de la charge :
Contrairement aux réseaux client/serveur où le serveur principal est chargé de gérer
l’ensemble des activités du réseau, d’où un risque de saturation, dans un réseau pair-à-pair, ce
sont tous les pairs qui contribuent à la gestion des différentes requêtes et des ressources
disponibles.
 Capacité de stockage décuplée :
Il est à savoir que dans un réseau à serveur central, toutes les données sont stockées au niveau
de ce serveur, ce qui vient en opposition aux réseaux pair où bien que chaque pair n’offre
qu’un petit espace disque (relativement au serveur) la capacité de stockage au sein du réseau
est décuplée grâce à la contribution de tous les pairs.
 Puissance de calcul :
Des études avancent que la puissance de calcul utilisée en moyenne par un utilisateur est de
20%, le processeur est donc sous exploité. Certaines applications pair-à-pair développées dans
le domaine de la recherche (Seti@home) visent à se servir de cette puissance inutilisée pour
réaliser des tâches réparties qu’un simple ordinateur ne pourrait accomplir en un temps
raisonnable.
 Réseaux très extensibles :
Une particularité des réseaux pair-à-pair est qu’ils sont de nature « Ad-hoc » c’est-à-dire que
des nœuds peuvent apparaître et disparaître à tout moment, cette gestion dynamique des pairs
facilite l’intégration de nouveaux pairs au sein du réseau.
 Résistance aux pannes :
Dans un réseau pair-à-pair, les ressources sont réparties sur l’ensemble des utilisateurs
connectés, la panne d’un pair ne peut donc pas altérer le fonctionnement du réseau.
 Disponibilité accrue des ressources :
Comme les réseaux pair-à-pair sont extensibles, et que les pairs sont fournisseurs de
ressources au sein du réseau, plus le nombre d’utilisateurs augmente, plus la disponibilité des
ressources présentes augmente.

19
 Diversité des chemins dans le réseau :
La topologie logique du réseau pair-à-pair étant maillée, plusieurs chemins de
communication sont possibles entre chaque couple de pairs. De plus, les échanges se font
plus rapidement étant plus directs.
 Maintenance et coûts réduits :
Le serveur d’une architecture client/serveur reste très gourmand en matière de ressources,
sa maintenance est très fastidieuse et son coût peut s’avérer très élevé. De ce fait, l’absence
de celui-ci dans les architectures pair-à-pair rend ces réseaux peu coûteux.
 Anonymat :
Certains algorithmes de routage ne permettent pas le pistage d’une requête, garantissant
ainsi l’anonymat aux utilisateurs.
 Meilleure exploitation de la bande passante :
Dans les réseaux à serveurs centraux, les goulots d’étranglements sont relativement
fréquents au niveau de ces derniers, ce qui paralyse le réseau, ainsi l’absence d’organisme
central dans les réseaux pair-à-pair facilite la circulation des flux, et augmente par
conséquent l’utilisation de la bande passante.
2. Limites
Les réseaux pair-à-pair rencontrent de nombreux problèmes et présentent quelques
inconvénients, on peut citer essentiellement :
 Topologie instable :
Les pairs d’un réseau pair-à-pair étant dynamiques, ils peuvent apparaître et disparaître à tout
moment, par conséquent les ressources aussi.
 Sécurité :
Nous pouvons citer quelques exemples : Crackers, Virus, Distributed Deny of Service (ddoS),
Confidentialité, Authentification.
 Contenu trompeur :
Un des inconvénients majeurs des applications pair-à-pair est que les données circulent
librement dans le système, sans vérification. Certains fichiers peuvent être corrompus :
mauvaise qualité, défectueux, contenu non correspondant à l’intitulé.
 QoS (Quality of Service) :
Bien que très utilisées dans d’autres domaines, beaucoup d’applications pair-à-pair sont
employées de nos jours pour le téléchargement souvent illégal de fichiers, ce qui pousse
certains fournisseurs à vouloir limiter au maximum les flux pair-à-pair au sein du réseau. La
bande passante allouée aux applications pair-à-pair est donc considérablement réduite, rendant
ainsi les échanges pair-à-pair très lents.
 Loi du Wild Wild Web :
Les applications pair-à-pair sont devenues la cible de plusieurs organismes de protection des
droits d’auteurs et lutte contre les contenus immoraux.
 Régulation/Répression :
Certains modèles de réseaux pair-à-pair garantissent l’anonymat aux utilisateurs, il est donc
plus difficile aux autorités d’appliquer les lois.

20
VII. Conclusion
Les systèmes pair-à-pair sont très utiles et ont prouvé leur efficacité durant les
dernières années. Ils sont structurés suivant différents modèles. Ils peuvent être centralisés,
décentralisés ou hybrides. Parmi ces différences entre ces architectures on s’intéresse à la
recherche des ressources c.-à-d. le routage dans les réseaux pair-à-pair.
Ce routage exige des méthodes, des mécanismes de communication, alors il nécessite des
protocoles spécifiques pour implémenter ces mécanismes.
Dans le prochain chapitre on va étudier les protocoles de routage dans les architectures
des réseaux pair-à-pair décentralisées (spécialement pour celles structurées basées sur DHT
(table d’hachage distribuée)) à l’aide des algorithmes spécifiques.

Les protocoles de routage
dans un réseau Pair à
Pair décentralisé
Chapitre 2:

22
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
I. Introduction
Les protocoles d’un réseau pair-à-pair établissent des méthodes et des mécanismes qui
garantissent les communications entre les pairs. Ces protocoles organisent les échanges des
messages et permettent la localisation des pairs, propagation des requêtes, la gestion et le
contrôle de la répartition de fichiers échangés sur tous les nœuds d’un système. Puisque, la
mise en place de ces protocoles génère un trafic d’informations très abondant sur ces réseaux
et les nœuds du réseau peuvent le quitter, ainsi que des nouveaux nœuds peuvent le rejoindre,
il existe de nombreuses architectures, qui utilisent différentes techniques de localisation des
donnés, qui se traduisent par différentes méthodes de routage des requêtes. Les solutions
proposées dans les systèmes décentralisés impliquent la création d’une structure ou non.
Les systèmes pair-à-pair décentralisée sont dite non structurés lorsqu’aucune
contrainte topologique n’existe, ni un répertoire centralisé. Alors chaque pair dans le réseau
est autonome, la découverte des ressources et La maintenance se font par inondation en
interrogeant tous les pairs associant un champ TTL (Time To Live) à chaque message de
recherche jusqu’à l’obtention du pair concerné. Le mécanisme est simple, flexible, et ne
demande pas des requêtes très précises, mais cette architecture ne peut pas être gérée
notamment sur les réseaux à grand échelle, ainsi que l’utilisation de la technique d’inondation
aboutit à une occupation importante de la bande passante, et L’utilisation de TTL est fixé à
un nombre limite, de ce fait une panne ou déconnexion dans un réseau à grand nombre des
pairs peut survenir. Gnutella est un bon exemple de cette architecture également FreeNet
mais ce dernier s’agit d’un pont vers les architectures décentralisées structurées, et il assure
l’anonymat et la permanence des informations qui y résident mais il présent des risques de
sécurité tel que man-in-the-middle ou cheval de Troie.
Les systèmes pair-à-pair décentralisée sont dite structurés lorsque la topologie logique
est imposée par un algorithme bien spécifié qui organise l’espace des pairs et aussi la
répartition des ressources. Ceci permet à n’importe quel pair de s’associer au réseau ou de le
quitter, un tel réseau est nommé « auto-organisé ». Les systèmes structurés garantissent donc
l’efficacité. La gestion des ressources s’appuie fréquemment sur l’utilisation d’une table de
hachage distribuée (DHT).
Puisque Les systèmes pair-à-pair s’orientent progressivement vers les DHT, cette table
sera détaillée dans ce chapitre qui lui est consacrée où différents algorithmes gérant le
routage dans les systèmes DHT seront ainsi présentés.
II. Les Tables de hachage distribuées (DHTs)
1. Définitions
1.1. La fonction de hachage
Une fonction f d’un ensemble E vers un ensemble F est dite injective si :
x, yE², x yf xf yCeci garantit donc que : x, yE², f xf yx y
Une fonction de hachage est une fonction injective d’un ensemble de clés vers un
ensemble de valeurs, où à une chaîne de longueur quelconque associe une valeur unique de
taille fixe, exemples de fonctions de hachages: SHA-1 (Secure Hash Algorithm 1 : 160 bits) et
MD5 (Message-Digest algorithm 5 : 128 bits).

23
1.2. La table de hachage
Une table de hachage représente un tableau qui permet l’association d’une valeur de
hachage à une structure de données , En effet, le hachage des clefs permet de retrouver
rapidement un contenu. La recherche de la valeur associée se fait alors en O(1) (un seul saut).
Les opérations essentielles dans une table de hachage sont : l’insertion : put (key,
value), la suppression : delete (key), la recherche : get (key) .
1.3. La table de hachage distribuée
Les tables de hachage distribuées (Distributed Hash Table) représentent la version
décentralisée de la structure classique d’une table de hachage, qui est partagée entre tous les
éléments actifs d’un système réparti.
2. Le principe des tables de hachage distribuées
Le principe des DHTs consiste à utiliser une fonction de hachage pour faire une
association à chaque ressource (ou objet) une clé. Cette clé devient l’identifiant d’une
ressource dont elle est dite objectId. A chaque nœud il s’est transmis un identifiant unique,
dit nodeId., la requête d’un objectif recherché est dit key, les nœuds sont dits pairs.
La DHT partitionne un index global de ces ressources, puis il distribue ces parties sur
plusieurs pairs. DHT peut être montré comme une grille, un cercle, ou une ligne selon la
spécification de l’algorithme de routage implémenté. Autrement dit:
Soit @IP : l’adresse IP d’un pair, R : une ressource, K : l’espace logique d’identification et
h : la fonction de hachage alors :
h(@IP)= nodeId, h(R)= objectId, et (nodeId, objectId)  K
Si la distance entre objectId et nodeId est minimale alors la ressource R est stockée sur
la DHT du pair d’adresse @IP et on dit que R est indexée par le pair nodeId. Si non, dans sa
DHT il existe au moins un pair P strictement plus proche de objectId, et dans ce cas un lien
sera établi vers le pair P.
La figure 2.1 donne un exemple de mécanisme de routage dans un réseau overlay basé
sur une DHT.
Figure 2.1 : DHT et mécanisme de routage overlay

24
3. Bilan De DHTs
Une « bonne » implémentation d’une DHT doit gérer efficacement : la recherche,
l’arrivée et le départ d’un nœud, et la mise à jour du contenu d’un nœud.
Les DHTs garantissent :
 l’unicité d’identifiant (clé).
 la réponse aux requêtes avec un nombre de sauts minimum que possible, surtout si la
donnée cherchée est répliquée. Cela ne concerne pas les sauts physiques (ou sauts IP) mais il
s’agit des sauts logiques..
 la faiblesse de degré de connexion : Le degré représente la taille de la table de routage
 la réduction de diamètre : Le diamètre est la plus grande distance ; en nombre de
sauts ; entre deux pairs (max log n)
 la recherche de chemin le plus court.
 L’existence d’un autre chemin vers la destination en cas de panne ou disparition de
pairs
 augmentation de performance d'un système et la facilité au passage à l’échelle.
 une distribution uniforme des ressources sur l’ensemble des nœuds
 L’implémentation de nombreux services qui exploitent la distribution cohérente de
données : Partage de fichiers, Base de données distribuée, chat , et DNS
Il existe de nombreuses implémentations, les algorithmes d’insertion et de recherche
étant différents pour chacun.
Les protocoles de routage dans les réseaux P2P utilisant des DHTs sont dits DHTs
tout simplement. Parmi eux nous en trouvons principalement : Chord [38], Tapestry
Pastry[39], CAN (Content-Addressable Network)[40], Kademlia[41], Viceroy[42] et
ulysses[43] qui seront présentés ci-suivant.
III. Architectures et protocoles pair-à-pair décentralisés et
structurés
1. Architecture en anneau :
L’architecture en anneau est la topologie la plus simple qu’on peut imaginer pour la
première fois et la plus facile à manager. Une DHT à topologie circulaire permet la meilleure
flexibilité et donne les meilleures performances de résilience et de proximité. Dans telle
architecture la proximité est numérique avec un espace d’identification circulaire. Chord est
un bon exemple de type du routage P2P avec un DHT dans une topologie en anneau.
1.1. La table de hachage distribuée Chord
1.1.1. Définition
Les nœuds sont organisés en topologie anneau orientée de 2 𝑚
pairs, avec m est le
nombre de bits de la fonction de hachage utilisée (généralement 160 bits).Chaque pair est lié
à un prédécesseur et plusieurs successeurs. Tous les objets ayant le objectId inférieur ou égal
nodeId de pair le plus proche seront stockés dans ce dernier.

25
Un nœud maintient une table de routage vers les nœuds d’identiﬁants n + 2K−1
avec k
est le nombre de bits d’identifiant. La table est donc de taille logarithmique et les opérations
de recherche de clé sont réalisées en temps logarithmique.
Le protocole Chord garde la trace dans sa table de routage à K entrées alors les
utilisateurs peut contacter directement K nœuds du réseau pour transmettre ses requêtes.
Figure 2.2 : Topologie de Chord (le réseau virtuel au-dessus du réseau physique)
1.1.2. Routage dans Chord
1.1.2.1. Routage simplifié
La Chord est la plus simple implémentation d’une DHT. Il n’y a pas de table de
routage. Chaque nœud ne communique qu’avec son successeur à la façon d’une chaine. Par
exemple, quand une requête est faite pour rechercher une clé, chaque nœud examine si la clé
recherchée est inférieure ou égale à l’identifiant de son successeur. Si cela sera vrai, alors le
nœud retourne l’identifiant de son successeur au nœud qui est l’origine de la requête. Sinon la
requête est transmise au successeur direct qui répondra.
Lookup(54)
N1
N8
N56
N51 N14
N48
N21
N42
N38 N32
Figure 2.3 : Routage simple
N 54

26
1.1.2.2. Le routage optimal
Dans le but d’optimiser le routage précédent, il est nécessaire de gérer une table de
routage qui permet une transmission des requêtes bien plus efficaces. Ici on cherche le
successeur de clé k (1<k<m) pour nœud n:
Soit C(k) le premier nœud successeur de (n+ 2 k-1
) mod 2 m
, ( m : le nombre de bits d’une clé).
Si la clé k existe localement, i.e. k appartient à [n, successeur] donc on renvoie la valeur
associée. Sinon on recherche dans la table de routage le nœud avec la plus grande valeur
inférieure ou égale à la clé cherchée.
Figure 2.4 : Routage optimale
En simplifiant le principe, voici un exemple décrivant comment cette utilisation d'un
modèle de petit monde permet de retrouver très rapidement un utilisateur dans un réseau
décentralisé. Supposons que l'utilisateur A soit à la recherche de l'utilisateur B, car il possède
un fichier qu'il recherche. A besoin de l'adresse IP de cet utilisateur, mais ne connaît que sa
clé Key(B) dans le réseau Chord (cette clé seule ne donne pas de route dans le réseau
physique d'Internet). A stocké dans sa mémoire les log(n) nœuds correspondants aux log(n)
liens supplémentaires qu'il a sur l'anneau virtuel. Si B est parmi ces nœuds, alors A retrouve
directement l'adresse de B. Sinon, A va renvoyer sa requête au nœud dont la clé est la plus
proche de Key(B) parmi les log (n) nœuds qu'il a mémorisés.

27
Figure 2.5 : exemple de retrouver très rapidement un utilisateur dans un réseau décentralisé
Chord supporte bien le facteur d'échelle. Différentes simulations ont été menées et
montrent que la longueur moyenne d'un chemin utilisé pour acheminer une requête évolue en
O(log(N)).
1.1.3. L’arrivée et le départ d’un nœud
Lorsqu'un nouveau pair X arrive sur l’overlay, il commence par prendre sa place dans
l'anneau par apport à son nodeId. Puis il envoie un message vers le successeur le plus
proche, ce dernier envoie toutes ses clés inférieures à nodeId de X vers le pair X. alors Les
pairs mettent à jour leurs tables de routage.
Un pair est détecté indisponible lorsque les autres pairs ne peuvent plus communiquer
avec lui .car le pair défaillant a quitté l’overlay ou une panne a été introduite. Alors les autres
1.1.4. Applications Basées Sur Chord
Parmi les applications utilisant Chord comme un réseau de base on en trouve:
o CFS (Collaborative File System) [21] : un système de fichiers distribués à l’échelle de
l’Internet, et où chaque fichier est partagé en blocs ;
o ConChord [46] : une infrastructure distribuée qui utilise CFS et délivre des certificats
de sécurité SDSI (Simple Distributed Security Infrastructure) ;
o Chord-based DNS[47] :qui propose une implémentation P2P du DNS (Domain Name
Service).

28
2. Architecture Maillée De Plaxton
Pour les systèmes distribués statiques un algorithme, dit Plaxton[48], a été développé
en 1997, C’est le premier algorithme destiné aux mailles quelconques applicables avec DHTs.
Il peut donc localiser les objets en utilisant des tables de routage de taille fixe. Les identifiants
des nœuds et des objets se caractérisent par une indépendance totale des sémantiques et ils
sont purement numériques. Chaque nœud est une racine d’un arbre de recouvrement. Le
routage implémenté est hyper-cube, qui se fait par rapprochement successif digit par digit
dans l’identifiant numérique jusqu’à avoir l’objectif. Son fonctionnement peut être basé soit
sur le préfixe comme pastry, soit sur le suffixe comme tapestry
Figure 2.6 : Exemple de suffixe routing
2.1. La table de hachage distribuée Tapestry
2.1.1. Définition
Dans Tapestry, on utilise la fonction de hachage fixée à 160 bits dans un espace
d’identification avec une maille quelconque. L’identifiant de l’objet est désigné par GUID
(Global Unique IDentifier) au lieu d’objectId. Ce noeud racine identifie l’objet de manière
unique. Le routage se fait vers le pair le plus proche numériquement dans le niveau
hiérarchique supérieur, on parle alors de surrogate routing. Durant le routage de pair jusqu’au
sommet des répliques de l’objet avec des différentes clés sont y insérés. Le pair responsable
de l’objet maintien des positions des pairs supports des répliques. Ce routage est basé sur le
suffixe et la recherche récursive.
La figure 2.7 ci-dessous montre exemple sur ce propos.

29
Figure 2.7 : Exemple des niveaux hiérarchiques dans Tapestry (map du noeud 5642)
2.1.2. Routage dans Tapestry
La table de routage dans Tapestry est dimensionnée de b lignes et LogbN colonnes où
b est la base d’identificateur de clé. Chaque colonne représente un niveau de suffixe afin que
des back pointers pointent vers les pairs reconnaissant le pair courant comme l’un de leurs
voisins. Dans chaque ligne, chaque pair pointe vers des pairs voisins de même suffixe, alors la
table de routage contient les pairs les plus proches numériquement.
2.1.3. Applications basées sur Tapestry
Parmi les applications utilisant tapestry comme un réseau de base on en trouve:
o OceanStore : une application de stockage massif.
o SpamWatch [49] : un système collaboratif de filtrage du pourriel.
2.2. La table de hachage distribuée Pastry
2.2.1. Définition
Ce système est purement décentralisé s’inspire de la topologie en anneau de Chord,
mais l’espace d’identification est circulaire non orienté, Les recherches peuvent donc se faire
dans un sens ou dans un autre.
L’identifiant d’un nœud avec une taille de 128 bits est obtenu d’une manière aléatoire
basée sur l’adresse IP ou la clé publique selon l’algorithme désiré en utilisant une fonction
d’hachage fixée à 128 bit, afin de générer des identifiants uniformément distribués sur
l’espace de l’identifiants.
Le routage est garanti par une distinction du nœud dans la table, en présentant le plus
long préﬁxe commun avec l’identifiant de la ressource pour faire le prochain routage.
Pastry est basé sur un mécanisme de routage fondé sur la notion de préﬁxe.

30
2.2.2. Le routage dans Pastry
2.2.2.1. Routage d’un message dans Pastry
Supposons qu’un nœud A soit à la recherche de nœud avec la clé K pour lui
transmettre un message m, il route le message au nœud qui a le nodeId le plus proche
numériquement de la clé K. Autrement dit vers un nœud où nodeId partage avec la clé K
recherchée un préfixe commun. Ce routage est basé sur la correspondance de préfixe.
Figure 2.8 : Le routage d’un message de proche en proche dans Pastry
Cette figure représente un exemple de routage d’un message, où le nœud d’identifiant
89B1CC route un message vers le nœud de la clé E19BCA. Lors de la première étape, le
nœud 89B1CC envoie le message à un nœud dont l’identifiant a un chiffre en commun avec la
clé recherchée, dans cet exemple le nœud est EF25BA. Lors de la seconde étape, le nœud
E1CC5A retransmet m à un nœud dont l’identifiant a trois chiffres en commun avec la clé
recherchée, ici le nœud E192C5. Ainsi de suite jusqu’à arriver m à le nœud de la clé
E19BCA.
2.2.2.2. Exemple de table de routage dans Pastry
Les nœuds ont une table de routage, cette table est composée de L/2b
lignes et 2b
− 1
colonnes (L est le nombre de bits des identifiants=128, b valant typiquement 4), la
numérotation des lignes commencent à partir de 0. L’entrée [i, j] de la table référence un
nœud dont l’identifiant partage ses i − 1 premiers chiffres avec l’identifiant du nœud local.
La table suivent représente la table de routage du nœud d’identifiant 65a1x. La ligne 0
est occupée d’identifiants n’ayant aucun chiffre en commun avec 65a1x, La ligne de rang 1
est occupée d’identifiants commençant par le chiffre 6, et ainsi de suite.

31
Figure 2.9 : Exemple d’une table de routage d’un nœud Pastry. Extrait de [74]
Si l’on suppose que le réseau contient N nœuds et que leur identifiants est
uniformément répartis, alors seules les "log2
b
N" premières lignes de la table sont en moyenne
occupées.
2.2.3. L’Arrivée et le départ d’un nœud
Lorsqu'un nouveau pair X arrive sur l’overlay, il génère son nodeld, puis il envoie un
message contenant sa clé. Le DHT pastry transmet le message jusqu'au nodeID le plus proche
numériquement, alors chaque pair intermédiaire dans cette route envoie une ligne de leur table
de routage correspondante au nodeld de X vers X, alors X établi sa table de routage a partir de
ces informations.
avec lui .car le pair défaillant a quitté l’overlay ou une panne a été introduite. alors les autres
Figure 2.10 : Exemple de routage dans Pastry

32
2.2.4. Applications basées sur Pastry
Parmi les applications utilisant pastry comme un réseau de base on en trouve:
o SCRIBE [50] : une application de diffusion multi-groupes.
o PAST : un utilitaire de stockage massif.
o PASTICHE [51] : un système de sauvegarde qui exploite les capacités disponibles
des antémémoires réparties dans le réseau.
3. Architecture torique
La DHT propose un exemple basé sur une topologie de tore à d dimensions à
coordonnées cartésiennes. Elle est uniformément partagée en zones. Les objets sont stockés
en points cartésiens de l’espace, Chaque pair est responsable des objets de sa zone.
CAN (Content-Addressable Network) est un exemple type d’une DHT avec une structure
torique.
3.1. La table de hachage distribuée CAN
3.1.1. Définition
La DHT CAN propose un espace vectoriel cartésien multidimensionnel dont chaque
portion de l’espace peut être adoptée par un nœud, et chaque nœud arrange les informations
sur ses voisins directement connectés. Chaque identiﬁant est converti en coordonnées dans
l’espace CAN. Le routage en CAN s'effectue de proche en proche en passant par tous les
voisins jusqu’à arriver au pair cible: pour faire un saut, le nœud réceptionnant la requête la
communique au voisin dont les coordonnées de ce voisin se chevauchent sur d-1 dimensions
et sont contiguës sur la dimension restante. À chaque saut, on ne peut changer de coordonnées
que sur une dimension.
CAN est une infrastructure décentralisée et distribuée. Il est organisé autour d’un
espace virtuel de coordonnées cartésiennes de dimension d (d-tore). L’espace des
coordonnées est partitionné dynamiquement entre les nœuds. La Figure 2.11 montre un
exemple d’espace de coordonnées cartésiennes de deux dimensions [0, 1] [0, 1] partitionné
entre six nœuds.
Figure 2.11 : Espace de coordonnées cartésiennes de dimensions 2 partagé entre 6 nœuds
CAN .extrait de [40]
CAN est construit de 3 pièces de base : Le routage, la construction de la couverture de
coordination et la maintenance de sa couverture. Les pairs dans le système CAN maintiennent
des tables de routage qui contiennent les adresses IP et les coordonnées virtuelles de zones
voisines (2.d voisins).
E F
CA B
D
1.0
0.5
0.0 0.5 1.0
0.5 Les coordonnées cartésiennes
de chaque zone
A( 0.0 - - 0.25 , 0.0 - - 0.5 )
B( 0.25 - - 0.5 , 0.0 - - 0.5 )
C( 0.5 - - 1.0 , 0.0 - - 0.5 )
D( 0.0 - - 0.5 , 0.5 - - 1.0 )
E(0.5 - - 0.75 , 0.5 - - 1.0 )
F(0.75 - - 1.0 , 0.5 - - 1.0 )

33
3.1.2. Arrivée d’un nœud
Quand un nouveau nœud rejoint le réseau par l’intermédiaire d’un autre nœud qui
existe déjà dans le système (trouvé par la technique de Boostrapping), il choisit un point P
dans l’espace de coordonnées cartésiennes d’une manière aléatoire, il envoie une requête
JOIN au nœud dont lequel sa zone contient le point P. Cette zone sera subdivisée en deux
parties, l’une des moitiés sera assignée au nouveau nœud. Les deux nœuds mettent à jour les
listes de leurs voisins.
Dans un espace de dimension 2 (Figure2.12), une zone est subdivisée premièrement
suivant l’axe des X, ensuite suivant l’axe des Y.
Figure 2.12 : espace de coordonnées cartésiennes avant que le nœud F arrive
3.1.3. Départ d’un nœud
Quand un nœud quitte le réseau (Figure 2.13), la zone qui été occupée par ce nœud
sera occupée par un de ses voisins. Une mise à jour des listes de voisins est nécessaire pour
ces derniers.
A
B E
C
D
1.0
0.75
0.5
0.0
0.5 0.75 1.0
A
B
C
D
1.0
0.75
0.5
0.0
0.5 0.75 1.0
Les coordonnées cartésiennes
de chaque zone
A( 0.0 - - 0.5 , 0.5 - - 1.0 )
B( 0.0 - - 0.5 , 0.0 - - 0.5 )
C( 0.5 - - 1.0 , 0.75 - - 1.0 )
D( 0.5 - - 1.0 , 0.5 - - 0.75 )
E(0.5 - - 1.0 , 0.0 - - 0.5 )
de chaque zone
A( 0.0 - - 0.5 , 0.5 - - 1.0 )
B( 0.0 - - 0.5 , 0.0 - - 0.5 )
C( 0.5 - - 1.0 , 0.75 - - 1.0 )
D( 0.5 - - 1.0 , 0.5 - - 0.75 )
E(0.5 - - 0.75 , 0.0 - - 0.5 )
F(0.75 - - 1.0 , 0.0 - - 0.5 )
(a)
(b)

34
Figure 2.13 : espace de coordonnées cartésiennes avant que le nœud D quitte
3.1.4. Le routage
Chaque table de routage d’un nœud contient l’identifiants des nœuds voisins leurs
adresses IP et leurs coordonnées cartésiennes, alors le routage se fait selon ces coordonnées
pour décider à quelle destination la raquette va être envoyée. Même si un pair intermédiaire
(dans le chemin reliant L et J) quitte le système, il y aura toujours un autre chemin qui relie
ces deux nœuds.
La figure 2.14 illustre un exemple de répartition et de routage dans un réseau CAN de
dimension 2.
4. Architecture en arborescence
L’architecture en arborescence dessine un arbre logique mais il n’y a pas
d’hiérarchisation entre les nœuds alors c’est une topologie plate où les nœuds sont les feuilles
de cet arbre logique. Dans lequel l’espace d’identification est en base 2. Le protocole CAN ,
que nous avons vu plus haut peut être transposé en une arborescence.
A
B E
C
D
1.0
0.75
0.5
0.0
0.5 0.75 1.0
A
B E
C
1.0
0.75
0.5
0.0
0.5 0.75 1.0
de chaque zone
A( 0.0 - - 0.5 , 0.5 - - 1.0 )
B( 0.0 - - 0.5 , 0.0 - - 0.5 )
C( 0.5 - - 1.0 , 0.75 - - 1.0 )
D( 0.5 - - 1.0 , 0.5 - - 0.75 )
E(0.5 - - 0.75 , 0.0 - - 0.5 )
F(0.75 - - 1.0 , 0.0 - - 0.5 )
de chaque zone
A( 0.0 - - 0.5 , 0.5 - - 1.0 )
B( 0.0 - - 0.5 , 0.0 - - 0.5 )
C( 0.5 - - 1.0 , 0.5 - - 1.0 )
E(0.5 - - 0.75 , 0.0 - - 0.5 )
F(0.75 - - 1.0 , 0.0 - - 0.5 )
(a)
(b)
F F
Figure 2.14 : Exemple de routage dans CAN

35
Maintenant nous étudions et analysons Kademlia car ce protocole est un bon exemple
de cette architecture (arborescence) qui a déjà été introduit et fait ses preuves dans le monde
p2p.
4.1. La table de hachage distribuée Kademlia
4.1.1. Définition
Kademlia est un protocole de réseau basé sur les tables de hachages distribuées et la
métrique XOR, il utilise le principe des tables de hachages distribuées pour hiérarchiser et
organiser le réseau en un arbre binaire. La complexité étant alors en Log(n) lors d’une
recherche.
4.1.2. Description
L’un de ces principaux atouts par rapport aux autres systèmes DHT est le nombre
réduit de messages de c configuration à envoyer. En termes de recherche de ses voisins, un
nœud doit être capable de connaitre suffisamment la topologie du réseau pour pouvoir
transmettre ses requêtes avec un temps de latence court. Ce temps de latence reste minime
grâce à l’utilisation du protocole UDP pour l’envoie de tous les messages de configuration et
communication au sein du réseau. De même, les requêtes sont envoyées de façon parallèles et
non synchronisées pour accélérer les temps de transmission et éviter les temps d’attente
venant des nœuds défectueux (timeout).
Chaque nœud du réseau possède un ID propre qui est une clé de 160 bits. Les entrées
de la table de hachage sont également des clés de 160 bits, et sont associées à une valeur, qui
dans notre cas sera une structure, ce qui donne la paire (clé-valeur) comme élément de la
table. Un nœud du réseau ne stocke dans sa table que les paires (clé-valeur) dont la clé est la
plus proche de son ID.
L’autre principal atout de Kademlia réside dans la nouvelle métrique XOR utilisée.
Comme il s’agit d’une métrique symétrique, cela permet aux nœuds de Kademlia de recevoir
les réponses de requêtes depuis exactement le même ensemble de nœud que celui contenu
dans sa table, qui correspond à l’ensemble des nœuds contactés. Sans cette symétrie, les
systèmes comme Chord n’apprennent rien des requêtes reçues concernant la topologie du
réseau. En effet , les nœuds du réseau Kademlia mettent à jour leur table à chaque message
UDP reçu, en stockant si nécessaire les informations relatives au nœud expéditeur.
4.1.3. Localisation d’un nœud dans le réseau
La localisation d’un ID du réseau (ou clé), qui peut représenter une machine connectée
ou bien un fichier, repose sur un unique algorithme de recherche, contrairement à beaucoup
d’autres systèmes DHT. En effet, l’espace des IDs est traité par Kademlia comme un arbre
binaire où chaque nœud du réseau est une feuille, représentée par un unique ID. Si l’arbre
n’est pas complet, il se peut que la recherche d’un ID ne converge pas vers un unique ID,
mais renvoie tous les IDs les plus proches.
Etant donné un nœud, on divise l’arbre binaire en une série de sous arbres ne
contenant pas le nœud en question. Le premier sous arbre obtenu correspond à la moitié de
l’arbre de départ ne contenant pas le nœud. Le suivant est la moitié de l’arbre restant ne

36
contenant pas le nœud, et ainsi de suite. Dans la figure 2.15 on considère le nœud 0111, les
sous arbres obtenus sont entourés dans la figure 2.16. Le protocole Kademlia assure que tous
les nœuds du réseau connaissent au moins un nœud dans chacun de ces sous arbres. Cette
garantie permet à tout nœud du réseau de pouvoir contacter un autre nœud par son ID. La
figure 2.15 montre un exemple de localisation par requêtes successives sur le nœud le plus
proche connu, qui est donc le "meilleur" nœud à contacter (ici le nœud 0111 recherche le
nœud 1101). La figure 2.16 représente un arbre binaire de Kademlia, « joe » est le nœud de
preﬁxe 0111.
Figure 2.15 : Localiser un nœud par son ID
Figure 2.16 : Arbre binaire de Kademlia

37
4.1.4. Distance entre deux nœuds : métrique XOR
La notion de distance dans le protocole Kademlia repose sur l’opérateur "ou-exclusif
bit à bit". Etant données deux IDs, la distance entre elle vaut : d(x; y) = XOR (binaire(x);
binaire(y)). Les propriétés mathématiques du XOR nous permettent de dire que son résultat
est toujours positif ou nul (seulement si x = y), et surtout, d(x; y) = d(y; x), ce qui garantit la
symétrie de cette métrique. On remarque que cet opérateur permet de récupérer la distance
entre 2 IDs.
4.1.5. L’arrivée et le départ d’un nœud
Lorsqu'un nouveau pair X arrive sur l’overlay, il génère son nodeID, puis il envoie un
message contenant son clé. Lorsqu’un pair reçoit un message, il met à jour le bucket
approprié. Si le noeud expéditeur se trouve déjà dans ce bucket, il est déplacé en bas de la
liste. Sinon, si le bucket n’est pas plein, la nouvelle entrée est insérée. Si le bucket est plein, le
noeud A émet un PING vers le voisin le plus ancien dans ce bucket. Si ce dernier répond au
PING, il est alors déplacé en fin de liste et la nouvelle entrée est ignorée. Kademlia conserve
donc dans sa table les noeuds les plus anciens dans le réseau.
avec lui .car le pair défaillant a quitté l’overlay ou une panne a été introduite. Alors les autres
4.1.6. Applications basées sur Kademlia
Parmi les applications utilisant Kadmelia comme un réseau de base on en trouve:
o BitTorrent
o eMule (sous le nom de Kad)
5. Architecture en papillon
L’architecture est dite papillon (butterfly) si les connexions établies entre les nœuds
du réseau figurent des formes semblables aux papillons. Ce type d’architecture a initialement
été conçu pour les systèmes multiprocesseurs SIMD (Single Instruction Multiple Data).
Viceroy et ulysses sont des protocoles de routage dans un réseau P2P basés sur
l’architecture en question.
5.1. La table de hachage distribuée Viceroy
C’est est un protocole de DHT qui s’insinue de Chord , appliqué à une topologie à
multiples anneaux , dite aussi multi-anneaux. De par l’architecture, chaque pair a une
connectivité (ou degré) constante, c’est à dire un nombre de voisins fixe (typiquement égale à
7), Un niveau consiste en un anneau bidirectionnel.
Chaque pair contient :
o deux pointeurs principaux : reliant les nœuds d’un même niveau (vers le nœud
précédent et le nœud suivant).

38
o deux pointeurs de niveau : vers des nœuds voisins des niveaux supérieur et inférieur
sur l’anneau de référence (généralement celui de niveau 1) .
o trois pointeurs papillon : vers le nœud le plus proche sur le niveau d’indice inférieur
et vers les nœuds à gauche et à droite sur le niveau d’indice supérieur.
À noter que les indices des niveaux vont croissants vers le bas.
Figure 2.17 : Illustration simplifiée de l'architecture de Viceroy,
Extrait de [42]
Le routage avec Viceroy se fait en commençant par le niveau du nœud qui lance sa
requête, puis en remontant jusqu’au niveau supérieur à l’aide des pointeurs de niveau, qui
permettent par la suite d'effectuer la descente en s’approchant de la clé aux niveaux d’indices
inférieurs, et ce récursivement jusqu’à satisfaction de la requête.
5.2. La table de hachage distribuée Ulysses
Ulysses est un autre protocole de routage P2P, il propose une amélioration du graphe
papillon basé sur Viceroy. Le protocole Ulysses ajoute des liens supplémentaires entre les
pairs de niveaux différents. Ces liens servent de raccourcis pour éviter les liens congestionnés
durant le fonctionnement dynamique du réseau afin de garantir un système sans congestion et
avec un trafic réparti équilibré.
IV. Comparaison Et Analyse
Des études comparant les performances théoriques des différentes architectures P2P
décentralisées et structurées ont été effectuées, la plupart de ces études d'évaluation sont
basées sur le degré et le diamètre d’un protocole.
Le tableau 2.1 résume les performances des principaux protocoles présentés
précédemment.

Les protocoles de routage dans les réseaux pair a-pair - master informatique-s§r- 2016 -

Les protocoles de routage dans les réseaux pair a-pair - master informatique-s§r- 2016 -

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à Les protocoles de routage dans les réseaux pair a-pair - master informatique-s§r- 2016 -

Similaire à Les protocoles de routage dans les réseaux pair a-pair - master informatique-s§r- 2016 - (20)

Les protocoles de routage dans les réseaux pair a-pair - master informatique-s§r- 2016 -