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
ملخص
هذه تحتوي. العنكبوتية الشبكة يسمى ما او IP شبكة طبقة فوق بتتُث افتراضية شبكة هي( للند الند ( P2P شبكة
. يرهظن مع المساواة قدم على منهم واحد كل يكون أن ويجب ، كالحواسيب لنهائية ا االلي اإلعالم اجهزة على الشبكة
كل على الموارد توزيع و المركزيةلللند با الند امظن يسمح. الوقت نفس في خدمات مقدم و زبون بمثابة نظير كل ويعمل
.مباشرة بطريقة والتعاون االتصال كذلك و ، االقران
بانتظام مركبة تكون ان يمكن التي ةالالمركزي البنية المركزية، البنية 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.1. Définition 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.1. Définition 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.1. Définition 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.1. Définition 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
Page Titre Tableau N°
13 Comparaison des infrastructures client-serveur et P2P Tableau 1.1
39 Comparaison le degré et le diamètre de quelques
protocoles de routage P2P utilisant des DHTs Tableau 2.1
44 Notations et leur signification Tableau 3.1
49-50 Quelques simulateurs des réseaux pair-à-pair Tableau 4.1
54 Configuration de l'ordinateur de développement Tableau 4.2
54 L’environnement logiciel de simulation Tableau 4.3
55 Quelques Paramètres de default.ini Tableau 4.4
56 Description de paramétrés OverSim Tableau 4.5
58 Description de paramétrés de sortie Tableau 4.6
59 Première Scenario Tableau 4.7
59 Deuxième Scenario Tableau 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
offert, 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
trafic 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].
Chapitre 1 Les Réseaux Pair-A-Pair
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)
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-Pair
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 :
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-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.
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-Pair
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
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-Pair
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.
Chapitre 1 Les Réseaux Pair-A-Pair
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, yE², x yf xf yCeci garantit donc que : x, yE², f xf yx 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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
Un nœud maintient une table de routage vers les nœuds d’identifiants 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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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
pairs mettent à jour leurs tables de routage.
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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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éfixe 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éfixe.
30
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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 2
b − 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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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 "log2bN" 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.
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
pairs mettent à jour leurs tables de routage.
Figure 2.10 : Exemple de routage dans Pastry
32
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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 identifiant 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
C A 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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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 )
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 - - 0.75 , 0.0 - - 0.5 )
F(0.75 - - 1.0 , 0.0 - - 0.5 )
(a) (b)
34
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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
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 - - 0.75 , 0.0 - - 0.5 )
F(0.75 - - 1.0 , 0.0 - - 0.5 )
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.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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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
prefixe 0111.
Figure 2.15 : Localiser un nœud par son ID
Figure 2.16 : Arbre binaire de Kademlia
37
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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.
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
pairs mettent à jour leurs tables de routage.
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
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
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.
39
Chapitre 2 Les protocoles de routage dans un réseau Pair à Pair décentralisé
Les paramètres de comparaison adoptés sont : le diamètre et le degré.
o Le degré représente la taille de la table de routage.
o Le diamètre est la plus grande distance en nombre de sauts entre deux pairs.
Protocole Degré Diamètre Degré Diamètre
Chord et Kademlia O(log2 N) O(log2 N)
Tapestry et Pastry O(log2bN) O(log2
bN)
CAN O(d) O(dN 1/d
)
Viceroy O(1) O(log N)
Ulysses O(k) O(log N / log k)
Tableau 2.1 : Comparaison des degré et diamètre de quelques protocoles de routage P2P
utilisant des DHTs
Avec :
o b : nombre de bits dans l’alphabet utilisé (ex : en hexadécimal b=4)
o N : nombre de nœuds
o k : nombre de lien supplémentaire pour ulysses.
o d : le nombre de dimensions pour CAN
Quelques remarques d’analyse comparative :
o Les architectures utilisant la métrique ou-exclusif (XOR) et celles de topologie en
anneau permettent la meilleure résilience quand on parle de la mise à jour des pairs
voisins et le choix d’autres routes en cas d’obstacle (flexibilité).
o Malgré les performances assez intéressantes d’Ulysses, Il reste lourd à mettre en œuvre,
car il possède des nombreux liens croisés à gérer, notamment à grande échelle.
V. Conclusion
Le but des réseaux P2P est de fournir une méthode efficace pour partager les
ressources entre les pairs, donc l’étude de la performance de protocoles de routage et les effets
des paramètres DHT sur le routage sont essentiels. Dans ce chapitre on a présenté la diversité
et multitude des protocoles de routage utilisés dans les réseaux Pair-a-Pair ainsi que la
spécificité de chacun. Notre étude s’est focalisée sur les réseaux logiques structurés avec leurs
tables de hachages distribuées, parmi eux nous en trouvons principalement Chord, Kademlia,
Pastry, qui faisaient partie substantielle de notre étude.
L’analyse des principaux aspects qui influent directement sur les performances d'un tel
système fera l’objet du prochain chapitre.
Influence des paramètres DHT sur la performance
des protocoles
Chapitre 3 :
Chapitre 3 Influence des paramètres DHT sur la performance des protocoles
41
I. Introduction
Différents DHTs forment des différentes topologies avec ses tables de routage, qui
donnent des différentes performances selon le DHT utilisé.
Le temps de recherche seule ne suffit pas pour évaluer les protocoles, ce métrique ne
tient pas en compte le coût du maintien de l'état nécessaire pour obtenir une faible latence de
recherche. Autres paramètres peuvent être introduits tel que le taux du succès, le nombre de
sauts de réseau au cours des recherches, l’échec des nœuds simultanément, le degré de
parallélisme, le degré de réplication, l’intervalle de stabilisation, l’équilibrage de la charge, la
longueur de chemins, la charge de CPU (central processing unit) et autres paramètres que
nous allons détailler ci-suivant.
L'évaluation des performances de recherche dans les réseaux overlay tend à favoriser
les protocoles comme Chord , Kademlia et Pastry qui gardent des grandes tables de routage,
puisque ils paient petit effort pour garder les tables à jour.
La plupart des travaux antérieurs évaluent la performance de différents DHTs tels que
Chord, kademlia et Pastry alors qu’autres concentrent sur la comparaison entre les protocoles.
L’utilité de cette étude est de comprendre la majorité des paramètres qui influent sur
la performance des protocoles de routage P2P.
II. Etat de l’art
1. Évaluation de Chord [38]
Les auteurs ont évalué le protocole Chord par simulation, ils ont également présenté
quelques résultats expérimentaux préliminaires d'un système opérationnel basé sur Chord
fonctionnant sur les hôtes Internet.
1.1. Le type de Protocole implémenté
Le protocole peut être mis en œuvre dans un processus de style itératif ou récursif.
Dans le style itératif, il demande une série des nœuds pour obtenir des informations à partir de
leurs tables de routage à chaque fois qu’il se rapproche au successeur désiré sur l'anneau de
chord. Dans le style récursif, chaque nœud intermédiaire transmet une requête vers le nœud
suivant jusqu'à ce qu'il atteigne le successeur désiré.
Les auteurs ont choisi le simulateur qui implémente les protocoles dans un style
itératif.
1.2. L’équilibrage de la charge
Les auteurs ont voulu distribuer les clés aux nœuds dans un réseau overlay avec N
nœuds et K clés, ils ont essayé de serrer la distribution autour de K / N.
Ils ont considéré un réseau constitué de 104 nœuds, et le nombre total de clés varie à
partir de 105 jusqu’ à 10
6.
Pour chaque valeur, ils ont répété l'expérience 20 fois. Ils ont présenté la moyenne, 1er
et 99eme
pourcentage du nombre de clés par nœud. Le nombre de clés par nœud présente des
grandes variations qui s’accroissent linéairement avec le nombre de clés. Par exemple, dans
tous les cas certains nœuds ne stockent pas de clés.
Chapitre 3 Influence des paramètres DHT sur la performance des protocoles
42
Pour clarifier ce point, les auteurs ont présenté la fonction de densité de probabilité
(PDF) du nombre de clés par nœud quand il y a 5 * 105 clés stockées dans le réseau.
Remarque :
Dans la théorie des probabilités, une fonction de densité de probabilité (PDF), ou la densité
d'une variable aléatoire continue, est une fonction qui décrit la probabilité relative à cette
variable aléatoire pour prendre une valeur donnée. La probabilité de la variable aléatoire se
situant dans une plage de valeurs est donnée par l'intégrale de la densité de cette variable au
cours de cette gamme, qui est donnée par l'aire sous la fonction de densité, mais au-dessus de
l'axe horizontal, et entre le plus bas et le plus grand valeurs de la gamme.
1.3. Longueur du chemin
La performance de tous les protocoles de routage dépend fortement de la longueur du
chemin entre deux nœuds quelconques dans le réseau.
Dans le contexte chord, la longueur du chemin que le nombre des nœuds ont traversé
lors d'une opération de recherche est définie. D'après chord, avec une forte probabilité, la
longueur de la voie de résoudre une requête est O (log N) où N est le nombre total de nœuds
dans le réseau.
Pour comprendre les performances de routage dans la pratique, les auteurs ont simulé
un réseau avec N = 2K nœuds, et le nombre de clés= 100 * 2
K clés. Ils ont fait varier K de 3 à
14 et ont mené une expérience séparée pour chaque valeur. Chaque nœud dans une expérience
a choisi un ensemble aléatoire des clés pour interroger à partir du système et ils ont mesuré la
longueur du chemin nécessaire pour résoudre chaque requête.
Les auteurs ont présenté le pourcentage de longueur de chemin en fonction de N.
1.4. Échec des nœuds simultanément
Dans cette expérience, ils ont évalué la capacité de chord de retrouver la consistance
après un grand pourcentage de nœuds échouent simultanément.
Ils ont considéré à nouveau un réseau de 104
nœuds qui stocke 106
clés, et ont choisi
au hasard une P fraction de nœuds qui échouent. Après les échecs qui se produisent, ils ont
attendu le réseau pour terminer la stabilisation, puis mesurer la fraction des clés qui ne
pouvaient pas être examinées correctement. Une recherche d'une clé correcte est celle qui
trouve le noeud qui était à l'origine responsable de la clé. Concernant les échecs, ceci
correspond à un système qui stocke les valeurs des clés, mais ne se répliquant pas les valeurs
ou les récupérer après les échecs.
Ils ont clarifie le taux d'échec moyen de recherche et de l’intervalle de confiance [77]
de 95% en fonction de P. Le taux d'échec de la recherche est presque exactement P. Puisque
ceci est juste la fraction des clés attendus à perdre en raison de l'échec des nœuds
responsables.
1.5. La recherche des ressources au cours de stabilisation
DHTs utilisent des mises à jour des tables de routage dans des intervalles du temps
fixés afin de confronter les effets indésirables de désabonnement des nœuds sur le routage.
L'objectif de stabilisation est de garder les informations de routage de chaque pair cohérentes
dans l’overlay avec la topologie d’évolution continue. Il existe deux approches alternatives à
la stabilisation: périodiques et réactifs [73].
Chapitre 3 Influence des paramètres DHT sur la performance des protocoles
43
La Stabilisation périodique peut utiliser soit un taux de stabilisation fixe soit un calcul
de taux de stabilisation de façon adaptative. Alors que la stabilisation réactive dépend à
chaque évènement de changement dans l’overlay tel que le joint/quitte de nœud.
Dans cette expérience, une recherche est considérée comme ayant réussi s’il atteint le
successeur actuel de la clé souhaitée. Cependant, cette méthode permet de concentrer sur
d’effectuer des recherches sur la capacité de Chord, plutôt que la capacité du logiciel de la
couche supérieur pour maintenir la cohérence de ses propres données. Toute défaillance de la
requête sera le résultat des incohérences dans Chord. En outre, le simulateur ne réessaie pas
des requêtes si une requête est transmise à un nœud qui est en panne, la requête s’échoue tout
simplement.
La source principale d'incohérences est le rejoint et le quitte des nœuds. Le mécanisme
principal pour résoudre ces incohérences est le protocole de la stabilisation. La performance
de Chord sera sensible à la fréquence du nœud rejoint /quitte par rapport à la fréquence dans
laquelle le protocole de stabilisation est invoqué.
Dans cette expérience, les Jointures et les échecs sont modélisés avec le taux de
d'arrivée moyenne.
Chaque nœud exécute les routines de stabilisation à des intervalles aléatoires en
moyenne 30 secondes. L’overlay à simuler comporte plus de 500 nœuds.
Les auteurs présentent les taux moyens de défaillance (recherches échoué) en fonction
du taux rejoint /échec.
1.6. L’expérience pratique sur l’Internet Cette expérience présente des mesures de latence obtenues à partir d'un prototype de
la mise en œuvre de Chord déployée sur Internet. Les nœuds sont à une dizaine de sites aux
États-Unis, en Californie, Colorado, Massachusetts, New York, Caroline du Nord, et en
Pennsylvanie. Le logiciel Chord fonctionne sur UNIX, utilise les clés 160 bits obtenus à partir
de la fonction de hachage SHA-1, et utilise le protocole TCP pour communiquer entre les
noeuds. Chord fonctionne dans le style itératif.
Les auteurs ont montré le temps d’attente de la recherche sur une plage de nombres
des nœuds.
2. Évaluation de Kademlia
2.1. Les effets de paramètres DHT [76]
2.1.1. Méthodologie expérimentale
Les auteurs ont utilisé le logiciel NetHawk EAST (un logiciel de simulation) pour
simuler le protocole kademlia dans un réseau P2P. NetHawk EAST est un test de
l'automatisation et un outil de génération de trafic pour simuler les réseaux de
télécommunication. Il a la fonctionnalité de codage et de décodage binaire qui est appropriée
pour le format binaire des nodeIds et objectIds de P2P. Ils ont précisément pu émuler les
messages binaires de Kademlia et rendre la charge de trafic aussi proche de la réalité que
possible. Ils ont utilisé un serveur dédié pour faire fonctionner leurs simulations.
Le matériel utilisé est un serveur Xeon (TM) CPU 3,06 GHz, 2,00 Go de RAM.
L'environnement logiciel est Microsoft Windows XP Professional 2002 Service Pack 2 et
NetHawk_EAST_IMS_v2.0.1_U1.1.
Chapitre 3 Influence des paramètres DHT sur la performance des protocoles
44
En raison des limitations du matériel, ils ne pouvaient simuler qu’un overlay de 400
nœuds. Toutes les mesures et les résultats réalisés sont basés sur les 400 nœuds de l’overlay.
Les nœuds restent en ligne et hors ligne (quittent et rejoignent l’overlay) à savoir un
intervalle de temps.
Les auteurs ont fixé les mêmes intervalles de en ligne et de hors ligne. Ils ont fixé à
l’Environ de la moitié des nœuds en ligne, et le reste hors ligne. En changeant le temps moyen
d’intervalles. Les Plus petits valeurs monline et moffline signifient des plus niveaux élevés
d’overlay.
Chaque essai dure deux heures. Les nœuds utilisent la même adresse IP et la même
NodeID quand ils rejoignent l’overlay après l'intervalle de temps hors ligne (moffline).
Ils ont utilisé un serveur dédié qui reste en ligne tous le temps pour chaque expérience
dans le but d’assurer la continuité de fonctionnalité de l’overlay. Dans l'étape initial, les
nœuds sont joindre à l’overlay à un taux de 2 noeuds / s. Après 200 noeuds ont rejoint
l’overlay, un intervalle stabilisation de 200 s est utilisé pour remplir leurs tables de routage
avec les indexes de routage appropriés de l’overlay. Ensuite, l’étape de taux de
désabonnement est commencé, les nœuds en ligne quittent l’overlay (après leur temps en
ligne expire) et les nœuds hors ligne se joindre à l’overlay (après l'expiration de leur temps
hors ligne), et ainsi de suite jusqu'à la fin de l'expérience. Les données présentées
ultérieurement sont recueillies par les opérations liées aux ressources, à savoir publier et
recherche, une base de données est utilisée pour enregistrer les indexes de ressources déjà
publié dans l’overlay. Après que le propriétaire d'une ressource laisse l’overlay, l’index de
ressource sera retiré de la base de données après le temps en ligne (monline).
Pour l'opération de recherche, les nœuds seulement regardent les objets de ressources à
partir de la base de données pour effectuer la mesure du taux de succès. Les auteurs utilisent
l'algorithme MD5 pour générer les ID de nœud et des identifiants de ressource qui ont tous
avec longueur de 128 bits.
2.1.2. Résultats de l’expérience Pour rendre l'évaluation plus claire, ils ont utilisé les notations suivantes et leurs valeurs
sélectionnées, comme le montre Le tableau 4.1, sauf le cas où ils mentionnent le contraire.
Notations Signification et les valeurs sélectionnées
tpublish intervalle de publie une Ressource =100s
trepublish intervalle de republie une Ressource =60s
tlookup Temps d’Intervalle de recherche d’un ressource =125s
texchange Intervalle de changé la table de routage =60s
nexchange Nombre des indexes de routage inclus dans un exchange {10..15}
nparallel degré de Parallélisme de recherche= {1,2 ou 3}
nreplication degré de réplication de ressources= {1,2 ou 3}
monline Durée de l’abonnement(en ligne) = {200…4000}
kvalue Nombre de bucket (zone de kademlia)={1,2,3,4,5}
Rsuccess taux de réussite de la recherche
Tableau 3.1 : Notations et leur signification.
Chapitre 3 Influence des paramètres DHT sur la performance des protocoles
45
2.1.2.1. Effets de nexchange sur le taux de réussite
Tout d'abord, ils ont évalué l'effet de nexchange sur le rapport de succès de la
recherche. Les valeurs des autres paramètres sont les mêmes comme il est indiqué dans le
tableau 4.1, tandis que les valeurs de nexchange varient.
Les auteurs ont présenté Le taux de réussite, la charge de trafic réseau, et le nombre de
messages/noued/s en fonction de monline avec les valeurs nparallel = 1; nréplication =1,
Kvalue= 3.
Les auteurs ont conclu que l'il n'y a pas une différence significative entre les deux
taux de réussite (nexchange=10 ou nexchange=15). Le taux de réussite accroit
proportionnellement avec le temps d’abonnement, il est proche de 99% à l’environ de
monline=4000s.
Pour la charge moyen de trafic de réseau et le nombre moyen de messages : le cas de
nexchange =15 a des valeurs légèrement plus élevées que le cas de nexchange = 10. Aussi
que les valeurs accroissement dans les deux scénarios.
2.1.2.2. Effets de kvalue sur le taux de réussite
Dans cette section les auteurs ont montré que, lorsque kvalue = 1, le réseau overlay est
relativement faible au taux de réussite, tandis que dans les autres cas, aucune différence
significative est observée avec kvalue >1.
La raison pour laquelle le cas kvalue = 1 a un taux de réussite beaucoup plus faible est
que : pour assurer un processus de consultation de Kademlia, chaque k (zone) doit contenir au
moins un contact (noeud) avec les autres k,si k=1 et le nœud contact quitte l’overlay après
monline , les hôtes contenant ce nœud dans sa table de routage ne parvient pas à se mettre à
jour.
2.1.2.3. Les effets de la recherche en parallèle sur taux de réussite
Pour observer l'effet du degré de parallélisme sur le rapport de succès, les auteurs ont
fixé le degré de réplication à 1, ce qui signifie que chaque index de ressource est stocké dans
un seul nœud.
Les auteurs ont présenté le taux de réussite par rapport aux différents degrés de
parallélisme (exchange=15, kvalue = 3, nréplication =1)
Ils ont conclu que le taux de réussite est plus élevé si le degré de parallélisme augmente.
2.1.2.4. Les effets de la réplication sur taux de réussite
Dans cette section ils ont présenté l’effet de la réplication sur le rapport de succès, les
auteurs ont fixé le degré de parallélisme à 1.
Les auteurs ont présenté taux de réussite par rapport aux différents degrés de
réplication (exchange=15, kvalue = 3, nparallel =1)
Ils ont conclu que le seul paramètre de réplication ne peut pas aboutir à une
amélioration remarquable pour performances en termes de taux de réussite.
2.1.2.5. Les effets de nparallel et nreplication sur taux de réussite
Les auteurs ont présenté le taux de réussite par rapport aux différents degrés de
parallélisme et différents degrés de réplication (exchange=15, kvalue = 3).
Une bonne amélioration de taux de réussite nécessite une augmentation de deux paramètres,
le paramètre de réplication et le paramètre de la recherche parallèle.
Chapitre 3 Influence des paramètres DHT sur la performance des protocoles
46
2.2. La performance de kademlia en termes de trafic [78] Les auteurs ont mis kademlia dans un niveau de Simulateur discret. L’overlay simulé
est constitué de 1024 nœuds. Le simulateur ne simule pas le taux de transmission de lien ou
de fichiers, toutes les expériences s’impliquent uniquement à la recherche de clé.
Les Nœuds lancent des recherches pour les clés aléatoires à un intervalle moyen de
dix minutes, et les nœuds accèdent et rejoignent l’overlay avec un intervalle moyen d'une
heure. Ce choix du temps permet des nœuds d’effectuer plusieurs recherches par session.
Chaque expérience dure six heures, et les nœuds conservent leur adresse IP et
l'identifiant pour toute la durée de l'expérience.
2.2.1. L'effet de la recherche parallèle
Les auteurs ont montré l'effet de la variation de nombre de la recherche parallèle (α)
sur le temps moyen de la recherche .Un plus grand α diminue le temps de la recherche.
2.2.2. L'effet de l’intervalle de stabilisation
Dans cette section les auteurs montre que l'intervalle de stabilisation de Kademlia a
guère influé sur la latence de la recherche surtout si le trafic >30 b/n/s, mais forte influence
sur le coût de la communication. La stabilisation fait diminuer le nombre d'entrées de table de
routage pointant vers les nœuds morts, et diminuer ainsi le nombre des délais d'expiration lors
de recherches. Contrairement aux recherches parallèles, leur élimination augmente la latence
de la recherche.
3. Évaluation de Pastry [39]
Les auteurs ont présenté les résultats expérimentaux obtenus avec une mise en œuvre
du prototype Pastry. Le logiciel de Pastry a été implémenté en Java. Pour être en mesure
d'effectuer des expériences avec des grands réseaux, ils ont été également mis en œuvre un
environnement de simulation de réseau jusqu'à 100.000.
Toutes les expériences ont été réalisées sur un quad-processeur Compaq AlphaServer
ES40 (500MHz 21264 Alpha CPU) avec 6 Go de mémoire principale, exécutant Tru64
UNIX, version 4.0F. Le logiciel a été implémenté en Java et exécutée à l'aide Java 2 SDK .
Dans toutes les expériences rapportées dans cette littérature, les nœuds pastry ont été
configurés pour fonctionner en une seule machine virtuelle Java. Ceci est largement
transparent pour l'implémentation pastry en Java.
L'environnement de la simulation garde les informations entre les nœuds. Les
coordonnées des nœuds sont assignés au hasard dans un l'intervalle donné.
Les auteurs ont réalisé une simulation basée sur un modèle de topologie de réseau plus
réaliste pris à partir de [75].
Un certain nombre de propriétés de pastry sont expérimentalement évaluées.
La première série de résultats démontre la performance de routage pastry. Les auteurs
ont présenté l’effet de nombre des nœuds sur la moyenne de nombre des sauts, les résultats
ont montré que l’augmentation de nombre des nœuds croitre le nombre des sauts.
La deuxième série de résultats démontre le maintien du réseau, tel que le nombre des
entrées dans une table de routage par rapport aux différents niveaux de pastry (level = 0 a 3),
Chapitre 3 Influence des paramètres DHT sur la performance des protocoles
47
La troisième série démontre l’effet de réplication des clés sur le temps de la recherche,
les auteurs ont conclu que le temps de la recherche démunie si le degré de réplication
augmente.
La quatrième série démontre l’état de la table de routage après l’échec de 500 nœuds et
la moyenne de nombre de saut par rapport au nombre des nœuds échoués.
4. Travaux connexes [58] Certain travaux concentrent sur la comparaison entre les différents protocoles comme
la comparaison de Jinyang Li, Jeremy Stribling, Robert Morris, M. Frans Kaashoek and Thomer M.
Gil [58].
La plupart des évaluations et des comparaisons de DHT ont mis l'accent sur le temps
moyen de la recherche réussite ou leur taux d’échec.
Dans cette littérature, la même plateforme a été utilisée que [78] et presque la même
méthodologie expérimentale.
Les auteurs ont fait la comparaison entre kademlia chord , tapestry et kelips [60].
La première série de résultats le taux d'échec de la recherche de toutes les DHTs, par
apport au trafic
La deuxième série de résultats démontre Le temps moyen de la recherche réussite de
toutes les DHTs, par apport au trafic
Parmi les limites de cette étude comparative la limitation de nombre de paramètres de
comparaison, les auteurs ont concentré seulement sur les deux paramètres : le taux d’échec et
le temps moyen de la recherche réussite.
III. Conclusion L’étude mené dans ce chapitre permet de donner l’impression que les systèmes pair-à-
pair structurés restent peut être une meilleure solution pour de nombreux problèmes. Mais il
reste encore le problème de la détermination du protocole le plus optimal dans ce domaine.
La plupart des travaux antérieurs évaluent la performance de différents DHTs
individuellement alors que peu d’autres concentrent sur la comparaison entre les protocoles
avec un nombre limité des paramètres.
Pour cela nous allons faire une étude comparative exhaustive, particulièrement sur les
protocoles Chord, Kademlia et Pastry où ce dernier qui n’a jamais été entamée dans ce genre
d’étude.
Cette étude sera détaillée dans le prochain chapitre avec une discussion sur les
résultats obtenus.
Chapitre 3 Influence des paramètres DHT sur la performance des protocoles
48
Comparaison des performances des DHTs
Chapitre 4 :
Chapitre 4 Comparaison des performances des DHTs
49
I. Introduction
L’étude comparative expérimental entre les DHTs est très difficile dans les
environnements réels, à cause du manque du matériel et d’argent. et aussi le temps perdu
durant cette expérience. Pour cela, la simulation est le moyen le plus efficace, le plus facile et
le moins cher pour réaliser cette tâche. Et aussi elle imite le comportement du réseau au fil du
temps.
En conséquence, la simulation est devenue un outil utile dans les essais et la conception
des grands réseaux constitués de milliers de nœuds. et aussi pour prédire le comportement des
systèmes dans des circonstances différentes.
Les réseaux P2P, comme tous les systèmes, peuvent être simulés sur des ordinateurs
de simulation. Les données générées par la simulation sont ensuite recueillies et analysées.
La simulation permet d'une manière simple d'évaluer le système P2P de dépendance à
l'égard des paramètres d'entrée différents comme le temps d'arrivée et de départ des nœuds et
le nombre de ces derniers.
La manipulation sur un simulateur peut compenser la lacune de manque de
matériel performant.
II. Les simulateurs pair-à-pair existants
Il existe de nombreux simulateurs pour les réseaux pair-à-pair, depuis les simulateurs
de bas niveau comme NS2 [63] jusqu’aux simulateurs les plus spécifiques.
Le tableau ci-dessus présente quelques simulateurs Pair-à-Pair.
Simulateur Avantages Inconvénients
NS2 [63] Grande communauté
d'utilisateurs
bas niveau, ne pas spécifique, peu de travail
pour P2P
P2Psim [61] simple Statistiques limitées, passage à l’échelle :
max 3000 nœuds
Ne pas une visualisation graphique
PeerSim [62] Passage à l’échelle : 106
nœuds en mode cyclique
Réseau physique non modélisé, peu de
documentation sur le mode événement
discret. pas de visualisation graphique
QueryCycle [64] Spécialisé dans les systèmes
d’échange de fichiers,
modélisation de réseau
Mode cyclique, passage à l’échelle : max
20 nœuds
PlanetSim [65] Passage à l’échelle : 105
nœuds
Pas de statistiques, réseau physique non
modélisé
NeuroGrid [66] Passage à l’échelle : 3x105
nœuds
Réseau physique non modélisé, statistiques
limités
3LS [67] Modèle du système,
visualisation de réseau et
statistiques
Passage à l’échelle : <1000 nœuds
P2PRealm [69]
visualisation de réseau et
statistiques
Spécifique aux réseaux de neurones
Chapitre 4 Comparaison des performances des DHTs
50
OverSim [70] Passage à l’échelle 105
nœuds, réseau physique
modélisé, recorde les
statistiques, , visualisation de
réseau et statistiques
Plusieurs DHTs implantés
Chord , Kademlia … etc …..
En cas d’erreur il bloque sans afficher des
Messages d’erreurs
Tableau 4.1 : Avantages et inconvénient de quelques simulateurs des réseaux pair-à-pair
III. Le simulateur Oversim
Dans ce projet, nous allons réaliser nos expérimentations à l'aide de simulateur
Oversim qui utilise comme environnement de simulation la plateforme de simulateur
OMNet++ [71] on intégrant la librairie INET [72] .
Nous présentons dans la suite une vue sur le simulateur OMNet++, le simulateur
Oversim et la librairie INET.
1. L’outil de simulation OMNET++ 1.1. Présentation
OMNet++ (Objective Modular Network Tested in C++) est un outil de simulation
d'événements discrets, il basé sur le langage C++, destiné principalement à simuler les
protocoles réseau et les systèmes distribués. Il est totalement programmable, paramétrable et
modulaire.
OMNet++ est une application open source sous licence GNU (General Public
License) [44], développée par Andras Varga, chercheur à l'université de Budapest dont le
développement a commencé en 1992.
Il contient un éditeur de réseaux qui permet facilement De construction de diverses
topologies de réseau sur un espace de travail.
Omnet++ caractérise par une présentation graphique de réseaux. Il permet aussi de la
configuration et l'observation d'un cycle de simulation, ainsi que l’enregistrement et l'analyse
des outils statistiques d’une façon graphique.
Il est destiné avant tout à un usage académique, est un intermédiaire entre des logiciels
de la simulation destinée principalement à la recherche (NS2) et les simulations
commerciales.
Actuellement, Ce simulateur est utilisé par des dizaines d'université pour la validation
de nouveaux matériels et logiciels, ainsi que pour l'analyse de performance et l'évaluation de
protocoles de communication.
L'avantage de OMNET ++ est sa facilité d'apprentissage, d'intégration de nouveaux
modules et la modification de ceux déjà implémentés.
1.2. L’architecture de OMNet++
Le fonctionnement d’OMNet++ repose entièrement sur l'utilisation de modules qui
communiquent entre eux par le biais de messages.
Chapitre 4 Comparaison des performances des DHTs
51
Ces modules sont organisés hiérarchiquement. Les modules de base sont appelés
module simple (simple module), Ceux-ci sont regroupés en module composé (compound
module). Ces modules composés peuvent eux-mêmes être regroupés en d’autre module
composé. Le nombre de niveau hiérarchique n'est pas limité.
Les feuilles de cette architecture sont les modules simples qui représentent les classes
C++. Pour chaque module simple correspond un fichier .cc et un fichier .h .
Un module composé est composé de simples modules ou d'autres modules composés
connectés entre eux. Les paramètres, les sous modules et les ports de chaque module sont
spécifiés dans un fichier .ned .
La communication entre les différents modules se fait à travers les échanges de
messages. Les messages peuvent représenter des paquets, des trames d'un réseau
informatique, des clients dans une file d'attente ou bien d'autres types d'entités en attente d'un
service. Les messages sont envoyés et reçus à travers des ports qui représentent les interfaces
d'entrer et de sortie pour chaque module.
La conception d'un réseau se fait dans un fichier .ned et les différents paramètres de
chaque module sont spécifiés dans un fichier de configuration ( .ini). OMNet++ génère à la
fin de chaque simulation deux nouveaux fichiers vectory (.vec) et scalars (.sca) qui permettent
de tracer les courbes et calculer les statistiques.
Le package OMNet++ que l'on peut trouver sur le site www.omnetpp.org contient un
éditeur graphique permettant d'éditer facilement des fichiers NED (Network Description).
Le diagramme suivant peut donner une idée plus détaillé sur le développement
d’exécution d’une simulation sous OMNet++.
Figure 4.1 : Exécution d’une simulation sous OMNeT++
2. INET
INET est une librairie open source pour la simulation des réseaux informatiques dans
l'environnement OMNeT++. Elle intègre divers protocoles, tels qu’IPv4, IPv6, TCP, UDP,
RIP, OSPF, des protocoles implémentés, et plusieurs modèles d'application. Elle comprend
également des modèles de PPP, Ethernet et 802.11 de La couche liaison de données.
Le routage statique peut être configuré à l'aide du réseau auto configurateur, ou on
peut utiliser le protocole de routage déjà mise en œuvre.
INET prend en charge les simulations des différents protocoles et les topologies réseau, tels
que filaires, sans fil et ad-hoc.
Chapitre 4 Comparaison des performances des DHTs
52
3. Le simulateur OverSim 3.1. Description
OverSim est un simulateur flexible pour les réseaux overlays, disposant d'une interface
graphique et utilise comme environnement de simulation la plateforme de OMNeT ++ .
OverSim est une application open source, développé à l'Institut de la télématique (groupe de
recherche, Prof Martina Zitterbart), Karlsruhe Institute of Technology (KIT) dans le cadre du
projet ScaleNet [45] financé par le Ministère fédéral allemand de l'éducation et de la
recherche. Ce projet est toujours en cours de développement, la dernière version stable
OverSim-20121206.tgz date du 06 décembre 2012. Il est basé sur un système de simulation
d'événements discrets de communication et de traitement des messages.
Un système de simulation d'événements discrets est un système dans lequel l'état du
système change à des points discrets dans le temps.
OverSim comprend des implémentations de nombreux protocoles pour les réseaux
pair-a-pair structurées et non structurées, telles que Chord , Kademlia , Koorde[52]…ect.
Il fournit également un soutien de visualisation en ayant une interface graphique forte de
l'utilisateur.
3.2. Caractéristiques principales
Parmi les caractéristiques principales d’OverSim :
Flexibilité : Un simulateur doit permettre la simulation des deux réseaux de
recouvrement structurées et non structurées. En raison de la conception modulaire et API
commune, OverSim peut facilement faciliter la mise en œuvre de nouvelles fonctionnalités et
des protocoles. L'utilisateur peut spécifier les paramètres de simulation dans un fichier de
configuration lisible par l’homme.
Evolutivité : OverSim est conçu en fonction des besoins actuels du réseau, en
gardant la performance comme exigence majeure. OverSim peut simuler des réseaux avec un
maximum de 100.000 nœuds
Interchangeables Modèles de réseau sous-jacent : OverSim fournit différents
modèles de réseaux sous-jacents. D'une part, le cadre fournit une topologie de réseau IPv4
entièrement configurable avec des bandes passantes réalistes, des retards de paquets et les
pertes de paquets (INET), et d'autre part fournit un modèle alternatif simple et rapide pour des
performances élevées (Underlay Simple)
GUI interactive : OverSim fournit un support graphique pour la validation et la
mise au point de nouveaux et existants protocoles de recouvrement. OverSim peut visualiser
la structure de la topologie du réseau, les états des nœuds et de communication de messages
entre les nœuds
Classe Overlay de Base : OverSim implémente une classe overlay de base. La
classe facilite la mise en œuvre des protocoles P2P structurés en fournissant une interface
RPC, un mécanisme de recherche générique et une API commune pour le routage à base de
clés KBR (key-based routing) .
Réutilisation du Code Simulation : OverSim fournit des différentes
implémentations de protocoles de recouvrement. Ces protocoles sont réutilisables pour
application réelle des réseaux. OverSim fournit des façons de comparer les résultats de la
simulation avec les résultats des tests de réseau réelles, puisque OverSim est capable
d'échanger des messages avec d'autres implémentations du même protocole d’overlay.
Statistiques : OverSim recueille des données telles que les messages envoyés,
reçus et transmis, la livraison de paquets réussi ou non et le nombre de paquets. Les
programmes externes peuvent afficher cette sortie dans un format facilement lisible.
Chapitre 4 Comparaison des performances des DHTs
53
3.3. Architecture d’OverSim
Ce simulateur est divisé en différentes niveaux d’abstraction sont décrits comme suit :
Niveau Underlay : Comme on a dit précédemment, dans ce niveaux, INET
intègre divers protocoles de couche transport , couche réseaux et de la couche liaison de
données.
Il contient un module décrit dans l’underlay sous le nom de churnGenerator dans
lequel on peut définir et manipuler quelques paramètres d’entrée comme le nombre de
nœuds, Le paramètre de la durée de vie et la durée de la mort du nœud, temps de simulation,
temps de mesure et temps d’échantillonnage …etc
Niveau Overlay : les protocoles P2P existants (Pastry, Chord, Kademlia,
koorde…) sont implantés dans ce niveau.
Ce niveau contient l’essentiel pour le routage de chaque protocole, ils sont inclus dans
le module baseoverlay, on cite quelques paramètres : Type de routage, nombre de colonnes de
table de routage, diamètre maximum, nombre maximum de successeurs, la possibilité d’étende
la table de routage, degré de Parallélisme, intervalle de la stabilisation, Nombre de bucket (zone
de kademlia), nombre de bits dans l’alphabet utilisé, activation de la découvrir et le temps
consacré pour la découvrir…etc
Niveau Application : On distingué dans ce niveau deux couche principales :
o tier1 : contient le module KBRTestAppModules
o tier2 : contient le module DHTTestAppModules
Le choix de ces modules selon les paramètres de sortie désirés, on va présenter les deux
modules ci-suivant.
Figure 4.2 : Architecture d’OverSim détaillé, extrait de [57].
Chapitre 4 Comparaison des performances des DHTs
54
4. Critères de choix
Notre choix du simulateur oversim basé sur les motifs suivants :
répondre particulièrement à nos attentes dans le sens où son architecture fait nettement
la séparation entre les déférents niveaux d’abstraction.
Inclure des implémentations de nombreux protocoles pour les réseaux pair-a-pair
structurées et non structurées.
modifier de ceux déjà implémentés
basé sur un système de simulation d'événements discrets de communication et de
traitement des messages.
modéliser des réseaux physiques
fournir un soutien de visualisation en ayant une interface graphique forte de
l'utilisateur
visualiser de réseau et de statistiques
IV. Environnement de Simulation
Nous allons détailler les outils utilisés dans la réalisation de notre simulation.
1. Environnement matériel
La simulation a été réalisée sur un ordinateur Labtop TOSHIBA dont la configuration
est la suivante :
Processeur Intel Core i5-4200 M CPU 2.50GHz, 2.50GHz
Mémoire 6 Go DDR3
Disque dur 500 Go
Carte graphique Intel HD Graphics 4600
Tableau 4.2 : Configuration de l'ordinateur de développement
2. Environnement logiciel
Notre simulation a été réalisée dans l'environnement logiciel suivant :
Logiciel Version
Système d'exploitation Microsoft Windows 8 ( 64 Bits)
Virtuel machine VMware-workstation-full-10.0.1-1379776
Virtuel système d’exploitation Microsoft Windows 7 ( 32 Bits)
Mémoire dans la machine virtuel 2 Go
Le simulateur OMNet++ 4.4 omnetpp-4.2.2-src-windows
Le simulateur Oversim OverSim-20121206
Inet inet-20111118-src
Tableau 4.3 : l’environnement logiciel de simulation
Chapitre 4 Comparaison des performances des DHTs
55
V. Définition des paramètres
1. Paramètres du fichier default.ini
Le fichier default.ini contient tous les paramètres de configuration d’OverSim et leurs
valeurs par défaut.
Nous avons choisi quelques paramètres que nous trouve intéressants, et ils définissent
les éléments principaux de routage dans un réseau overlay P2P.
Le tableau 4.4 illustre ces paramètres choisis.
Groupe Paramètre Valeur
KBRTestApp
settings
tier1.kbrTestApp.testMsgSize
tier1.kbrTestApp.lookupNodeIds
tier1.kbrTestApp.failureLatency
100B
True
10s
DHT settings tier1.dht.numReplica
tier1.dht.numGetRequests
tier1.dht.ratioIdentical
4
4
0.5 DHTTestApp
settings
tier2.dhtTestApp.testInterval
tier2.dhtTestApp.testTtl
60s
300 Chord settings overlay.chord.stabilizeDelay
overlay.chord.routingType
overlay.chord.successorListSize
overlay.chord.extendedFingerTable
overlay.chord.memorizeFailedSuccessor
20s
" itérative"
8
False
false
kademlia settings overlay.kademlia.lookupParallelPaths
overlay.kademlia.routingType
overlay.kademlia.minSiblingTableRefreshInterval
overlay.kademlia.k
overlay.kademlia.s
overlay.kademlia.b
1
"iterative"
1000s
8
8
1
pastry settings overlay.pastry.bitsPerDigit
overlay.pastry.numberOfLeaves
overlay.pastry.useDiscovery
overlay.pastry.discoveryTimeoutAmount
overlay.pastry.useRoutingTableMaintenance
overlay.pastry.routingTableMaintenanceInterval
overlay.pastry.routingType
4
16
False
1s
False
60s
"iterative"
ChurnGenerator
configuration
churnGenerator.sim-time-limit
churnGenerator.measurementTime
churnGenerator.lifetimeMean
churnGenerator.deadtimeMean
churnGenerator.targetOverlayTerminalNum
1209600s
10000.0s
10000.0s
10000.0s
10
Tableau 4.4 : Quelque Paramètres de default.ini
Chapitre 4 Comparaison des performances des DHTs
56
Paramètre description
tier1.kbrTestApp.testMsgSize
tier1.kbrTestApp.lookupNodeIds
tier1.kbrTestApp.failureLatency
tier1.dht.numReplica
tier1.dht.numGetRequests
tier1.dht.ratioIdentical
tier2.dhtTestApp.testInterval
tier2.dhtTestApp.testTtl
overlay.chord.stabilizeDelay
overlay.chord.routingType
overlay.chord.successorListSize
overlay.chord.extendedFingerTable
overlay.chord.memorizeFailedSuccessor
overlay.kademlia.lookupParallelPaths
overlay.kademlia.routingType
overlay.kademlia.minSiblingTableRefreshInterval
overlay.kademlia.k
overlay.kademlia.s
overlay.kademlia.b
overlay.pastry.bitsPerDigit
overlay.pastry.numberOfLeaves
overlay.pastry.useDiscovery
overlay.pastry.discoveryTimeoutAmount
overlay.pastry.useRoutingTableMaintenance
overlay.pastry.routingTableMaintenanceInterval
overlay.pastry.routingType
churnGenerator.sim-time-limit
churnGenerator.measurementTime
churnGenerator.lifetimeMean
churnGenerator.deadtimeMean
churnGenerator.targetOverlayTerminalNum
churnGenerator. transitionTime
test la taille de message (byte)
activation de recherche noeudid
temps de échouée la requête (second)
degré de réplication
nombre de répliques interrogé
taux de réplication
intervalle de recherche d'un nœud
le nombre TTL (time to live)
intervalle de la stabilisation
type de routage
nombre maximum de successeurs
la possibilité d’étende la table de routage
sauvegardé la trace de noeuds échouées
degré de Parallélisme
type de routage
intervalle de la stabilisation
Nombre de bucket (zone de kademlia)
diamètre maximum
nombre de bits dans l’alphabet utilisé
nombre de bits dans l’alphabet utilisé
nombre de colonnes de table de routage
activation de la découvrir
le temps consacré pour la découvrir
activation de la stabilisation
intervalle de la stabilisation
type de routage
temps de simulation
temps de mesure
durée de vie du nœud
durée de mort du nœud
nombre de nœuds
temps d’échantillonnage
Tableau 4.5 : description de paramétrés OverSim
La stabilisation : la mise à jour de la table de routage (voire chapitre 3)
2. Création des Fichiers de configuration
La bonne simulation et manipulation des paramètres oversim nous obligent à créer un
ou plusieurs fichiers de configuration (.ini), dans notre configuration nous allons créer deux
fichiers sous les noms (config1 et config2) selon les scénarios que nous allons expliquer ci-
suivant.
Chapitre 4 Comparaison des performances des DHTs
57
Les fichiers de configuration doivent contenir la ligne : include ./default.ini
S'il y a des chevauchements dans les paramètres et default.ini et config1ou2.ini le simulateur
prend les valeurs de ces derniers.
include ./default.ini
[Config chordKBR]
description = Chord (iterative, SimpleUnderlayNetwork)
sim-time-limit = 21600s
**.lifetimeMean = 21600s
**.measurementTime = 400s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.chord.ChordModules"
**.tier1Type = "oversim.applications.kbrtestapp.KBRTestAppModules"
**.targetOverlayTerminalNum = 200
[Config ChordDht]
description = Chord DHT (SimpleUnderlayNetwork)
sim-time-limit = 21600s
**.lifetimeMean = 21600s
**.measurementTime = 4000s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.chord.ChordModules"
**.numTiers = 2
**.tier1Type = "oversim.applications.dht.DHTModules"
**.tier2Type = "oversim.tier2.dhttestapp.DHTTestAppModules"
**.targetOverlayTerminalNum = 100
**.tier1*.dht.numReplica = 4
Figure 4.3 : Un échantillon de réglage de fichier de configuration pour une exécution.
3. Les paramètres de la simulation
3.1. Le choix de paramètres et de DHTs
Notre choix de paramètres basé sur trois critères principaux :
les plus reconnus dans la communauté.
Correspondants à notre étude dans les chapitres précédents
Clarifiants les déférences entre les protocoles de routage DHTs en termes de
performance
Nous avons choisis les DHTs chord , Kademlia et Pastry car
couramment utilisé
caractérisés par des mécanismes et des architectures différents tel que :
Chord : architecture en anneau.
Kademlia : Architecture en arborescence.
Pastry : Architecture Maillée De Plaxton .
Chapitre 4 Comparaison des performances des DHTs
58
3.2. Les paramètres d’entrée
Nos résultats sont obtenus via les deux paramètres, le nombre de nœuds dans le réseau
overlay et le temps de rejoint/quitte du noeud. D'autres paramètres sont restés constant à leur
valeur par défaut alors que ces deux ont été modifiées une à la fois.
3.2.1. Le temps de la Simulation
Temps de simulation pour tous les scénarios dépend de ces derniers (jusqu’à 6 heures).
Ce paramètre est décrit dans l’oversim sous le nom : sim-time-limit.
3.2.2. Le nombre de nœuds
Ce paramètre est décrit dans l’oversim sous le nom : targetOverlayTerminalNum
Le paramètre définit le nombre de nœuds participant dans le réseau overlay. La valeur
idéale choisie correspond aux exigences de la simulation logicielle, mais la valeur est égale au
maximum 1000 nœuds selon la puissance de traitement disponible. L'objectif est de simuler
les réseaux larges que possible. Les scénarios ont été réalisés avec les DHTs Kademlia chord
et pastry .la valeur de nombre de nœuds varie entre 200 et 1000.
3.2.3. Le temps de rejoint/quitte le réseau overlay
Ce paramètre est décrit dans l’oversim sous le nom: lifetimeMean et deadtimeMean
Le paramètre définit la valeur moyenne de la durée de vie (lifetimeMean) et la durée
de la mort du nœud (deadtimeMean).
3.3. Les paramètres de sortie
De la sortie de la simulation, il y a plusieurs paramètres, nous sommes
particulièrement intéressés à :
Paramètre de sortie Nom de la variable
la Longueur moyenne du chemin KBRTestApp :one way hop count mean
le taux de succès DHTTestapp:GET Success Ratio.mean
Le nombre moyen de requêtes échouées par
seconde
DHTTestapp:faild GET Requests/s.mean
le temps moyenne de latence de recherche en
secondes
DHTTestapp:GET Latency (s).mean
trafic bytes/seconde
(le nombre moyen des octets reçus par second
+ le nombre moyen des octets émis par second)
/ 2
-----
BaseOverlay:ReceivedTotalBytes/s.mean
BaseOverlay:Sent Total Bytes/s.mean
le nombre moyen d’entrées stockées dans le
DHT
GlobalDHTTestMap : nombre of stord DHT
entries mean
Tableau 4.6 : description de paramétrés de sortie
Chapitre 4 Comparaison des performances des DHTs
59
- Pour le paramètre nombre de sauts, il faut utiliser le module :
KBRTestAppModules (KBR : key-based routing).
tier1Type = "oversim.applications.kbrtestapp.KBRTestAppModules".
- Pour les paramétres de sortie restant, il faut utiliser le module DHTModules puis le
module DHTTestAppModules dans le deuxième tiers.
tier1Type = "oversim.applications.dht.DHTModules"
tier2Type = "oversim.tier2.dhttestapp.DHTTestAppModules"
VI. Les scénarios de la simulation Pour les deux scinarions ci_suivant, on a répété la simulation pour les deux modules
KBRTestAppModules et DHTTestAppModules.
Les valeurs des paramètres utilisées dans les scénarios sont présentées dans les
tableaux 4.7 et 4.8.
1. Premier scénario
Nombre de nœud Temps de rejoint/quitte du nœud (heur)
200 6
400 6
600 6
800 6
1000 6
Tableau 4.7 : première Scenario On a Répété le première scenario pour chaque ’une de ces valeurs avec les trois DHT chord,
kademlia et pastry.
2. Deuxième scénario
Nombre de nœud Temps de rejoint/quitte du nœud (heur)
100 0.5
100 1
100 1.5
100 2
100 2.5
Tableau 4.8 : deuxième Scenario
On a répété aussi le deuxième scenario pour chaque ’une de ces valeurs avec les trois
DHT chord, kademlia et pastry.
Au total 60 opérations de simulation ont été effectuées.
Chapitre 4 Comparaison des performances des DHTs
60
3. Collection des statistiques
Les statistiques sont recueillies à l'aide de l'outil OverSim RECORD_STATS. Les
statistiques recueillies au RECORD_STATS sont automatiquement imprimées à deux fichier
appelés scalars (.sca) et vectory (.vec) .
Les fichiers scalars sont ensuite traités avec MATLAB qui imprime les statistiques de
manière plus lisible.
Figure 4.4 : Présentation graphique d’un exemple de statistique de nombre de sauts d’après
le fichier scalars (.sca)
VII. Résultats et discussion
1. Longueur du chemin
1.1. En fonction de nombre de nœuds et en fonction de temps
rejoint/quitte
Figure 4.5 : La longueur de chemin en fonction de la taille du réseau.
Chapitre 4 Comparaison des performances des DHTs
61
La Figure 4.5 montre que la longueur moyenne du chemin augmente
logarithmiquement avec le nombre de nœuds.
Ainsi que le cas de DHT pastry obtient les plus petites valeurs de la longueur de
chemin, et ça prouve que la longueur maximum de chemin de DHTs Chord et Kademlia est
log2(n) alors que la longueur de chemin de Pastry est log2b(n) car log2(n) >= log2
b(n).
Avec :
o b : nombre de bits dans l’alphabet utilisé (ex : en hexadécimal b=4)
o N : nombre de nœuds
Figure 4.6 : La longueur de chemin en fonction du temps rejoint/quitte du nœud
La Figure 4.6 clarifié qu’il n y ‘a aucun influence du temps rejoint/quitte du nœud sur
La longueur de chemin. Cela prouve l’efficacité d’auto-organisation des protocoles DHTs.
A l’observation de Figure 4.5 et Figure 4.6 on conclut que Pastry c’est le meilleur en
fonction de longueur de chemin par apport Kademlia, alors que chord est classé le dernier.
1.2. La probabilité de nombre de sauts
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).
Chapitre 4 Comparaison des performances des DHTs
62
DHT
Nombre
de sauts
Chord Kademlia Pastry
Nombre
Total
(20s)
probabilité Nombre
Total
(20s)
probabilité Nombre
Total
(20s)
probabilité
1 0 0 0 0.005 13 0.073
2 5 0.025 7 0.037 110 0.625
3 14 0.07 21 0.112 50 0.284
4 40 0.2 61 0.326 0 0
5 53 0.265 44 0.235 1 0.005
6 56 0.28 42 0.224 1 0.005
7 19 0.095 12 0.064 0 0
8 13 0.065 0 0 1 0.005
total 200 1 187 1 176 1
Tableau 4.9 : la probabilité de la longueur du chemin dans le cas d'un réseau overlay
avec 600 nœuds.
Figure 4.8 : la probabilité de la longueur du chemin dans le cas d'un réseau overlay
avec 600 nœuds.
Dans La Figure 4.8 la probabilité de faire deux sauts pour accéder à la cible par Pastry
est supérieur à 60% alors que par Chord et Kademlia est inférieur à 5%, ainsi que la
probabilité de faire quatre sauts par Pastry est presque 0% tandis que par Kademlia est
supérieur à 30%. on remarque aussi que la probabilité de faire six sauts par chord est presque
30%.
Ce qui confirme notre déduction dans les figures précédentes, le meilleur DHT en
fonction de langueur de chemin est respectivement Pastry, Kademlia puis Chord .
Chapitre 4 Comparaison des performances des DHTs
63
2. Taux du succès
Figure 4.9 : Le taux du succès en fonction de la taille du réseau.
Figure 4.9 : montre que Pastry est presque parfait en fonction de taux du succès quel
que soit la taille de réseau overlay, alors que celui de kademlia varie entre 96% et 99.9% au
cours d’évolution de nombre de nœuds mais le taux de succès de chord diminue
proportionnellement inverse avec la taille de réseau overlay.
Nous ne concluons que le DHT Pastry est jugé le plus robuste vis-à-vis évolution de
réseau overlay.
Figure 4.10 : Le taux du succès en fonction du temps rejoint/quitte du nœud.
La Figure 4.10 montre que l’augmentation de temps su rejoint/quitte du nœud croitre
le taux du succès.
Comme a été attendu, les meilleurs résultats celui de Pastry.
Chapitre 4 Comparaison des performances des DHTs
64
3. Temps de latence de la recherche Les faibles latences sont causées par des recherches pour les clés à proximité (dans
l'espace ID) de nœud cible et par les sauts de requête qui restent locaux vers le site physique.
Les percentiles élevés sont causés par des recherches dont les sauts suivent des longs
chemins.
Figure 4.11: le temps moyen de Latence de recherche (seconde) en fonction de la taille
du réseau.
La leçon de la figure 4.11 est que le temps moyen de latence de recherche se
développe lentement par l’augmentation de nombre total des nœuds, ce qui confirme que
tous les DHT sont évolutifs.
Figure 4.12 : le temps moyen de Latence de recherche (seconde) en fonction du temps
rejoint/quitte du nœud.
La figure 4.12 montre que le temps moyen de latence de recherche se diminue avec
l’accroissance du temps rejoint/quitte du nœud.
Nous observons aussi que le temps moyen de Latence de recherche par Pastry est
presque égale à celui de Kademlia notamment si le temps rejoint/quitte >2.5.
On conclut à partir de la figure 4.11 et la figure 4.12 que le meilleur DHT en fonction
de temps de latence de recherche sont Pastry et Kademlia par apport Chord.
Chapitre 4 Comparaison des performances des DHTs
65
4. Le nombre moyen de Requêtes échouées
Dans cette expérience seuls les défaillances causées par l’état d'incohérence de DHT
sont incluses, et pas les échecs en raison de clés perdues.
Figure 4.13 : Le nombre moyen de Requêtes échouées par seconde en fonction de la
taille du réseau.
La Figure 4.13 montre qu'il y a un nombre important de requêtes échouées dans le
réseau overlay de DHT chord, ce nombre croît avec l’évolution de la taille de réseau, alors
que kademlia et pastry restent stable avec des petites valeurs malgré l’accroissance de
nombres de nœuds.
Figure 4.14 : Le nombre moyen de Requêtes échouées par seconde en fonction du
temps rejoint/quitte du nœud.
A partir de La Figure 4.14 : tant que le temps du rejoint/quitte du nœud diminue alors
le nombre de requêtes échouées croissent et vice versa.
La Figure 4.13 et la Figure 4.14 affirment que le DHT Pastry a prouvé son efficacité
contre les échecs des requêtes, alors que kademlia son efficacité est évidente si le temps de
rejoint/quitte du nœud est assez grand.
Chapitre 4 Comparaison des performances des DHTs
66
5. Le Trafic (bytes/s)
Figure 4.15 : Le nombre moyen d’octets par seconde en fonction de la taille du réseau.
La figure 4.15 illustre que kademlia caractérise par un trafic massif qui augmente
proportionnellement avec la taille de réseau jusqu’à environs de 600 nœuds puis il se stabilise,
contrairement au pastry qui se stabilise à partir de 400 nœuds, alors que chord augment
lentement au cours de l’évolution de réseau avec un trafic de petites valeurs.
Figure 4.16 : Le nombre moyen d’octets par seconde en fonction du temps
rejoint/quitte du nœud.
Dans Figure 4.16 : nous observons que le trafic de chord est toujours faible et stable
quel que soit le temps du rejoint/quitte alors que kademlia et pastry sont proportionnellement
inverse avec le temps du rejoint/quitte.
Nous concluons à partir de Figure 4.15 et Figure 4.16 que le DHT chord est le meilleur
en fonction de trafic.
Chapitre 4 Comparaison des performances des DHTs
67
6. Nombre d’entrées stockées dans le DHT Les entrés stockées dans le DHT sont les clés stockés dans les nœuds d’un réseau
overlay.
Figure 4.17 : Le nombre moyen d’entrés stockées dans le DHT en fonction de la taille
du réseau.
Figure 4.17 clarifie que le nombre moyen des clés stockées dans le DHT est presque
égale à 4 fois le nombre de nœuds pour tous les DHTs, et il augmente linéairement avec le
croissance du nombre de nœuds.
Cela prouve qu’il y a un équilibrage de la charge dans tous les DHTs étudiés.
Figure 4.18 : Le nombre moyen d’entrés stockées dans le DHT en fonction du temps
rejoint/quitte du nœud.
Figure 4.18 montre que le nombre des clés stockées augmente lentement avec la
croissance du temps rejoint/quitte du nœud, presque il n’y a aucune influence du temps
rejoint/quitte sur le nombre d’entrées stockées dans le DHT.
Chapitre 4 Comparaison des performances des DHTs
68
VIII. Conclusion
Les résultats présentés dans ce chapitre ont montré que le protocole Pastry est efficace
dans la majorité des cas, le DHT chord est plus efficace seulement en fonction de trafic, alors
que le protocole kademlia est caractérisé par sa position moyenne entre Pastry et Chord en
termes de performance dans la plus part des cas.
Cela prouve que l'utilisation de la recherche heuristique est efficace car le DHT pastry
utilise ce genre de recherche.
69
Conclusion Générale
Conclusion Générale
Les réseaux pair-a-pair, structurées ou non structurées, ont été globalement Reconnus
comme une solution viable pour la mise en œuvre de divers applications distribués.
Ce type de réseaux est plus répandu dans les centres de données de sites Web très
populaires tels que Facebook, bien que les applications Pair-a-Pair soient très appréciées dans
nos jours.
Les produits existants et les projets de recherche indiquent que le système pair-à-pair
structuré est une technologie qu’a une valeur très importante en pratique. Elle aide à
surmonter l'évolutivité et les problèmes de performances rencontrés par de nombreuses
technologies pair-à-pair non structurées.
Ce mémoire donne un aperçu de plusieurs représentants structurés des systèmes pair-
à-pair, et une analyse des principaux aspects qui influent sur la performance d'un système
pair-à-pair, ainsi que il présente une simulation d’un réseau P2P structuré pour mieux
comprendre les facteurs responsables du changement de performance en utilisant trois
protocoles largement utilisé Kademlia, Chord et Pastry. L’objectif le plus important était de
faire la comparaison entre eux. L'effet de plusieurs paramètres d'entrée dans la simulation
nous donne une vue globale sur les majors facteurs responsables de la baisse ou
l’augmentation des performances. il nous donne aussi un aperçu sur la réalité.
Les scénarios de la simulation ont été construits avec le simulateur OverSim après une
comparaison entre les simulateurs des réseaux pair-à-pair existant. On a constaté que le
meilleur simulateur est OverSim, ce dernier est un simulateur open source très détaillé donne
des bonnes résultats malgré que OverSim ne peut pas être maîtrisé dans une courte période.
Les résultats ont montré que Pastry est efficace dans la majorité des cas, mais
seulement en fonction de trafic le DHT Chord est plus efficace, alors que Kademlia
caractérise par sa position moyenne entre Pastry et Chord en termes de performance dans la
plus part des cas, cela prouve que l'utilisation de la recherche heuristique est efficace car le
DHT Pastry utilise ce genre de recherche.
Nous croyons que les systèmes pair-à-pair structurés restent peut être une solution
meilleure pour de nombreux problèmes. Certaines questions ouvertes n’ont pas encore été
abordés et restent comme perspectives de recherche dans ce domaine, comme
l'interopérabilité entre les différents réseaux Pair-to-Pair qui est probablement, l'un des plus
difficiles questions a résoudre, La communauté de l'Internet fait des efforts pour combler cette
lacune existante.
Bien qu'il existe de nombreuses solutions relatives à l’interopérabilité, Néanmoins,
aucune solution n'a été sérieusement envisagée pour permettre l'interopérabilité entre les
différents réseaux.
Il y a aussi d’autres questions de recherches ouvertes, tels que des nouveaux
algorithmes de recherche, des cadres pratiques et nouvelles applications.
Bibliographie
70
Bibliographie
[1]. Marguerite Fayçal. Thèse doctorat : Routage Efficace pour les Réseaux Pair-a-Pair
utilisant des Tables de Hachage Distribuées. École Doctorale d’Informatique,
Télécommunications et Électronique de Paris. 2010.
[2]. Guillaume Doyen . Thèse doctorat : Supervision des réseaux et services pair à pair. Ecole
doctorale IAEM Lorraine. 2005
[3].Bickson, D .The eMule protocol specification. eMule project. 2009. homepage :
http://www.emule-project.net
[4]. Leibowitz, N.Ripeanu, M.Wierzbicki, A. Deconstructing the Kazaa network. Proceedings
the Third IEEE Workshop on Internet Applications. WIAPP 2003
[5]Bram Cohen. The BitTorrent Protocol Specification. 2009. homepage : http://bittorrent.org
[6]. ICQ(I Seek You) Initial release November 15, 1996..Homepage :
https://icq.com/windows/en
[7]. Microsoft Skype Division. Première version août 2003. Homepage :
http://www.skype.com
[8]. Huazhong University of Science and Technology.homepage : http://www.pplive.com/en/
[9]. Anderson, David P.Cobb, Jeff , Korpela, Eric , Lebofsky, Matt , Werthimer, Dan.
SETI@home: an experiment in public-resource computing. Communications of the ACM.
2002.
[10]. C. Shirky. Peer-to-peer : Harnessing the Power of Disruptive Technologies, chapter
Listeningto Napster, pages 21–37. O’Reilly & Associates, Inc., 2001.
[11]. R. Schollmeier. A definition of peer-to-peer networking for the classification of peer-to-
peer architecture and applications. In Proceedings of the 1st International Conference on Peer-
to-Peer Computing - P2P’01, pages 101–102. IEEE Computer Society, 2001.
[12]. S. Androutsellis-Theotokis and D. Spinellis. A survey of peer-to-peer content
distribution technologies. ACM Computing Surveys, 36(4) :335–371, December 2004.
[13]. C. Partridge . Mail routing and the domain system (DNS) . RFC 974part of STD 10 .
Obsoleted by RFC 2821 . January 1986
[14]. Dallons Q. (2003) JXTA: Un Framework Peer-to-Peer Open Source. Namur : Institut
d’Informatique FUNDP, 18 p.
[15]. L. Olson. .NET P2P : Writing peer-to-peer networked apps with the microsoft .NET
framework. MSDN Magazine, 16(2), February 2001.
[16]. Clark I., Sandberg O., Willey B., Hong T.W. (2000) Freenet: A distributed anonymous
information storage and retrieval system. In: Designing Privacy Enhancing Technologies:
International Workshop on Design Issues in Anonymity and Unobservability, July 25-26,
Berkeley, California, États-Unis. International Computer Science Institute (ICSI), pp. 311–
320
[17] . Lotus Notes inventor Ray Ozzie. Groove Networks. homepage: http://www.groove.net
[18]. J. Miller. Peer-to-peer : Harnessing the Power of Disruptive Technologies, chapter
Jabber .Conversational Technologies, pages 77–88. O’Reilly & Associates, Inc., 2001.
Bibliographie
71
[19] . J. Davies, T. Manion, R. Rao, J. Miller, and X. Zhang. Introduction to Windows Peer-
to-Peer Networking. Microsoft Corporation, July 2004. Homepage : http
://www.microsoft.com/technet/prodtechnol/winxppro/deploy/p2pintro.mspx
[20]. E. Adar and B. Huberman. Free riding on gnutella. First Monday, 5(10), 2000.
[21]. F. Dabek, M.F. Kaashoek, D. Karger, R. Morris, and I. Stoica. Wide-area cooperative
storage with CFS. In Proceedings of the 18th ACM Symposium on Operating Systems
Principles - SOSP’01, pages 202–215. ACM Press, 2001.
[22]. P. Druschel and A. Rowstron. Past : A large-scale, persistent peer-to-peer storage utility.
In Proceedings of the 8th IEEE workshop on Hot Topics in Operating Systems – HotOS VIII,
pages 75–80. IEEE Computer Society, 2001.
[23]. J. Kubiatowicz, D. Bindel, Y. Chen, P. Eaton, D. Geels, R. Gummadi, S. Rhea, H.
Weatherspoon, W.Weimer, C.Wells, and B. Zhao. Oceanstore : An architecture for global-
scale persistent storage. SIGARCH Computer Architecture News, 28(5) :190–201, 2000.
[24] Liang, Jian Kumar, Rakesh Ross, Keith W. The FastTrack overlay: A measurement
study. Computer Networks. 2006
[25]. D. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja, J. Pruyne, B. Richard, S. Rollins,
and Z. Xu. Peer-to-peer computing. Technical Report HPL-2002-57, HP Laboratories, 2002.
[26]. S. Saroiu, P. K. Gummadi, and S. D. Gribble. A measurement study of peer-to-peer file
sharing systems. In M. G. Kienzle and P. J. Shenoy, editors, Proceedings of Multimedia
Computing and Networking 2002 - MMCN’02, volume 4673. SPIE, 2002.
[27]. S. Milgram. The small world problem. Psychology Today, 2 :60–67, 1967.
[28]. Zhao B. Y., Kubiatowicz J. D., Joseph A. D. (2001) Tapestry: An infrastructure for
fault-tolerant wide-area location and routing. In Tech. Report No. UCB/CSD-01-1141,
Computer Science Division (EECS), University of California at Berkeley, California 94720,
USA.
[29]. Andersen D. G., Balakrishnan H., Kaashoek F., Morris R. (2001) Resilient Overlay
Networks. In: 18th Symposium on Operating Systems Principles (SOSP), Oct 21-24, Banff,
Canada. ACM Press, pp.131–145
[30]. B. Kantor and P. Lapsley. Network News Transfer Protocol. Internet Engineering Task
Force, February 1986. RFC 977 (Proposed Standard).
[31]. G. Malkin. RIP Version 2. Internet Engineering Task Force, November 1998. RFC 2453
(Standard).
[32]. R. Dingledine, M. J. Freedman, and D. Molnar. The free haven project : Distributed
anonymous storage service. In H. Federrath, editor, Proceedings of the International
Workshop on Design Issues in Anonymity and Unobservability, number 2009 in LNCS,
pages 67–95. Springer-Verlag, 2000.
[33]. M. Waldman, A. Rubin, and L. Faith Cranor. Publius : A robust, tamper-evident,
censorship-resistant, web publishing system. In Proc. 9th USENIX Security Symposium,
pages 59–72, August 2000.
[34]. M. K. Reiter and A. D. Rubin. Crowds : anonymity for web transactions. ACM Transac-
tions on Information and System Security, 1(1) :66–92, 1998.
[35]. M. Rennhard. MorphMix – A Peer-to-Peer-based System for Anonymous Internet
Access. PhD thesis, TIK – ETH Zurich – Switzerland, 2004.
Bibliographie
72
[36]. M. J. Freedman and R. Morris. Tarzan : A peer-to-peer anonymizing network layer. In
Proceedings of the 9th ACM Conference on Computer and Communications Security -
CCS’02, 2002.
[37]. Sushant Jain,Ratul Mahajan,David Wetherall.A study of the performance potential of
DHT-based overlays.Published in:Proceeding USITS'03 Proceedings of the 4th conference on
USENIX Symposium on Internet Technologies and Systems - Volume 4 Pages 11-11
USENIX Association Berkeley, CA, USA .2003
[38]. Stoica I., Morris R., Liben-Nowell D., Karger D. R., Kaashoek M. F., Dabek F.,
Balakrishnan H. (2001) Chord: A Scalable Peer-topeer Lookup Protocol for Internet
Applications. In: Proceedings of SIGCOMM. ACM Press, pp. 149–160
[39]. Rowstron A., Druschel P. (2001) Pastry: Scalable, decentralized object location and
routing for large-scale peer-to-peer systems. In: IFIP/ACM Middleware. Springer Verlag,
number 2218 in LNCS
[40]. Ratnasamy S. P., Francis P., Handley M., Karp R., Shenker S. (2001) A scalable
content-addressable network. In: Proceedings of ACM Special Interest Group on Data
Communication (SIGCOMM), Aug, San Diego, CA, US, pp. 161–172.
[41]. Maymounkov P., Mazières D. (2002) Kademlia: A peer-to-peer information system
based on the XOR metric. In: 1st International Workshop on Peer-to-Peer Systems (IPTPS),
Mar 07-08, Cambridge, Massachusetts, États-Unis. Springer Verlag, number 2429 in LNCS,
2002, pp.53–65
[42]. Malkhi D., Naor M., Ratajczak D. (2002) Viceroy: A Scalable and Dynamic Emulation
of the Butterfly. In: Proceedings of PODC. ACMPress, New York.
[43]. Kumar A., Merugu S., Xu J., Yu X. (2003) Ulysses: A Robust, Low- Diameter Low-
Latency Peer-to-Peer Network. In: 11th International Conference on Network Protocols
(ICNP), Nov 04-07, Atlanta, Georgia, États-Unis. IEEE Communications Society, pp. 258–
267.
[44]. Franklin St, Fifth Floor. Licence publique générale GNU, version 1. February 1989.
Homepage : http://www.gnu.org/licenses/old-licenses/gpl-1.0.html [45]. Prof. Martina
Zitterbart and our groupe. Flexible and Converged Access Networks (SCALENET). Institut
für Telematik – KIT.
[46]. Ajmani S., Clarke D. E., Moh C., Richman S. (2002) ConChord : Cooperative SDSI
certificate storage and name resolution. In: 1st International Workshop on Peer-to-Peer
Systems (IPTPS), Mar 07- 08, Cambridge, Massachusetts, États-Unis. Springer Verlag,
number 2429 in LNCS, pp. 141–154
[47]. Cox R., Muthitacharoen A., Morris R. (2002) Serving DNS using Chord. In: 1st
International Workshop on Peer-to-Peer Systems (IPTPS’02), Mar 07-08, Cambridge,
Massachusetts, États-Unis. Springer Verlag, number 2429 in LNCS, pp. 155–165
[48]. Plaxton C., Rajaram R., Richa A. (1997) Accessing Nearby Copies of Replicated
Objects in a Distributed Environment. In: 9th ACM Symposium on Parallel Algorithms and
Architectures (SPAA), Jun 23-25, Newport, Rhode Island, États-Unis. ACM Press, pp. 311–
320
[49]. Zhou F., Zhuang L., Zhao B. Y., Huang L., Joseph A. D., Kubiatowicz J. (2003)
Approximate Object Location and Spam Filtering on Peer-to-peer Systems. In: 4th
International Middleware Conference (Middleware), Jun 16-20, Rio de Janeiro, Brésil. ACM
Bibliographie
73
Press, pp. 01–20
[50]. Rowstron A., Kermarrec A.-M., Castro M., Druschel P. (2001)SCRIBE: The design of a
large-scale event notificationinfrastructure. In: 3rd International Workshop on Networked
GroupCommunications (NGC), Nov 07-09, Londres, Royaume-Uni. UCL,pp. 30–43
[51]. Cox L. P., Murray C. D., Noble B. D. (2002) Pastiche: making backup cheap and easy.
ACM Special Interest Group On Operating Systems (SIGOPS) Oper. Syst. Rev., 36(SI):285–
298
[52]. Kaashoek M. F., Karger D. R. (2003) Koorde: A simple degreeoptimal distributed hash
table. In: 2nd International Workshop on Peer-to-Peer Systems (IPTPS), Feb 20-21, Berkeley,
California, États-Unis. Springer Verlag, number 2735 in LNCS, 2003, pp. 98–107
[53]. Napster. Northeastern University. JANUARY, 1999 .homepage :
http://www.napster.com
[54]. Fraigniaud P., Gauron P. (2006) D2B: a de Bruijn Based Content- Addressable Network.
Theoretical Computer Science 355(1):65–79
[55]. M. Ripeanu. Peer-to-peer architecture case study : Gnutella network. Technical Report
TR-2001-26, Department of Computer Science - University of Chicago, 2001.25-29,
Karlsruhe, Allemagne. ACM Press, pp. 395–406
[56]. P. Fraigniaud and P. Gauron. The content-addressable network D2B. Technical Report
TR-LRI-1349, Laboratoire de Recherche en Informatique - Universit´e Paris-Sud, 2003.
[57] . Jamie Furness, Mario Kolberg, Marwan Fayed. An Evaluation of Chord and Pastry
Models in OverSim. University of Stirling. publications on ResearchGate, novembre 2013
[58] Jinyang Li, Jeremy Stribling, Robert Morris, M. Frans Kaashoek and Thomer M. Gil.A
performance vs. cost framework for evaluating DHT design tradeoffs under churn.MIT
Computer Science and Artificial Intelligence Laboratory.2005
[59] Toby VelteAnthony VelteRobert Elsenpeter. Book: Cloud Computing, A Practical
Approach. McGraw-Hill, Inc. New York, NY, USA ©2010 ISBN:0071626948
9780071626941
[60] Idnranil Gupta, Ken Birman, Prakash Linga, Al Demers, and Robbert van Renesse.
Kelips: Building an efficient and stable P2P DHT through increased memory and background
overhead. In Proceedings of the Second IPTPS, 2003.
[61]. P2Psim a simultor for peer to peer protocols. Homepage :
https://pdos.csail.mit.edu/archive/p2psim/
[62]. PeerSim : a simultor for peer to peer protocols. Homepage :
http://sourceforge.net/projects/peersim
[63]. NS2 : a simultor for peer to peer protocols. http://www.isi.edu/nsnam/ns
[64]. QueryCycle : a simultor for peer to peer protocols. Homepage :
http://p2p.stanford.edu/docs/qcsim/runtime/Simulator.html
[65] Planetsim : a simultor for peer to peer protocols. Homepage :
http://ants.etse.urv.es/planetsim
[66] Neurogrid : a simultor for peer to peer protocols.
http://sourceforge.net/projects/neurogrid
[67]. Nyik San Ting, Ralph Deters. 3LS - A Peer-to-Peer Network Simulator. University of
Saskatchewan. Proceedings of the Third International Conference on Peer-to-Peer Computing
(P2P’03). IEEE 2003.
Bibliographie
74
[68]. M. A. Jovanovic, F. S. Annexstein, and K. A. Berman. Scalability issues in large peer-
to-peer networks : A case study of gnutella. Technical report, University of Cincinnati, 2001.
[69]. N. Kotilainen, M. Vapa , T. Keltanen , A. Auvinen . P2PRealm - peer-to-peer network
simulator. 11th International Workshop on Computer-Aided Modeling, Analysis and Design
of Communication Links and Networks. IEEE 2006.
[70]. I Baumgart, B Heep, S Krause. OverSim: A Flexible Overlay Network Simulation
Framework. Global Internet Symposium IEEE 2007.
[71]. OMNeT++ Manual. https://omnetpp.org/doc/omnetpp/UserGuide.pdf
[72]. INET Framework for OMNeT++ Manual. https://omnetpp.org/doc/inet/api-current/inet-
manual-draft.pdf
[73] . Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, "Handling Churn in a DHT", In
Proceedings of the USENIX Annual Technical Conference, pp. 127-140, June 2004.
[74]. Miguel Castro1, Peter Druschel2, Ayalvadi Ganesh1, Antony Rowstron1 and Dan
Wallach2. Secure routing for structured peer-to-peer overlay networks OSDI '02 Paper
Pp. 299-314 of the Proceedings
[75]. E. Zegura, K. Calvert, and S. Bhattacharjee. How to model an internetwork. In
INFOCOM96, San Francisco, CA, 1996.
[76]. Zhonghong Ou , Erkki Harjula , Otso Kassinen , Mika Ylianttila . Performance
evaluation of a Kademlia-based communication-oriented P2P system under
churn..elsevier.2010.
[77]. K. Pawlikowski, H.-D.J. Jeong, J.-S. Ruth Lee, On credibility of simulation studies of
telecommunication networks, in: IEEE Communications Magazine, January 2002.
[78]. Jinyang Li, Jeremy Stribling, Thomer M. Gil, Robert Morris, M. Frans Kaashoek.
Comparing the performance of distributed hash tables under churn. MIT Computer Science
and Artificial Intelligence Laboratory.2005
Annexes
Annexes
A : Les fichiers de configuration
Config 1: Module DHTTestApp
1. nombre de nœuds varie entre 200 et 1000
(au-dessous échantillon de nombre de nœuds 200)
[Config Pastrydht200]
description = Pastry (SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.lifetimeMean = 21600s
**.measurementTime = 400s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.pastry.PastryModules"
**.enableNewLeafs = false
**.numTiers = 2
**.tier1Type = "oversim.applications.dht.DHTModules"
**.tier2Type = "oversim.tier2.dhttestapp.DHTTestAppModules"
**.globalObserver.globalFunctions[0].functionType = "oversim.tier2.dhttestapp.GlobalDhtTestMap"
**.globalObserver.numGlobalFunctions = 1
**.targetOverlayTerminalNum = 200
**.measureNetwInitPhase = false
**.useCommonAPIforward = true
**.neighborCache.enableNeighborCache = true
**.initPhaseCreationInterval = 0.1s
**.debugOutput = false
**.drawOverlayTopology = true
**.tier1*.dht.numReplica = 4
[Config ChordDht200]
description = Chord DHT (SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.lifetimeMean = 21600s
**.measurementTime = 400s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.chord.ChordModules"
**.numTiers = 2
**.tier1Type = "oversim.applications.dht.DHTModules"
**.tier2Type = "oversim.tier2.dhttestapp.DHTTestAppModules"
**.globalObserver.globalFunctions[0].functionType = "oversim.tier2.dhttestapp.GlobalDhtTestMap"
**.globalObserver.numGlobalFunctions = 1
**.targetOverlayTerminalNum = 200
**.initPhaseCreationInterval = 0.1s
**.debugOutput = false
**.drawOverlayTopology = true
**.tier1*.dht.numReplica = 4
[Config KADDht200]
description = Kademlia (SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.overlayType = "oversim.overlay.kademlia.KademliaModules"
**.lifetimeMean = 21600s
**.measurementTime = 400s
Annexes
**.transitionTime = 100s
**.numTiers = 2
**.tier1Type = "oversim.applications.dht.DHTModules"
**.tier2Type = "oversim.tier2.dhttestapp.DHTTestAppModules"
**.globalObserver.globalFunctions[0].functionType = "oversim.tier2.dhttestapp.GlobalDhtTestMap"
**.globalObserver.numGlobalFunctions = 1
**.targetOverlayTerminalNum = 200
**.initPhaseCreationInterval = 0.1s
**.debugOutput = false
**.drawOverlayTopology = true
**.tier1*.dht.numReplica = 4
2. temps rejoint/quitte varie entre 0.5 heure et 2.5 heure
(au-dessous échantillon de temps rejoint/quitte 2.5 heurs << 9000 seconde >> )
[Config Pastry25]
description = Pastry (SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.lifetimeMean = 9000s
**.deadtimeMean = 9000s
**.measurementTime = 9000s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.pastry.PastryModules"
**.enableNewLeafs = false
**.numTiers = 2
**.tier1Type = "oversim.applications.dht.DHTModules"
**.tier2Type = "oversim.tier2.dhttestapp.DHTTestAppModules"
**.globalObserver.globalFunctions[0].functionType =
"oversim.tier2.dhttestapp.GlobalDhtTestMap"
**.globalObserver.numGlobalFunctions = 1
**.targetOverlayTerminalNum = 100
**.measureNetwInitPhase = false
**.useCommonAPIforward = true
**.neighborCache.enableNeighborCache = true
**.initPhaseCreationInterval = 0.1s
**.debugOutput = false
**.drawOverlayTopology = true
**.tier1*.dht.numReplica = 4
[Config Chord25]
description = Chord DHT (SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.lifetimeMean = 9000s
**.deadtimeMean = 9000s
**.measurementTime = 9000s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.chord.ChordModules"
**.numTiers = 2
**.tier1Type = "oversim.applications.dht.DHTModules"
**.tier2Type = "oversim.tier2.dhttestapp.DHTTestAppModules"
Annexes
**.globalObserver.globalFunctions[0].functionType =
"oversim.tier2.dhttestapp.GlobalDhtTestMap"
**.globalObserver.numGlobalFunctions = 1
**.targetOverlayTerminalNum = 100
**.initPhaseCreationInterval = 0.1s
**.debugOutput = false
**.drawOverlayTopology = true
**.tier1*.dht.numReplica = 4
[Config kad25]
description = Kademlia (SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.overlayType = "oversim.overlay.kademlia.KademliaModules"
**.lifetimeMean = 9000s
**.deadtimeMean = 9000s
**.measurementTime = 9000s
**.transitionTime = 100s
**.numTiers = 2
**.tier1Type = "oversim.applications.dht.DHTModules"
**.tier2Type = "oversim.tier2.dhttestapp.DHTTestAppModules"
**.globalObserver.globalFunctions[0].functionType =
"oversim.tier2.dhttestapp.GlobalDhtTestMap"
**.globalObserver.numGlobalFunctions = 1
**.targetOverlayTerminalNum = 100
**.initPhaseCreationInterval = 0.1s
**.debugOutput = false
**.drawOverlayTopology = true
**.tier1*.dht.numReplica = 4
Annexes
Config 2: Module KBRTestApp
1. nombre de nœuds varie entre 200 et 1000
(au-dessous échantillon de nombre de nœuds 600)
[Config Pastrycount600]
description = Pastry (SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.lifetimeMean = 21600s
**.measurementTime = 400s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.pastry.PastryModules"
**.enableNewLeafs = false
**.tier1Type = "oversim.applications.kbrtestapp.KBRTestAppModules"
**.targetOverlayTerminalNum = 600
**.measureNetwInitPhase = false
**.useCommonAPIforward = true
**.neighborCache.enableNeighborCache = true
[Config chordcount600]
description = Chord (iterative, SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.lifetimeMean = 21600s
**.measurementTime = 400s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.chord.ChordModules"
**.tier1Type = "oversim.applications.kbrtestapp.KBRTestAppModules"
**.targetOverlayTerminalNum = 600
[Config Kademliacount600]
description = Kademlia (SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.lifetimeMean = 21600s
**.measurementTime = 400s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.kademlia.KademliaModules"
**.tier1Type = "oversim.applications.kbrtestapp.KBRTestAppModules"
**.targetOverlayTerminalNum = 600
2. temps rejoint/quitte varie entre 0.5 heure et 2.5 heure
(au-dessous échantillon de temps rejoint/quitte 2 heurs << 7200 seconde >>)
[Config Pastrycount7200]
description = Pastry (SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.lifetimeMean = 7200s
**.deadtimeMean = 7200s
Annexes
**.measurementTime = 9000s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.pastry.PastryModules"
**.enableNewLeafs = false
**.tier1Type = "oversim.applications.kbrtestapp.KBRTestAppModules"
**.targetOverlayTerminalNum = 100
**.measureNetwInitPhase = false
**.useCommonAPIforward = true
**.neighborCache.enableNeighborCache = true
[Config chordcount7200]
description = Chord (iterative, SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.lifetimeMean = 7200s
**.deadtimeMean = 7200s
**.measurementTime = 9000s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.chord.ChordModules"
**.tier1Type = "oversim.applications.kbrtestapp.KBRTestAppModules"
**.targetOverlayTerminalNum = 100
[Config Kademliacount7200]
description = Kademlia (SimpleUnderlayNetwork)
sim-time-limit = 21600s
*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"
**.lifetimeMean = 7200s
**.deadtimeMean = 7200s
**.measurementTime = 9000s
**.transitionTime = 100s
**.overlayType = "oversim.overlay.kademlia.KademliaModules"
**.tier1Type = "oversim.applications.kbrtestapp.KBRTestAppModules"
**.targetOverlayTerminalNum = 100
Annexes
B : Les statistiques des fichiers scalars
1. Longueur du chemin/ Nombre de nœuds
200 400 600 800 1000
Chord 4.486 5.045 5.360 5.561 5.688
Kademlia 3.316 4.102 4.414 4.553 4.750
Pastry 1.948 2.186 2.328 2.481 2.543
2. Longueur du chemin/ temps rejoint/quitte
0.5 1 1.5 2 2.5
Chord 4.051 4.085 4.103 4.066 4.128
Kademlia 3.162 3.165 3.211 3.215 3.235
Pastry 1.970 1.874 1.848 1.831 1.827
3. Taux du succès/ Nombre de nœuds
200 400 600 800 1000
Chord 0.979 0.958 0.966 0.947 0.949
Kademlia 0.997 0.999 0.976 0.997 0.994
Pastry 0.998 0.997 0.997 0.997 0.998
4. Taux du succès/ temps rejoint/quitte
0.5 1 1.5 2 2.5
Chord 0.800 0.899 0.930 0.947 0.964
Kademlia 0.648 0.795 0.881 0.896 0.954
Pastry 0.984 0.991 0.996 0.995 0.996
5. Temps de latence de la recherche/ Nombre de nœuds
200 400 600 800 1000
Chord 0.998 1.150 1.195 1.235 1.241
Kademlia 0.438 0.459 0.516 0.512 0.535
Pastry 0.512 0.526 0.523 0.536 0.538
6. Temps de latence de la recherche / temps rejoint/quitte
0.5 1 1.5 2 2.5
Chord 1.098 0.929 0.906 0.870 0.829
Kademlia 1.462 0.963 0.688 0.665 0.551
Pastry 0.702 0.624 0.595 0.545 0.532
7. Le nombre moyen de Requêtes échouées/s/ Nombre de nœuds
200 400 600 800 1000
Chord 0.00033 0.00066 0.00052 0.00080 0.00078
Kademlia 0.00003 0.00001 0.00036 0.00003 0.00009
Pastry 0.00002 0.00004 0.00003 0.00004 0.00002
8. Le nombre moyen de Requêtes échouées/ temps rejoint/quitte
0.5 1 1.5 2 2.5
Chord 0.0028 0.0015 0.0011 0.0008 0.0005
Kademlia 0.005 0.0031 0.0018 0.0016 0.0007
Pastry 0.0002 0.0001 0.00001 0.00001 0.00001
Annexes
9. le nombre moyen des octets reçus par second / Nombre de nœuds
200 400 600 800 1000
Chord 131.39 138.93 143.61 146.04 149.70
Kademlia 139.95 187.61 241.91 233.79 250.56
Pastry 97.11 153.57 153.76 156.155 160.295
10. le nombre moyen des octets émis par second/ Nombre de nœuds
200 400 600 800 1000
Chord 131.40 138.99 143.47 146.15 150.06
Kademlia 136.18 179.63 215.37 226.48 241.00
Pastry 96.82 148.90 149.14 152.23 153.96
11. Le Trafic (bytes/s) / Nombre de nœuds
200 400 600 800 1000
Chord 131.39 138.36 143.54 146.09 149.88
Kademlia 138.13 183.62 228.64 230.13 232.31
Pastry 96.96 151.23 151.45 154.19 157.12
12. le nombre moyen des octets reçus par second / temps rejoint/quitte
0.5 1 1.5 2 2.5
Chord 133.858 126.947 128.505 124.954 124.412
Kademlia 242.668 160.280 140.794 130.220 118.544
Pastry 430.626 214.114 165.103 153.837 138.380
13. le nombre moyen des octets émis par second / temps rejoint/quitte
0.5 1 1.5 2 2.5
Chord 134.502 126.635 125.599 124.408 125.021
Kademlia 565.848 270.832 188.856 161.712 125.970
Pastry 439.859 220.140 169.331 153.80 140.282
14. Le Trafic (bytes/s) / temps rejoint/quitte
0.5 1 1.5 2 2.5
Chord 134.18 126.81 127.052 124.670 124.81
Kademlia 404.258 215.556 164.826 145.966 122.257
Pastry 435.242 217.137 167.215 153.82 193.330
15. Nombre d’entrées stockées dans le DHT/ / Nombre de nœuds
200 400 600 800 1000
Chord 792.45 1616.38 2468.53 3245.30 4080.30
Kademlia 798.25 1621.25 2473.90 3260.90 4092.20
Pastry 799.025 1619.20 2466.73 3269.35 4092.38
16. Nombre d’entrées stockées dans le DHT/ temps rejoint/quitte
0.5 1 1.5 2 2.5
Chord 496.649 516.640 529.190 537.654 545.141
Kademlia 507.212 531.961 526.954 546.144 546.314
Pastry 491.612 507.539 536.744 536.713 526.931
Annexes
C : Les statistiques des fichiers vectorys
Les fichiers victorys concernés : chordcount600-0.vec Kademliacount600-0.vec
Pastrycount600-0.vec
probabilité de longueur de chemin (600 nœud , 720s jusqu’à 740s)
DHT
Nombre
de sauts
Chord Kademlia Pastry Nombre
Total
(20s)
probabilité Nombre
Total
(20s)
probabilité Nombre
Total
(20s)
probabilité
1 0 0 0 0.005 13 0.073
2 5 0.025 7 0.037 110 0.625
3 14 0.07 21 0.112 50 0.284
4 40 0.2 61 0.326 0 0
5 53 0.265 44 0.235 1 0.005
6 56 0.28 42 0.224 1 0.005
7 19 0.095 12 0.064 0 0
8 13 0.065 0 0 1 0.005
total 200 1 187 1 176 1
Top Related