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

République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université de Larbi Tébessi –Tébessa-

Faculté des Sciences Exactes et des Sciences de la Nature et de la Vie

Département : des mathématiques et informatique

MEMOIRE DE MASTER

Domaine: Informatique

Filière: Informatique

Option: Sécurité et réseaux

Thème:

Présenté par:

Brakni Tahar

Bentahar Atef

Devant le jury :

Mahmoudi Rachid M.A Université Tébessa Président

Abdelghafour Azzeddine M.A Université Tébessa Rapporteur

Ghrieb Nawel M.A Université Tébessa Examinateur

Date de soutenance: 29/05/2016

Note : ……..Mention :………..………………

Les protocoles de routage

dans les réseaux pair-à-pair

ملخص

هذه تحتوي. العنكبوتية الشبكة يسمى ما او 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.2. Routage dans Tapestry 29

2.1.3. Applications basées sur Tapestry 29

2.2. La table de hachage distribuée Pastry 29


2.2.2. Le routage dans Pastry 30

2.2.3. L’Arrivée et le départ d’un nœud 31

2.2.4. Applications basées sur Pastry 32

3. Architecture Torique 32

3.1. La table de hachage distribuée CAN 32


3.1.2. Arrivée d’un nœud 33

3.1.3. Départ d’un nœud 33

3.1.4. Le routage 34

4. Architecture en arborescence 34

4.1. La table de hachage distribuée Kademlia 35


4.1.2. Description 35

4.1.3. Localisation d’un nœud dans le réseau 35

4.1.4. Distance entre deux nœuds : métrique XOR 37

4.1.5. L’arrivée et le départ d’un nœud 37

4.1.6. Applications basées sur Kademlia 37

5. Architecture en papillon 37

5.1. La table de hachage distribuée Viceroy 37

5.2. La table de hachage distribuée Ulysses 38

IV. Comparaison Et Analyse 38

V. Conclusion 39

Chapitre 3 : Influence des paramètres DHT sur la performance des protocoles

III

I. Introduction 41

II. Etat de l’art 41

1. Évaluation de Chord 41

1.1. Le type de Protocole implémenté 41

1.2. L’équilibrage de la charge 41

1.3. Longueur du chemin 42

1.4. Échec des nœuds simultanément 42

1.5. La recherche des ressources au cours de stabilisation 42

1.6. L’expérience pratique sur l’Internet 43

2. Évaluation de Kademlia 43

2.1. Les effets de paramètres DHT 43

2.1.1. Méthodologie expérimentale 43

2.1.2. Résultats de l’expérience 44

2.1.2.1. Effets de nexchange sur le taux de réussite 45

2.1.2.2. Effets de kvalue sur le taux de réussite 45

2.1.2.3. Les effets de la recherche en parallèle sur taux de réussite 45

2.1.2.4. Les effets de la réplication sur taux de réussite 45

2.1.2.5. Les effets de nparallel et nreplication sur taux de réussit 45

2.2. La performance de kademlia en termes de trafic 46

2.2.1. L'effet de la recherche parallèle 46

2.2.2. L'effet de l’intervalle de stabilisation 46

3. Évaluation de Pastry 46

III. Travaux connexes 47

IV. Conclusion 47

Chapitre 4 : Comparaison des performances des DHTs

I. Introduction 49

II. Les simulateurs pair-à-pair existants 49

III. Le simulateur OverSim 50

1. L’outil de simulation OMNET++ 50

1.1. Présentation 50

1.2. L’architecture de OMNet++ 50

2. INET 51

3. Le simulateur OverSim 52

3.1. Description 52

3.2. Caractéristiques principales 52

3.3. Architecture d’OverSim 53

4. Critères de choix 54

IV. Environnement de Simulation 54

1. Environnement matériel 54

2. Environnement logiciel 54

V. Définition des paramètres 55

1. Paramètres du fichier default.ini 55

2. Création des Fichiers de configuration 56

3. Les paramètres de la simulation 57

3.1. Le choix de paramètres et de DHTs 57

3.2. Les paramètres d’entrée 58

IV

3.2.1. Le temps de la Simulation 58

3.2.2. Le nombre de nœuds 58

3.2.3. Le temps de rejoint/quitte le réseau overlay 58

3.3. Les paramètres de sortie 58

VI. Les scénarios de la simulation 59

1. Premier scénario 59

2. Deuxième scénario 59

3. Collection des statistiques 59

VII. Résultats et discussion 60

1. Longueur du chemin 60

1.1. En fonction de nombre de nœuds et en fonction de temps

rejoint/quitte

60

1.2. La probabilité de nombre de sauts 61

2. Taux du succès 63

3. Temps de latence de la recherche 64

4. Le nombre moyen de Requêtes échouées 65

5. Le Trafic (bytes/s) 66

6. Nombre d’entrées stockées dans le DHT 67

VIII. Conclusion 68

Conclusion Générale 69

Bibliographie 70

Annexes

V

Liste des tableaux

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


5

Définition 3 : « Peer-to-peer systems are distributed systems consisting of

interconnected nodes able to self-organize into network topologies with the purpose of

sharing resources such as content, CPU cycles, storage and bandwidth, capable of adapting

to failures and accommodating transient populations of nodes while maintaining acceptable

connectivity and performance, without requiring the intermediation or support of a global

centralized server or authority » [12].

Ces définitions différentes introduisent plusieurs concepts généraux qui sont :

Le partage des ressources (définitions 1, 2 et 3).

Le caractère dynamique des participants (définitions 1 et 3)

La capacité à s’auto-organiser (définitions 1 et 3).

L’absence d’élément central (définitions 1, 2 et 3).

De notre côté, la définition du modèle P2P que nous adoptons fait l’abstraction de ces

concepts:

« Le Système P2P est une architecture d'applications distribuées qui partitionne les

tâches ou les charges de travail entre les nœuds. Ces derniers sont équi-privilégiés et

participent de façon équivalente dans l'application. »

Ces nœuds interconnectés et auto-organisés capables de distribuer les ressources en

topologies de réseau dans le but de les adapter à des défaillances et accueillir d'autres nœuds.

Les pairs font partie de leurs ressources, telles que la puissance de traitement, le

stockage sur disque ou la bande passante du réseau, ces ressources sont directement

accessibles aux autres participants du réseau sans la nécessité d'une coordination centrale par

les serveurs ou hôtes stables.

L’accès à ces ressources décentralisées signifie le fonctionnement dans un

environnement de connectivité instable dans lequel les adresses IP sont imprévisibles, les

nœuds ont une autonomie importante par rapport à l’architecture client-serveur.

Les pairs sont des fournisseurs et des consommateurs de ressources, contrairement au

modèle client-serveur classique dans lequel la consommation et la fourniture sont séparées.

Ces systèmes P2P révèlent la collaboration de telle façon que tous les participants

partagent les ressources, et recherchent divers pairs qui peuvent apporter d'autres ressources

.ainsi un tel système livre des plus grandes tâches relativement à ceux qui peuvent être

accomplies par les pairs individuels qui sont bénéfiques pour tous les pairs.

III. Domaines d’application des systèmes pair-à-pair

Actuellement, on distingue quatre grands domaines d’applications couverts par le

modèle P2P. Nous les avons représentés sur la figure 1.1 qui les classifie. Il s’agit des :

Plateformes de développement (JXTA [14], .net My Services [15])

Partage et distribution de contenu (Napster, Gnutella, Freenet [16] Publius [33], Free

Haven[32])

Collaboration et communication ( Groove[17], Jabber[18]).

Calcul distribué (seti@home)


6

Figure 1.1 : Classification des domaines d’applications P2P

Dans ce qui suit, nous présentons chacun d’eux :

1. Les plates-formes de développement

Les applications de partage de fichiers qui ont popularisé le modèle P2P ont aussi mis

en évidence un besoin fort d’interopérabilité pour ce type d’application. C’est pourquoi,

plusieurs propositions de plates-formes génériques de développement qui permettent cette

interopérabilité ont vu le jour. Celles-ci permettent aux développeurs d’applications de

s’abstraire des mécanismes de bas niveau du modèle P2P et de proposer des applications

toutes construites sur les mêmes fondements.

Jxta, est l’une des premières propositions de plate-forme générique et est actuellement

une des plus complètes et déployées. Microsoft, de son côté propose deux infrastructures pour

le développement des applications P2P. Le premier est une extension de la plate-forme de

développement de services web .NET qui présente une manière d’intégrer des services P2P a

cette infrastructure. Cette proposition s’apparente plus à l’adaptation d’une plate-forme

initialement dédiée à un fonctionnement centralisé plutôt qu’a une véritable proposition de

plate-forme qui intègre les mécanismes de base du modèle P2P. La seconde proposition

s’appelle Windows P2P [19] et propose un ensemble de mécanismes utilisables par les

concepteurs d’applications Windows pour développer des services P2P.

2. Le partage et la distribution de contenu

Le modèle P2P connaıt son succès actuel grâce aux applications de partage de fichiers.

Initié par Napster , ce type d’application consiste à créer des communautés de pairs qui

partagent des fichiers qui sont stockés sur leur machine. Les protocoles et implantations

d’applications de partage de fichiers sont nombreux. Parmi les plus connues, on trouve

Gnutella, , Kazaa, Emule, Bit-Torrent . Souvent aucune interopérabilité n’existe entre celles-

ci. Pour pallier ce problème, on trouve maintenant des applications qui implantent plusieurs

protocoles et permettent aux usagers de se connecter à plusieurs communautés, augmentant

ainsi le volume de données accessibles.


7

Un des principaux problèmes mis en évidence par les applications de partage de

fichiers concerne le free riding [20], un comportement qui consiste à télécharger des données

sans en partager aucune. Pour le résoudre, les applications de partage de fichiers les plus

récentes mettent en place des mécanismes apparentés à l’autogestion. Les principaux reposent

sur un classement régulier des pairs qui dépend de leur comportement : les pairs les plus

stables, fiables et généreux vont ainsi voir leurs recherches de données être traitées plus

efficacement et pouvoir télécharger plus de données, plus rapidement.

Le second type d’application relatif aux fichiers et à leur accès par le biais du modèle

P2P concerne le stockage de fichiers. On trouve plusieurs applications telles que CFS [21],

PAST [22] ou OceanStore [23] qui sont toutes construites sur des tables de hachage

distribuées et qui proposent de construire un système de fichiers de type Unix qui soit

distribué parmi une communauté de pairs. L’objectif est de fournir un service similaire à NFS

(Network File System) qui ne nécessite aucune architecture centralisée.

3. La collaboration

Les applications P2P collaboratives proposent à des communautés d’usagers des

services de communication et d’échange de données. Différents moyens de communiquer sont

souvent offerts, avec notamment le chat, la messagerie instantanée, la voix et la vidéo par le

biais de la visioconférence ou des webcams. L’échange de données, selon le contexte

d’utilisation, va des photos ou vidéos personnelles aux documents d’un projet de travail. Deux

types d’usagers sont visés par ce type d’application qui sont le particulier et les entreprises.

On trouve aujourd’hui une multitude d’applications qui ciblent ces deux catégories,

avec par exemple Jabber , ICQ ou Skype pour la communication et Groove pour le travail

collaboratif.

4. Le calcul distribué

La possibilité de pouvoir utiliser la puissance de calcul de millions de machines

connectées à l’Internet intéresse fortement les acteurs de la communauté du calcul distribué.

En 1999, l’université de Berkeley lance le projet Seti@Home qui a pour objectif d’analyser

des données transmises par des récepteurs du projet SETI qui écoutent l’univers afin de

détecter une quelconque forme de communication. Etant donné un grand nombre de données

à analyser, l’équipe propose de développer une application assimilable à un économiseur

d’écran qui, lorsque l’ordinateur sur lequel elle est hébergée est inefficace, télécharge un

morceau de données sur un serveur dédié, les analyse et lui retourne le résultat. Cette

application connait un très grand succès et est actuellement utilisé par des milliers

d’utilisateurs, motivés par des classements réguliers de participations et par la possibilité

d’être celui qui aura traité le bloc qui contient un extrait de communication extra-terrestre. En

outre, des clones sont aujourd’hui utilisés dans de nombreux autres domaines. On considère

ainsi Seti@Home comme le précurseur d’une problématique de recherche à part entière qui

concerne la manière de distribuer un calcul sur une infrastructure P2P.


8

IV. Les modèles d’architecture des réseaux Pair-à-Pair

Plusieurs modèles d’architecture P2P existent. D’ordinaire, c’est le degré de

décentralisation qui est retenu pour leur classification, puisque c’est là l’idée de base du P2P.

Ce degré de décentralisation de l’architecture caractérise aussi l’index de référence des

ressources.

La première génération des applications P2P était à architecture centralisée. Une

deuxième génération à architecture décentralisée non structurée a vite vu le jour, suivie par

une troisième génération d’applications à architecture hybride.

Au niveau de l’infrastructure P2P, des protocoles et des architectures décentralisées

structurées se sont développées en parallèle aux applications P2P, à partir de la deuxième

génération.

Nous distinguons donc trois familles d’architectures P2P (figure 1.2) :

L’architecture centralisée.

L’architecture décentralisée, qui peut être structurée ou non structurée.

L’architecture hybride.

Figure 1.2 : Les modèles d’architecture P2P.


9

1. L’architecture centralisée

L’architecture centralisée est caractérisée par un index central pour repérer les

ressources. Cet index reçoit tous les messages de contrôle et toutes les requêtes, mais par la

suite, l’échange se fait directement entre les pairs concernés. C’est ce qui distingue

principalement cette architecture d’une architecture traditionnelle de type client-serveur.

Figure 1.3 : Architecture P2P Centralisée

Ce serveur centralisé ne dispose pas des fichiers. Il contient principalement deux

types d’informations : celles sur le fichier (nom, taille, ...), et celles sur l'utilisateur (nom

utilisé, IP, nombre de fichiers, type de connexion, ...).

Comme toute architecture centralisée, cette architecture facilite la gestion des

différentes ressources de l’index et offre une bonne performance de découverte des ressources

(le coût de localisation des ressources est faible), ainsi que Le confort d'utilisation peut être

amélioré, puisqu'il n'y a pas de soucis de connexion au bon serveur. Cependant la

centralisation représente un goulot d’étranglement au niveau de l’index, tant par la charge de

son utilisation que de sa mise à jour. De plus, au niveau de la sécurité, l’index est le talon

d’Achille de ce type d’architecture et aussi aucun anonymat n'est possible, puisque chaque

utilisateur est identifié sur le serveur. Alors ce type est sensible au partitionnement du réseau

et aux attaques.

L’exemple type d’une telle architecture est Napster (1999-2002) qui a déclenché le

phénomène P2P. Il a aussi été le modèle le plus spectaculaire de la réussite technologique du

P2P.


10

2. L’architecture décentralisée

Dans l’architecture P2P décentralisée, tous les pairs sont fonctionnellement

parfaitement équivalents. C’est un modèle P2P pur (Figure 1.4) Cette architecture est

caractérisée par une décentralisation de l’index, qui devient local à chaque pair, faisant effet

de table de routage. La décentralisation rend le système autonome et répartit la charge

équitablement. L’architecture décentralisée est donc plus robuste que l’architecture

centralisée, mais le temps de découverte des ressources est évidemment plus long.

Figure 1.4 : Architecture P2P décentralisée

On distingue dans ce type d’architecture deux sous catégories :

L’architecture décentralisée non structurée

L’architecture décentralisée structurée.

2.1. Architecture décentralisée non structurée

Une architecture P2P décentralisée [1] est dite non structurée lorsqu’aucune contrainte

topologique n’existe.

Un système P2P à architecture décentralisée est aussi dit : système P2P pur. Aucune

connaissance de la topologie n’est donc disponible au préalable et chaque pair dans le réseau

est autonome. La maintenance et la mise à jour des connexions se font par sondage périodique

du voisinage, et la découverte des ressources se fait par une technique d’inondation associant

un champ TTL (Time To Live) à chaque message de recherche envoyé, afin de comptabiliser

le nombre de retransmissions restantes.

L’architecture décentralisée et non structurée permet de pallier les points faibles de la

centralisation. Elle est simple et flexible, et ne requiert pas des requêtes exactes ou des

demandes de recherches très précises. Néanmoins, cette architecture ne peut pas être gérée

(par un opérateur de réseau ou fournisseur de services). Elle présente aussi certains

inconvénients résultant de l’utilisation de la technique d’inondation et du TTL :


11

La génération d’un nombre important de messages, dont découlent :

o une consommation importante de la bande passante et donc une consommation

des ressources du réseau.

o la visite des pairs par des messages (requêtes ou réponses) non sollicités.

l’absence de garantie de résultat et de connectivité.

un passage à l’échelle assez limité.

L’exemple type d’une architecture P2P décentralisée non structurée est Gnutella dans

sa version initiale, Le TTL y était typiquement fixé à 7. De ce fait, une mise hors réseau

(panne ou déconnexion) d’un nombre aléatoire de pairs scinderait le réseau en deux.

Gnutella est le premier réseau pur pair-à-pair, il succède Napster et son architecture

centralisée jugée vulnérable. Gnutella est un protocole ouvert décentralisé pour des recherches

distribuées sur un ensemble de pairs non hiérarchisés. Tous les utilisateurs sont des «

servent » c'est-à-dire qu’ils jouent le rôle de clients et de serveurs en même temps. A

n’importe quel moment les pairs peuvent se connecter et intégrer le réseau selon certaines

règles, ils n’ont aucune connaissance de la topologie ou de la localisation des données, c’est

pour cette raison qu’un index est créé en local au fur et à mesure. Lorsqu’un pair effectue une

requête, elle est propagée à ses voisins qui la propagent à leur tour aux leurs. Ce mécanisme

qui se base sur la technique de broadcast est appelée « flood », cette approche passe mal à

l’échelle (risque de saturation du réseau). Pour limiter cette surcharge, la requête se voit

attribuer une durée de vie déterminée TTL décrémentée à chaque passage par un pair [1].

2.2. Architecture décentralisée structurée

On parle de réseau décentralisé structuré lorsque la topologie du réseau est connue et

que l’emplacement des données est choisi dans le but d’optimiser les recherches. Les fichiers

sont donc stockés à des emplacements spécifiques. Les pairs sont reliés entre eux selon des

règles bien définies suivant un algorithme de recherche déterministe de telle sorte que pour

une source donnée, correspond un endroit fixé au préalable. L’emplacement est choisi de telle

sorte qu’il soit le plus simple d’accès aux pairs. Ceci permet à n’importe quel pair de se

joindre au réseau ou de le quitter (auto-organisé), Un autre avantage de cette architecture est

la garantie qu’elle offre sur les résultats des requêtes. Cette section sera détaillée dans le

chapitre suivant.

3. Architecture hybride

L’architecture hybride est une architecture décentralisée dont chaque nœud est

l’élément central d’une architecture centralisée. Ces éléments centraux sont des super-pairs

par rapport à l’architecture globale.

Pour une homogénéité entre les super-pairs, c’est souvent le critère de la bande

passante – identifiée suivant le type de connexion (e.g. par modem ou haut débit) qui est pris

en compte. Mais d’autres critères peuvent aussi entrer en jeu, comme la puissance de calcul,

l’espace de stockage, etc. Un nœud peut, avec le temps, à plusieurs reprises gagner et perdre

le statut de super-pair.


12

Figure 1.5 : Architecture P2P Hybride

L’architecture hybride tire avantage simultanément de l’architecture centralisée et de

l’architecture décentralisée. Le nombre de pairs mis en jeu dans la découverte des ressources

est aussi réduit, et avec lui, le trafic global entre les pairs. Ceci permet une économie de bande

passante et facilite le passage à l’échelle.

Un super-pair a cependant les mêmes faiblesses que l’index d’une architecture P2P

centralisée. Une amélioration possible est d’assurer une redondance en choisissant, pour un

même sous-groupe, un ou plusieurs partenaires au super-pair. L’architecture sera dite à super-

pairs redondants.

Des supers-pairs partenaires ont les mêmes connexions aux autres pairs et possèdent

des index identiques de toutes leurs ressources. Pour une répartition de charge équitable entre

les super-pairs partenaires, Chaque Super-Pair réfère une recherche aux autres Super-Pairs. La

recherche est donc plus rapide car elle ne se fait que dans les fichiers indexés par le Super-

Pair auquel on est connecté, les pairs d’un sous-groupe envoient leurs requêtes selon le

principe d’ordonnancement round Robin.

Voici quelques exemples d’applications basées sur un réseau P2P hybride : Gnutella (à

partir de la version 0.6) , FastTrack[24] , eDonkey/eMule , Skype .

Il est à noter que les architectures hybrides et les architectures centralisées sont parfois

regroupées au sein d’une même classe dite architecture à serveurs.

V. Caractéristiques des réseaux pair-a-pair

Le modèle P2P apporte une nouvelle manière de concevoir et mettre en œuvre les

applications réseaux. De par ses caractéristiques intrinsèques, il permet de résoudre certains

problèmes posés par le modèle client-serveur, comme par exemple, la limite du passage à

l’échelle ou le coût important pour l’achat et la maintenance des équipements. Toutefois, il en

induit d’autres, liés par exemple à la sécurité ou la pérennité des ressources.


13

Le tableau 1.1 met en évidence plusieurs différences fondamentales entre les modèles

client-serveur et P2P. D’une manière générale, on constate que le modèle client-serveur est

associé à un fonctionnement, un environnement et des ressources statiques et connues, alors

que le modèle P2P est lié au concept de dynamicité. Dans cette section, nous passons en revue

l’ensemble des caractéristiques que présente le modèle P2P ainsi que les différentes propriétés

qu’elles lui confèrent.

Critère Modèle Client-Serveur Modèle P2P

Gestion Supervisé Auto-organisé

Présence Permanente Ad Hoc

Accès aux ressources Recherche Découverte

Organisation Hiérarchique Distribuée, Equitable

Mobilité Statique Mobile

Disponibilité Dépendante du serveur Indépendante des pairs

Nommage Reposant sur le DNS Indépendant

Modèle de programmation RPC Asynchrone

Tableau 1.1- Extrait de [25]. Comparaison des infrastructures client-serveur et P2P

1. Décentralisation

La décentralisation est la caractéristique du modèle P2P. Elle s’applique à différentes

fonctions et aux trois sous-modèles. Dans le cas du modèle P2P centralisé, seules les

ressources sont décentralisées mais les mécanismes de recherche et de localisation restent

centralisés. Par contre, dans le cas du modèle pur, tout est décentralisé, des ressources aux

mécanismes de découverte, localisation, sécurité, routage, . . . Quelle que soit sa nature, cette

décentralisation confère au modèle P2P un ensemble de propriétés que nous détaillons

maintenant.

1.1. L’équilibre de la charge et du trafic

La première conséquence induite par la décentralisation sur les applications P2P,

concerne l’équilibre de la charge et du trafic. Dans le cas du modèle client-serveur, le serveur

de l’application concentre tout : les données, l’ensemble des mécanismes qui assurent l’accès

à celles-ci et leur manipulation, mais aussi le trafic généré sur le réseau qui héberge le

serveur. Au contraire, le modèle P2P permet de repartir et équilibrer au mieux la charge

induite par l’exécution du service ainsi que le trafic généré sur le réseau.

Pour une ressource particulière, le Pair qui l’héberge agit comme un serveur central.

Une bonne répartition des ressources, nécessitant éventuellement l’utilisation de mécanisme

de dissémination et de duplication, permet d’éviter que le système bascule dans un

fonctionnement client-serveur avec des pairs qui ne sont pas dédiés à cette fonction.


14

1.2. Le passage à l’échelle

Le bon équilibre de la charge et du trafic des services P2P se répercute directement sur

le passage à l’échelle des applications qui, comparativement au modèle client-serveur, s’en

trouve fortement amélioré. Par exemple, les applications P2P de partage de fichiers comptent

un très grand nombre de participants et fonctionnent sans aucun problème. D’après une étude

menée en 2001 [26], Gnutella compte en moyenne dix mille participants simultanés et

OceanStore , une application P2P de stockage de fichiers, permet de gérer 1010 utilisateurs

stockant au total plus de 1014 fichiers.

Le modèle P2P centralisé possède lui aussi un très bon passage à l’échelle car il ne

centralise pas les ressources mais un index de références. Ainsi la charge et le trafic qui lui

sont attribués sont acceptables et permettent un bon passage à l’échelle des applications qui

reposent sur ce modèle. Les deux exemples-phares qui ont révèle cette bonne propriété sont

Napster , qui permit à plusieurs dizaines de milliers d’usagers d’utiliser simultanément son

service, et Seti@Home , une application de calcul distribué qui compte plusieurs milliers

d’utilisateurs simultanés.

1.3. La répartition des coûts

Déployer une infrastructure centralisée de services en réseaux qui puisse prendre en

compte des milliers d’utilisateurs répartis sur tout l’Internet, a un coût qui peut être lourd pour

l’organisation qui la déploie. Ce coût se répartit sur l’ensemble du cycle de vie de

l’infrastructure et comprend la conception, l’achat d’équipements, la mise en œuvre, la

supervision, la maintenance, la formation des usagers, la mise à jour des composants logiciels,

. . . Le modèle P2P permet de réduire fortement ce coût par l’utilisation de machines situées

en bordure de l’Internet. Ces machines appartiennent toutes à des propriétaires différents qui

peuvent être par exemple des particuliers, des universités, des entreprises ou des

administrations et qui sont toutes achetées, mises en œuvre et maintenues par ces différentes

organisations. L’utilisation du modèle P2P permet donc à un fournisseur de service de réduire

fortement les coûts d’équipements et, au-delà de l’aspect financier, de concentrer son action

sur l’aspect logiciel de l’infrastructure qu’il propose.

1.4. La tolérance aux fautes

Dans l’architecture client-serveur la disponibilité d’un service repose intégralement

sur celle du serveur. Si celui-ci s’écroule, le service qu’il fournit devient indisponible. Dans

un contexte P2P, il n’existe potentiellement aucun point central de faute. Si un pair disparait,

le service continuera d’être fourni par ceux qui restent. En d’autres termes, la disponibilité

d’un service n’est plus liée aux pairs mais à la communauté de pairs qui le fournissent.

2. Auto-organisation

L’absence d’´élément central dans les applications P2P nécessite la mise en place de

mécanisme d’auto-organisation qui permettent à une communauté de d´délivrer son service

quels que soient les allers et venues des pairs et la disponibilité des ressources.


15

Cette auto-organisation couvre plusieurs aspects qui peuvent être fonctionnels,

communautaires et topologiques.

2.1. Aspect fonctionnel

Le modèle P2P hybride montre clairement que certains pairs peuvent se charger de

l’exécution de fonctions particulières, segmentant ainsi une communauté en pairs spécialisés.

Jxta est une bonne illustration d’organisation fonctionnelle avec l’utilisation de pairs

minimaux qui sont de simples consommateurs d’une communauté, de pairs simples qui n’ont

pas de rôle particulier, de pairs de rendez-vous qui assurent les fonctions de découverte et de

localisation, et de pairs relais qui s’occupent du routage. En outre, les applications P2P

possèdent souvent la capacité d’assigner ou de supprimer par elles-mêmes les fonctions

attribuées aux pairs pour garantir le bon fonctionnement de son service.

2.2. Aspect communautaire

Ensuite, les applications P2P sont capables de regrouper leurs pairs par centres

d’intérêts communs créant ainsi des communautés qui peuvent elles-mêmes contenir des sous-

communautés. On trouve ce type d’organisation dans les services de communication et

d’échange de données personnelles telles que Jabber qui regroupe les pairs en fonction des

sujets sur lesquels ils souhaitent échanger comme par exemple, le sport, le cinéma ou la

politique.

2.3. Aspect topologique

Le dernier aspect pour lequel les applications P2P proposent des mécanismes

d’organisation concerne la topologie. De manière générale, il existe deux grandes classes de

topologies P2P qui sont les topologies structurées et non structurées. Les topologies

structurées sont construites à l’aide d’un algorithme reposant souvent sur un modèle

mathématique ou un graphe particulier. Les topologies non structurées, quant à elles, ne

respectent aucune règle de construction particulière. Gnutella , dans sa première version 6,

reposait sur une topologie non structurée. On peut néanmoins remarquer que les topologies

non-structurées, du fait des différences de comportement des pairs, peuvent tendre au fil du

temps à s’organiser selon une topologie de type Small World [27], un modèle topologique

comportant quelques nœuds à fort degré de connexion et de nombreux autres à faible degré de

connexion et connectés à ces premiers . La figure 1.6 illustre ce propos avec deux

représentations de topologies Gnutella. La première (figure 1.6 a) montre une topologie non

structurée et la seconde (figure 1.6 b) en montre une autre qui tend à s’organiser selon le

modèle Small World.


16

Figure 1.6 : Topologies Gnutella. (a) Topologie non-structurée. (b) Topologie s’approchant

du modèle Small World. Extrait de [68]

3. Connectivité Ad Hoc

Le modèle P2P se caractérise par une connectivité intermittente des pairs qui le

composent. Cette nature Ad Hoc est principalement due à deux phénomènes. Le premier

concerne le comportement des usagers qui utilisent les services P2P. Les pairs sont en effet

exécutés dans un cadre de travail ou personnel sur des machines d’utilisateurs qui peuvent se

connecter et se déconnecter de manière spontanée et donc imprévisible.

Le second phénomène concerne la mobilité. Les ordinateurs portables munis

d’interfaces de communication sans fil sont de plus en plus courants. Les usagers disposant de

cette technologie ont souvent un comportement nomade, se trouvant certaines fois sur des

sites qui permettent de se connecter à l’Internet, et d’autres fois pas. En outre, la manière dont

ils atteignent une passerelle de connexion varie. Elle peut être directe ou n´nécessiter le

routage des données à travers différents terminaux mobiles qui forment un réseau Ad Hoc.

Cette présence dynamique des pairs se répercute directement sur la disponibilité des

ressources qui se trouve être variable. Pour garantir une bonne disponibilité des ressources

offertes à une communauté, les infrastructures P2P doivent ainsi mettre en place des

mécanismes de duplication et de synchronisation qui peuvent pallier ce problème. En outre,

l’absence d’une ressource ou d’un pair censé être présent ne doit pas être considérée comme

une faute. D’ailleurs, dans Tapestry [28], une infrastructure de routage et de localisation de

ressources, l’absence de réponse d’un pair inscrit dans une table de routage n’entraîne pas son

retrait de la table. L’infrastructure tente de contacter le pair plusieurs fois. Après plusieurs

tentatives, si aucune réponse n’est donnée, le Pair est supprimé de la table mais une référence

est tout de même conservée.


17

4. Un réseau virtuel

Les pairs participant à un service P2P forment souvent un réseau virtuel, appelé

overlay [29] construit au-dessus de la couche transport. Un exemple d’overlay est représenté

sur la figure 2.2 (Voir chapitre 2). Généralement, un tel réseau virtuel présente une propriété

de transparence qui s’applique à plusieurs points. Tout d’abord, il permet de faire abstraction

des différences de nature des pairs.

Une communauté peut être composée de pairs dont les caractéristiques différentes sur

les plans :

matériel : avec par exemple des stations de travail, des téléphones mobiles, des

assistants personnels, ou un cluster de machines.

logiciel : au niveau des systèmes d’exploitation et langages de programmation.

communication : avec l’utilisation de technologies et de piles de protocoles

différentes.

La transparence s’applique aussi sur le routage effectué au niveau sous-jacent , deux

voisins de la topologie virtuelle ne le sont pas forcément physiquement ; ils peuvent être

situés dans des espaces physiques et sur des réseaux différents. L’overlay rend ainsi

transparent le routage effectué au niveau physique. Enfin, concernant les ressources, un

overlay rend transparent leur accès, leur localisation et leur duplication. Lorsqu’un pair

accède à une ressource, il ne sait pas si cette ressource est locale ou distante. Dans le cas où la

ressource est distante, il n’a pas de connaissance de l’hôte qui l’héberge, et si elle est

dupliquée, il ne sait pas à quel réplica il accède.

L’utilisation d’un overlay n´nécessite toutefois la mise en œuvre des mécanismes de

nommage et routage dédiés. Les pairs ne sont donc plus représentés par leur adresse de niveau

transport ou adresse physique mais par un identifiant défini dans le cadre de l’overlay. En

outre, pour pouvoir découvrir et accéder à des ressources, des services de routage, calcul de

routes, découverte et accès sont mis en place.

Remarque :

Un réseau P2P ne constitue pas obligatoirement un overlay [2]. Des applications

reposant sur les protocoles NNTP [30] ou RIP [31] sont construites selon le modèle P2P en

ce sens qu’elles ne présentent aucune centralisation et que chacun de leurs éléments agit

comme un client et un serveur sans pour autant constituer un réseau virtuel au-dessus du

réseau IP.

5. Anonymat

L’anonymat est une fonction qui permet de cacher son identité. Dans le cadre des

systèmes distribués relatifs au partage de documents. L’anonymat est utilisé dans plusieurs

applications qui voient dans le modèle P2P une infrastructure qui se prête particulièrement à

cette fonction. Tout d’abord, Freenet utilise une forme de routage qui garantit l’anonymat du

serveur, de l’auteur et du lecteur en ne permettant à aucun nœud de savoir quelle est la source

et la destination d’une requête. Ensuite, FreeHaven et Publius mettent explicitement en œuvre


18

des mécanismes d’anonymat qui ont pour rôle principal d’assurer la persistance et la

disponibilité de documents dans un environnement soumis à la censure.

Enfin, on trouve maintenant des infrastructures P2P dont le but est simplement de

fournir un service d’anonymat à des applications P2P ou centralisées. Parmi les différentes

propositions, nous en retenons trois qui sont Crowds [34], Morphmix [35] et Tarzan [36] que

nous présentons. Tarzan est une infrastructure qui rend anonyme la couche réseau IP. Pour ce

faire, elle utilise un modèle P2P pur où les pairs forment des tunnels construits de manière

pseudo-aléatoire. La manière dont les tunnels se forment est quasi-impossible à d´détecter et à

compromettre et le trafic qu’ils transportent est crypté. De plus, chaque pair est associé à

quelques autres, appelés mimes, qui vont effectuer les mêmes opérations. Par ce biais, Tarzan

empêche la d´détection de la source d’un message.

VI. Avantages et limites des réseaux pair-à-pair

1. Avantages

Les architectures P2P présentent beaucoup d’avantages parmi eux :

Répartition de la charge :

Contrairement aux réseaux client/serveur où le serveur principal est chargé de gérer

l’ensemble des activités du réseau, d’où un risque de saturation, dans un réseau pair-à-pair, ce

sont tous les pairs qui contribuent à la gestion des différentes requêtes et des ressources

disponibles.

Capacité de stockage décuplée :

Il est à savoir que dans un réseau à serveur central, toutes les données sont stockées au niveau

de ce serveur, ce qui vient en opposition aux réseaux pair où bien que chaque pair n’offre

qu’un petit espace disque (relativement au serveur) la capacité de stockage au sein du réseau

est décuplée grâce à la contribution de tous les pairs.

Puissance de calcul :

Des études avancent que la puissance de calcul utilisée en moyenne par un utilisateur est de

20%, le processeur est donc sous exploité. Certaines applications pair-à-pair développées dans

le domaine de la recherche (Seti@home) visent à se servir de cette puissance inutilisée pour

réaliser des tâches réparties qu’un simple ordinateur ne pourrait accomplir en un temps

raisonnable.

Réseaux très extensibles :

Une particularité des réseaux pair-à-pair est qu’ils sont de nature « Ad-hoc » c’est-à-dire que

des nœuds peuvent apparaître et disparaître à tout moment, cette gestion dynamique des pairs

facilite l’intégration de nouveaux pairs au sein du réseau.

Résistance aux pannes :

Dans un réseau pair-à-pair, les ressources sont réparties sur l’ensemble des utilisateurs

connectés, la panne d’un pair ne peut donc pas altérer le fonctionnement du réseau.

Disponibilité accrue des ressources :

Comme les réseaux pair-à-pair sont extensibles, et que les pairs sont fournisseurs de

ressources au sein du réseau, plus le nombre d’utilisateurs augmente, plus la disponibilité des

ressources présentes augmente.


19

Diversité des chemins dans le réseau :

La topologie logique du réseau pair-à-pair étant maillée, plusieurs chemins de

communication sont possibles entre chaque couple de pairs. De plus, les échanges se font

plus rapidement étant plus directs.

Maintenance et coûts réduits :

Le serveur d’une architecture client/serveur reste très gourmand en matière de ressources,

sa maintenance est très fastidieuse et son coût peut s’avérer très élevé. De ce fait, l’absence

de celui-ci dans les architectures pair-à-pair rend ces réseaux peu coûteux.

Anonymat :

Certains algorithmes de routage ne permettent pas le pistage d’une requête, garantissant

ainsi l’anonymat aux utilisateurs.

Meilleure exploitation de la bande passante :

Dans les réseaux à serveurs centraux, les goulots d’étranglements sont relativement

fréquents au niveau de ces derniers, ce qui paralyse le réseau, ainsi l’absence d’organisme

central dans les réseaux pair-à-pair facilite la circulation des flux, et augmente par

conséquent l’utilisation de la bande passante.

2. Limites

Les réseaux pair-à-pair rencontrent de nombreux problèmes et présentent quelques

inconvénients, on peut citer essentiellement :

Topologie instable :

Les pairs d’un réseau pair-à-pair étant dynamiques, ils peuvent apparaître et disparaître à tout

moment, par conséquent les ressources aussi.

Sécurité :

Nous pouvons citer quelques exemples : Crackers, Virus, Distributed Deny of Service (ddoS),

Confidentialité, Authentification.

Contenu trompeur :

Un des inconvénients majeurs des applications pair-à-pair est que les données circulent

librement dans le système, sans vérification. Certains fichiers peuvent être corrompus :

mauvaise qualité, défectueux, contenu non correspondant à l’intitulé.

QoS (Quality of Service) :

Bien que très utilisées dans d’autres domaines, beaucoup d’applications pair-à-pair sont

employées de nos jours pour le téléchargement souvent illégal de fichiers, ce qui pousse

certains fournisseurs à vouloir limiter au maximum les flux pair-à-pair au sein du réseau. La

bande passante allouée aux applications pair-à-pair est donc considérablement réduite, rendant

ainsi les échanges pair-à-pair très lents.

Loi du Wild Wild Web :

Les applications pair-à-pair sont devenues la cible de plusieurs organismes de protection des

droits d’auteurs et lutte contre les contenus immoraux.

Régulation/Répression :

Certains modèles de réseaux pair-à-pair garantissent l’anonymat aux utilisateurs, il est donc

plus difficile aux autorités d’appliquer les lois.


20

VII. Conclusion

Les systèmes pair-à-pair sont très utiles et ont prouvé leur efficacité durant les

dernières années. Ils sont structurés suivant différents modèles. Ils peuvent être centralisés,

décentralisés ou hybrides. Parmi ces différences entre ces architectures on s’intéresse à la

recherche des ressources c.-à-d. le routage dans les réseaux pair-à-pair.

Ce routage exige des méthodes, des mécanismes de communication, alors il nécessite des

protocoles spécifiques pour implémenter ces mécanismes.

Dans le prochain chapitre on va étudier les protocoles de routage dans les architectures

des réseaux pair-à-pair décentralisées (spécialement pour celles structurées basées sur DHT

(table d’hachage distribuée)) à l’aide des algorithmes spécifiques.

Les protocoles de routage dans un réseau Pair à

Pair décentralisé

Chapitre 2 :

22

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

I. Introduction

Les protocoles d’un réseau pair-à-pair établissent des méthodes et des mécanismes qui

garantissent les communications entre les pairs. Ces protocoles organisent les échanges des

messages et permettent la localisation des pairs, propagation des requêtes, la gestion et le

contrôle de la répartition de fichiers échangés sur tous les nœuds d’un système. Puisque, la

mise en place de ces protocoles génère un trafic d’informations très abondant sur ces réseaux

et les nœuds du réseau peuvent le quitter, ainsi que des nouveaux nœuds peuvent le rejoindre,

il existe de nombreuses architectures, qui utilisent différentes techniques de localisation des

donnés, qui se traduisent par différentes méthodes de routage des requêtes. Les solutions

proposées dans les systèmes décentralisés impliquent la création d’une structure ou non.

Les systèmes pair-à-pair décentralisée sont dite non structurés lorsqu’aucune

contrainte topologique n’existe, ni un répertoire centralisé. Alors chaque pair dans le réseau

est autonome, la découverte des ressources et La maintenance se font par inondation en

interrogeant tous les pairs associant un champ TTL (Time To Live) à chaque message de

recherche jusqu’à l’obtention du pair concerné. Le mécanisme est simple, flexible, et ne

demande pas des requêtes très précises, mais cette architecture ne peut pas être gérée

notamment sur les réseaux à grand échelle, ainsi que l’utilisation de la technique d’inondation

aboutit à une occupation importante de la bande passante, et L’utilisation de TTL est fixé à

un nombre limite, de ce fait une panne ou déconnexion dans un réseau à grand nombre des

pairs peut survenir. Gnutella est un bon exemple de cette architecture également FreeNet

mais ce dernier s’agit d’un pont vers les architectures décentralisées structurées, et il assure

l’anonymat et la permanence des informations qui y résident mais il présent des risques de

sécurité tel que man-in-the-middle ou cheval de Troie.

Les systèmes pair-à-pair décentralisée sont dite structurés lorsque la topologie logique

est imposée par un algorithme bien spécifié qui organise l’espace des pairs et aussi la

répartition des ressources. Ceci permet à n’importe quel pair de s’associer au réseau ou de le

quitter, un tel réseau est nommé « auto-organisé ». Les systèmes structurés garantissent donc

l’efficacité. La gestion des ressources s’appuie fréquemment sur l’utilisation d’une table de

hachage distribuée (DHT).

Puisque Les systèmes pair-à-pair s’orientent progressivement vers les DHT, cette table

sera détaillée dans ce chapitre qui lui est consacrée où différents algorithmes gérant le

routage dans les systèmes DHT seront ainsi présentés.

II. Les Tables de hachage distribuées (DHTs)

1. Définitions

1.1. La fonction de hachage

Une fonction f d’un ensemble E vers un ensemble F est dite injective si :

x, 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


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

https://fr.wikipedia.org/wiki/Structure_de_donn%C3%A9es

24


3. Bilan De DHTs

Une « bonne » implémentation d’une DHT doit gérer efficacement : la recherche,

l’arrivée et le départ d’un nœud, et la mise à jour du contenu d’un nœud.

Les DHTs garantissent :

l’unicité d’identifiant (clé).

la réponse aux requêtes avec un nombre de sauts minimum que possible, surtout si la

donnée cherchée est répliquée. Cela ne concerne pas les sauts physiques (ou sauts IP) mais il

s’agit des sauts logiques..

la faiblesse de degré de connexion : Le degré représente la taille de la table de routage

la réduction de diamètre : Le diamètre est la plus grande distance ; en nombre de

sauts ; entre deux pairs (max log n)

la recherche de chemin le plus court.

L’existence d’un autre chemin vers la destination en cas de panne ou disparition de

pairs

augmentation de performance d'un système et la facilité au passage à l’échelle.

une distribution uniforme des ressources sur l’ensemble des nœuds

L’implémentation de nombreux services qui exploitent la distribution cohérente de

données : Partage de fichiers, Base de données distribuée, chat , et DNS

Il existe de nombreuses implémentations, les algorithmes d’insertion et de recherche

étant différents pour chacun.

Les protocoles de routage dans les réseaux P2P utilisant des DHTs sont dits DHTs

tout simplement. Parmi eux nous en trouvons principalement : Chord [38], Tapestry

Pastry[39], CAN (Content-Addressable Network)[40], Kademlia[41], Viceroy[42] et

ulysses[43] qui seront présentés ci-suivant.

III. Architectures et protocoles pair-à-pair décentralisés et

structurés

1. Architecture en anneau :

L’architecture en anneau est la topologie la plus simple qu’on peut imaginer pour la

première fois et la plus facile à manager. Une DHT à topologie circulaire permet la meilleure

flexibilité et donne les meilleures performances de résilience et de proximité. Dans telle

architecture la proximité est numérique avec un espace d’identification circulaire. Chord est

un bon exemple de type du routage P2P avec un DHT dans une topologie en anneau.

1.1. La table de hachage distribuée Chord

1.1.1. Définition

Les nœuds sont organisés en topologie anneau orientée de 2𝑚 pairs, avec m est le

nombre de bits de la fonction de hachage utilisée (généralement 160 bits).Chaque pair est lié

à un prédécesseur et plusieurs successeurs. Tous les objets ayant le objectId inférieur ou égal

nodeId de pair le plus proche seront stockés dans ce dernier.

25


Un nœud maintient une table de routage vers les nœuds d’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


1.1.2.2. Le routage optimal

Dans le but d’optimiser le routage précédent, il est nécessaire de gérer une table de

routage qui permet une transmission des requêtes bien plus efficaces. Ici on cherche le

successeur de clé k (1<k<m) pour nœud n:

Soit C(k) le premier nœud successeur de (n+ 2 k-1

) mod 2 m

, ( m : le nombre de bits d’une clé).

Si la clé k existe localement, i.e. k appartient à [n, successeur] donc on renvoie la valeur

associée. Sinon on recherche dans la table de routage le nœud avec la plus grande valeur

inférieure ou égale à la clé cherchée.

Figure 2.4 : Routage optimale

En simplifiant le principe, voici un exemple décrivant comment cette utilisation d'un

modèle de petit monde permet de retrouver très rapidement un utilisateur dans un réseau

décentralisé. Supposons que l'utilisateur A soit à la recherche de l'utilisateur B, car il possède

un fichier qu'il recherche. A besoin de l'adresse IP de cet utilisateur, mais ne connaît que sa

clé Key(B) dans le réseau Chord (cette clé seule ne donne pas de route dans le réseau

physique d'Internet). A stocké dans sa mémoire les log(n) nœuds correspondants aux log(n)

liens supplémentaires qu'il a sur l'anneau virtuel. Si B est parmi ces nœuds, alors A retrouve

directement l'adresse de B. Sinon, A va renvoyer sa requête au nœud dont la clé est la plus

proche de Key(B) parmi les log (n) nœuds qu'il a mémorisés.

27


Figure 2.5 : exemple de retrouver très rapidement un utilisateur dans un réseau décentralisé

Chord supporte bien le facteur d'échelle. Différentes simulations ont été menées et

montrent que la longueur moyenne d'un chemin utilisé pour acheminer une requête évolue en

O(log(N)).

1.1.3. L’arrivée et le départ d’un nœud

Lorsqu'un nouveau pair X arrive sur l’overlay, il commence par prendre sa place dans

l'anneau par apport à son nodeId. Puis il envoie un message vers le successeur le plus

proche, ce dernier envoie toutes ses clés inférieures à nodeId de X vers le pair X. alors Les

pairs mettent à jour leurs tables de routage.

Un pair est détecté indisponible lorsque les autres pairs ne peuvent plus communiquer

avec lui .car le pair défaillant a quitté l’overlay ou une panne a été introduite. Alors les autres


1.1.4. Applications Basées Sur Chord

Parmi les applications utilisant Chord comme un réseau de base on en trouve:

o CFS (Collaborative File System) [21] : un système de fichiers distribués à l’échelle de

l’Internet, et où chaque fichier est partagé en blocs ;

o ConChord [46] : une infrastructure distribuée qui utilise CFS et délivre des certificats

de sécurité SDSI (Simple Distributed Security Infrastructure) ;

o Chord-based DNS[47] :qui propose une implémentation P2P du DNS (Domain Name

Service).

28


2. Architecture Maillée De Plaxton

Pour les systèmes distribués statiques un algorithme, dit Plaxton[48], a été développé

en 1997, C’est le premier algorithme destiné aux mailles quelconques applicables avec DHTs.

Il peut donc localiser les objets en utilisant des tables de routage de taille fixe. Les identifiants

des nœuds et des objets se caractérisent par une indépendance totale des sémantiques et ils

sont purement numériques. Chaque nœud est une racine d’un arbre de recouvrement. Le

routage implémenté est hyper-cube, qui se fait par rapprochement successif digit par digit

dans l’identifiant numérique jusqu’à avoir l’objectif. Son fonctionnement peut être basé soit

sur le préfixe comme pastry, soit sur le suffixe comme tapestry

Figure 2.6 : Exemple de suffixe routing

2.1. La table de hachage distribuée Tapestry

2.1.1. Définition

Dans Tapestry, on utilise la fonction de hachage fixée à 160 bits dans un espace

d’identification avec une maille quelconque. L’identifiant de l’objet est désigné par GUID

(Global Unique IDentifier) au lieu d’objectId. Ce noeud racine identifie l’objet de manière

unique. Le routage se fait vers le pair le plus proche numériquement dans le niveau

hiérarchique supérieur, on parle alors de surrogate routing. Durant le routage de pair jusqu’au

sommet des répliques de l’objet avec des différentes clés sont y insérés. Le pair responsable

de l’objet maintien des positions des pairs supports des répliques. Ce routage est basé sur le

suffixe et la recherche récursive.

La figure 2.7 ci-dessous montre exemple sur ce propos.

29


Figure 2.7 : Exemple des niveaux hiérarchiques dans Tapestry (map du noeud 5642)

2.1.2. Routage dans Tapestry

La table de routage dans Tapestry est dimensionnée de b lignes et LogbN colonnes où

b est la base d’identificateur de clé. Chaque colonne représente un niveau de suffixe afin que

des back pointers pointent vers les pairs reconnaissant le pair courant comme l’un de leurs

voisins. Dans chaque ligne, chaque pair pointe vers des pairs voisins de même suffixe, alors la

table de routage contient les pairs les plus proches numériquement.

2.1.3. Applications basées sur Tapestry

Parmi les applications utilisant tapestry comme un réseau de base on en trouve:

o OceanStore : une application de stockage massif.

o SpamWatch [49] : un système collaboratif de filtrage du pourriel.

2.2. La table de hachage distribuée Pastry

2.2.1. Définition

Ce système est purement décentralisé s’inspire de la topologie en anneau de Chord,

mais l’espace d’identification est circulaire non orienté, Les recherches peuvent donc se faire

dans un sens ou dans un autre.

L’identifiant d’un nœud avec une taille de 128 bits est obtenu d’une manière aléatoire

basée sur l’adresse IP ou la clé publique selon l’algorithme désiré en utilisant une fonction

d’hachage fixée à 128 bit, afin de générer des identifiants uniformément distribués sur

l’espace de l’identifiants.

Le routage est garanti par une distinction du nœud dans la table, en présentant le plus

long pré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


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


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.


avec lui .car le pair défaillant a quitté l’overlay ou une panne a été introduite. alors les autres


Figure 2.10 : Exemple de routage dans Pastry

32


2.2.4. Applications basées sur Pastry

Parmi les applications utilisant pastry comme un réseau de base on en trouve:

o SCRIBE [50] : une application de diffusion multi-groupes.

o PAST : un utilitaire de stockage massif.

o PASTICHE [51] : un système de sauvegarde qui exploite les capacités disponibles

des antémémoires réparties dans le réseau.

3. Architecture torique

La DHT propose un exemple basé sur une topologie de tore à d dimensions à

coordonnées cartésiennes. Elle est uniformément partagée en zones. Les objets sont stockés

en points cartésiens de l’espace, Chaque pair est responsable des objets de sa zone.

CAN (Content-Addressable Network) est un exemple type d’une DHT avec une structure

torique.

3.1. La table de hachage distribuée CAN

3.1.1. Définition

La DHT CAN propose un espace vectoriel cartésien multidimensionnel dont chaque

portion de l’espace peut être adoptée par un nœud, et chaque nœud arrange les informations

sur ses voisins directement connectés. Chaque 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


3.1.2. Arrivée d’un nœud

Quand un nouveau nœud rejoint le réseau par l’intermédiaire d’un autre nœud qui

existe déjà dans le système (trouvé par la technique de Boostrapping), il choisit un point P

dans l’espace de coordonnées cartésiennes d’une manière aléatoire, il envoie une requête

JOIN au nœud dont lequel sa zone contient le point P. Cette zone sera subdivisée en deux

parties, l’une des moitiés sera assignée au nouveau nœud. Les deux nœuds mettent à jour les

listes de leurs voisins.

Dans un espace de dimension 2 (Figure2.12), une zone est subdivisée premièrement

suivant l’axe des X, ensuite suivant l’axe des Y.

Figure 2.12 : espace de coordonnées cartésiennes avant que le nœud F arrive

3.1.3. Départ d’un nœud

Quand un nœud quitte le réseau (Figure 2.13), la zone qui été occupée par ce nœud

sera occupée par un de ses voisins. Une mise à jour des listes de voisins est nécessaire pour

ces derniers.

A

B E

C

D

1.0

0.75

0.5

0.0 0.5 0.75 1.0

A

B

C

D

1.0

0.75

0.5

0.0 0.5 0.75 1.0

Les coordonnées cartésiennes

de chaque zone

A( 0.0 - - 0.5 , 0.5 - - 1.0 )

B( 0.0 - - 0.5 , 0.0 - - 0.5 )

C( 0.5 - - 1.0 , 0.75 - - 1.0 )

D( 0.5 - - 1.0 , 0.5 - - 0.75 )

E(0.5 - - 1.0 , 0.0 - - 0.5 )


de chaque zone

A( 0.0 - - 0.5 , 0.5 - - 1.0 )

B( 0.0 - - 0.5 , 0.0 - - 0.5 )

C( 0.5 - - 1.0 , 0.75 - - 1.0 )

D( 0.5 - - 1.0 , 0.5 - - 0.75 )

E(0.5 - - 0.75 , 0.0 - - 0.5 )

F(0.75 - - 1.0 , 0.0 - - 0.5 )

(a) (b)

34


Figure 2.13 : espace de coordonnées cartésiennes avant que le nœud D quitte

3.1.4. Le routage

Chaque table de routage d’un nœud contient l’identifiants des nœuds voisins leurs

adresses IP et leurs coordonnées cartésiennes, alors le routage se fait selon ces coordonnées

pour décider à quelle destination la raquette va être envoyée. Même si un pair intermédiaire

(dans le chemin reliant L et J) quitte le système, il y aura toujours un autre chemin qui relie

ces deux nœuds.

La figure 2.14 illustre un exemple de répartition et de routage dans un réseau CAN de

dimension 2.

4. Architecture en arborescence

L’architecture en arborescence dessine un arbre logique mais il n’y a pas

d’hiérarchisation entre les nœuds alors c’est une topologie plate où les nœuds sont les feuilles

de cet arbre logique. Dans lequel l’espace d’identification est en base 2. Le protocole CAN ,

que nous avons vu plus haut peut être transposé en une arborescence.

A

B E

C

D

1.0

0.75

0.5

0.0 0.5 0.75 1.0

A

B E

C

1.0

0.75

0.5

0.0 0.5 0.75 1.0


de chaque zone

A( 0.0 - - 0.5 , 0.5 - - 1.0 )

B( 0.0 - - 0.5 , 0.0 - - 0.5 )

C( 0.5 - - 1.0 , 0.75 - - 1.0 )

D( 0.5 - - 1.0 , 0.5 - - 0.75 )

E(0.5 - - 0.75 , 0.0 - - 0.5 )

F(0.75 - - 1.0 , 0.0 - - 0.5 )


de chaque zone

A( 0.0 - - 0.5 , 0.5 - - 1.0 )

B( 0.0 - - 0.5 , 0.0 - - 0.5 )

C( 0.5 - - 1.0 , 0.5 - - 1.0 )

E(0.5 - - 0.75 , 0.0 - - 0.5 )

F(0.75 - - 1.0 , 0.0 - - 0.5 )

(a)

(b)

F F

Figure 2.14 : Exemple de routage dans CAN

35


Maintenant nous étudions et analysons Kademlia car ce protocole est un bon exemple

de cette architecture (arborescence) qui a déjà été introduit et fait ses preuves dans le monde

p2p.

4.1. La table de hachage distribuée Kademlia

4.1.1. Définition

Kademlia est un protocole de réseau basé sur les tables de hachages distribuées et la

métrique XOR, il utilise le principe des tables de hachages distribuées pour hiérarchiser et

organiser le réseau en un arbre binaire. La complexité étant alors en Log(n) lors d’une

recherche.

4.1.2. Description

L’un de ces principaux atouts par rapport aux autres systèmes DHT est le nombre

réduit de messages de c configuration à envoyer. En termes de recherche de ses voisins, un

nœud doit être capable de connaitre suffisamment la topologie du réseau pour pouvoir

transmettre ses requêtes avec un temps de latence court. Ce temps de latence reste minime

grâce à l’utilisation du protocole UDP pour l’envoie de tous les messages de configuration et

communication au sein du réseau. De même, les requêtes sont envoyées de façon parallèles et

non synchronisées pour accélérer les temps de transmission et éviter les temps d’attente

venant des nœuds défectueux (timeout).

Chaque nœud du réseau possède un ID propre qui est une clé de 160 bits. Les entrées

de la table de hachage sont également des clés de 160 bits, et sont associées à une valeur, qui

dans notre cas sera une structure, ce qui donne la paire (clé-valeur) comme élément de la

table. Un nœud du réseau ne stocke dans sa table que les paires (clé-valeur) dont la clé est la

plus proche de son ID.

L’autre principal atout de Kademlia réside dans la nouvelle métrique XOR utilisée.

Comme il s’agit d’une métrique symétrique, cela permet aux nœuds de Kademlia de recevoir

les réponses de requêtes depuis exactement le même ensemble de nœud que celui contenu

dans sa table, qui correspond à l’ensemble des nœuds contactés. Sans cette symétrie, les

systèmes comme Chord n’apprennent rien des requêtes reçues concernant la topologie du

réseau. En effet , les nœuds du réseau Kademlia mettent à jour leur table à chaque message

UDP reçu, en stockant si nécessaire les informations relatives au nœud expéditeur.

4.1.3. Localisation d’un nœud dans le réseau

La localisation d’un ID du réseau (ou clé), qui peut représenter une machine connectée

ou bien un fichier, repose sur un unique algorithme de recherche, contrairement à beaucoup

d’autres systèmes DHT. En effet, l’espace des IDs est traité par Kademlia comme un arbre

binaire où chaque nœud du réseau est une feuille, représentée par un unique ID. Si l’arbre

n’est pas complet, il se peut que la recherche d’un ID ne converge pas vers un unique ID,

mais renvoie tous les IDs les plus proches.

Etant donné un nœud, on divise l’arbre binaire en une série de sous arbres ne

contenant pas le nœud en question. Le premier sous arbre obtenu correspond à la moitié de

l’arbre de départ ne contenant pas le nœud. Le suivant est la moitié de l’arbre restant ne

36


contenant pas le nœud, et ainsi de suite. Dans la figure 2.15 on considère le nœud 0111, les

sous arbres obtenus sont entourés dans la figure 2.16. Le protocole Kademlia assure que tous

les nœuds du réseau connaissent au moins un nœud dans chacun de ces sous arbres. Cette

garantie permet à tout nœud du réseau de pouvoir contacter un autre nœud par son ID. La

figure 2.15 montre un exemple de localisation par requêtes successives sur le nœud le plus

proche connu, qui est donc le "meilleur" nœud à contacter (ici le nœud 0111 recherche le

nœud 1101). La figure 2.16 représente un arbre binaire de Kademlia, « joe » est le nœud de

prefixe 0111.

Figure 2.15 : Localiser un nœud par son ID

Figure 2.16 : Arbre binaire de Kademlia

37


4.1.4. Distance entre deux nœuds : métrique XOR

La notion de distance dans le protocole Kademlia repose sur l’opérateur "ou-exclusif

bit à bit". Etant données deux IDs, la distance entre elle vaut : d(x; y) = XOR (binaire(x);

binaire(y)). Les propriétés mathématiques du XOR nous permettent de dire que son résultat

est toujours positif ou nul (seulement si x = y), et surtout, d(x; y) = d(y; x), ce qui garantit la

symétrie de cette métrique. On remarque que cet opérateur permet de récupérer la distance

entre 2 IDs.

4.1.5. L’arrivée et le départ d’un nœud

Lorsqu'un nouveau pair X arrive sur l’overlay, il génère son nodeID, puis il envoie un

message contenant son clé. Lorsqu’un pair reçoit un message, il met à jour le bucket

approprié. Si le noeud expéditeur se trouve déjà dans ce bucket, il est déplacé en bas de la

liste. Sinon, si le bucket n’est pas plein, la nouvelle entrée est insérée. Si le bucket est plein, le

noeud A émet un PING vers le voisin le plus ancien dans ce bucket. Si ce dernier répond au

PING, il est alors déplacé en fin de liste et la nouvelle entrée est ignorée. Kademlia conserve

donc dans sa table les noeuds les plus anciens dans le réseau.


avec lui .car le pair défaillant a quitté l’overlay ou une panne a été introduite. Alors les autres


4.1.6. Applications basées sur Kademlia

Parmi les applications utilisant Kadmelia comme un réseau de base on en trouve:

o BitTorrent

o eMule (sous le nom de Kad)

5. Architecture en papillon

L’architecture est dite papillon (butterfly) si les connexions établies entre les nœuds

du réseau figurent des formes semblables aux papillons. Ce type d’architecture a initialement

été conçu pour les systèmes multiprocesseurs SIMD (Single Instruction Multiple Data).

Viceroy et ulysses sont des protocoles de routage dans un réseau P2P basés sur

l’architecture en question.

5.1. La table de hachage distribuée Viceroy

C’est est un protocole de DHT qui s’insinue de Chord , appliqué à une topologie à

multiples anneaux , dite aussi multi-anneaux. De par l’architecture, chaque pair a une

connectivité (ou degré) constante, c’est à dire un nombre de voisins fixe (typiquement égale à

7), Un niveau consiste en un anneau bidirectionnel.

Chaque pair contient :

o deux pointeurs principaux : reliant les nœuds d’un même niveau (vers le nœud

précédent et le nœud suivant).

38


o deux pointeurs de niveau : vers des nœuds voisins des niveaux supérieur et inférieur

sur l’anneau de référence (généralement celui de niveau 1) .

o trois pointeurs papillon : vers le nœud le plus proche sur le niveau d’indice inférieur

et vers les nœuds à gauche et à droite sur le niveau d’indice supérieur.

À noter que les indices des niveaux vont croissants vers le bas.

Figure 2.17 : Illustration simplifiée de l'architecture de Viceroy,

Extrait de [42]

Le routage avec Viceroy se fait en commençant par le niveau du nœud qui lance sa

requête, puis en remontant jusqu’au niveau supérieur à l’aide des pointeurs de niveau, qui

permettent par la suite d'effectuer la descente en s’approchant de la clé aux niveaux d’indices

inférieurs, et ce récursivement jusqu’à satisfaction de la requête.

5.2. La table de hachage distribuée Ulysses

Ulysses est un autre protocole de routage P2P, il propose une amélioration du graphe

papillon basé sur Viceroy. Le protocole Ulysses ajoute des liens supplémentaires entre les

pairs de niveaux différents. Ces liens servent de raccourcis pour éviter les liens congestionnés

durant le fonctionnement dynamique du réseau afin de garantir un système sans congestion et

avec un trafic réparti équilibré.

IV. Comparaison Et Analyse

Des études comparant les performances théoriques des différentes architectures P2P

décentralisées et structurées ont été effectuées, la plupart de ces études d'évaluation sont

basées sur le degré et le diamètre d’un protocole.

Le tableau 2.1 résume les performances des principaux protocoles présentés

précédemment.

39


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.


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


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.


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.


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.


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),


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.


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


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.


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.


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.

http://www.oversim.org/chrome/site/OverSim-20121206.tgz


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


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


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


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


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


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.


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)






**.numTiers = 2

**.tier1Type = "oversim.applications.dht.DHTModules"

**.tier2Type = "oversim.tier2.dhttestapp.DHTTestAppModules"


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


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


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.


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.


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


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 .


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.


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.


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.


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


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.


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


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.


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.

http://www.emule-project.net/

http://bittorrent.org/

https://icq.com/windows/en

http://www.skype.com/

https://en.wikipedia.org/wiki/Huazhong_University_of_Science_and_Technology

http://www.pplive.com/en/

http://www.groove.net/

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

http://www.gnu.org/licenses/old-licenses/gpl-1.0.html

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.

http://www.napster.com/

https://pdos.csail.mit.edu/archive/p2psim/

http://sourceforge.net/projects/peersim

http://www.isi.edu/nsnam/ns

http://p2p.stanford.edu/docs/qcsim/runtime/Simulator.html

http://ants.etse.urv.es/planetsim

http://sourceforge.net/projects/neurogrid

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

https://omnetpp.org/doc/omnetpp/UserGuide.pdf

https://omnetpp.org/doc/inet/api-current/inet-manual-draft.pdf

https://omnetpp.org/doc/inet/api-current/inet-manual-draft.pdf

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)


*.underlayConfigurator.churnGeneratorTypes = "oversim.common.LifetimeChurn"




**.overlayType = "oversim.overlay.pastry.PastryModules"

**.enableNewLeafs = false

**.numTiers = 2



**.globalObserver.globalFunctions[0].functionType = "oversim.tier2.dhttestapp.GlobalDhtTestMap"

**.globalObserver.numGlobalFunctions = 1


**.measureNetwInitPhase = false

**.useCommonAPIforward = true

**.neighborCache.enableNeighborCache = true

**.initPhaseCreationInterval = 0.1s

**.debugOutput = false

**.drawOverlayTopology = true


[Config ChordDht200]








**.numTiers = 2










[Config KADDht200]

description = Kademlia (SimpleUnderlayNetwork)



**.overlayType = "oversim.overlay.kademlia.KademliaModules"



Annexes


**.numTiers = 2










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]





**.deadtimeMean = 9000s





**.numTiers = 2



**.globalObserver.globalFunctions[0].functionType =

"oversim.tier2.dhttestapp.GlobalDhtTestMap"










[Config Chord25]









**.numTiers = 2



Annexes









[Config kad25]









**.numTiers = 2











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]














[Config chordcount600]










[Config Kademliacount600]










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]






Annexes










[Config chordcount7200]











[Config Kademliacount7200]











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