Thesis Magistere 05

République Algérienne Démocratique et Populaire
Ministère de l’enseignement supérieur et de la recherche scientifique

Université Abderrahmane Mira, Bejaïa
Ecole doctorale d’informatique
Réseaux et Systèmes Distribués (ReSyD)
R eSyD
Thèse de Magister
Option : Réseaux et Systèmes Distribués
Thème
DÉCOUVERTE ET LOCALISATION DE SERVICES

EN MODE P2P
AMAD Mourad
Directeur de thèse : M r . MEDDAHI Ahmed

Co-Directeur de thèse : M r . VANWORMHOUDT Gilles
Soutenu le 05 Novembre 2005 devant le jury :
Président de jury : M r . KERKAR Moussa Professeur

Université de Bejaïa, Algérie
Rapporteur : M r . MEDDAHI Ahmed Maitre de conférences
GET/ENIC TELECOM Lille1, France
Examinateur : M r . VANWORMHOUDT Gilles Maitre de conférences
GET/ENIC TELECOM Lille1, France
r
Examinateur : M . NAIT ABDESSELAM Farid Maitre de conférences
Université Lille1, France
c AMAD Mourad, Novembre 2005

°
ii
A ma mère
A mon père
A mes frères et sœurs
A toute ma famille
A la mémoire de notre collégue Chahine
A tous mes amis
iii
Table des Matières
Table des matières iv
Liste des Tableaux ix
Liste des Algorithmes ix
Table des Figures xi
Remerciements xiii
Résumé xiv
Introduction Générale 1
1 Découverte et localisation de services en mode P2P 4

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Les réseaux peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Les applications Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Les aspects des réseaux P2P . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Les obstacles du réseau P2P . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.4 Les systèmes basés sur la technologie P2P et leurs classifications . . . . 9
1.2.5 Le futur des réseaux P2P . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Réseaux non structurés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 Napster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1.1 La structure de messages Napster . . . . . . . . . . . . . . . . 11
1.3.2 Gnutella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.2.1 La structure de messages Gnutella . . . . . . . . . . . . . . . . 12
1.3.2.2 Les principaux messages utilisés dans le protocole Gnutella . . 12
1.3.2.3 Mécanisme de routage . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2.4 Recherche de données . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2.5 La tolérance aux pannes . . . . . . . . . . . . . . . . . . . . . . 15
1.3.3 Les protocoles probabilistes . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.4 L’algorithme de Plaxton . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Réseaux structurés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1 Le protocole chord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.1.1 Le réseau virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . 18
iv
1.4.1.2 L’identificateur du nœud . . . . . . . . . . . . . . . . . . . . . 18
1.4.1.3 Le hachage consistent (Cohérent) . . . . . . . . . . . . . . . . 19
1.4.1.4 Placement des ressources . . . . . . . . . . . . . . . . . . . . . 20
1.4.1.5 Recherche de données . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.1.6 Exemple de recherche . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.1.7 Tables des raccourcis . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.1.8 Algorithme de recherche avec des tables de raccourcis . . . . . 23
1.4.1.9 Arrivée d’un nœud . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.4.1.10 Construction des tables de raccourcis . . . . . . . . . . . . . . 23
1.4.1.11 Algorithme de recherche avec tolérance aux fautes . . . . . . . 24
1.4.1.12 Les caractéristiques du protocole Chord . . . . . . . . . . . . . 24
1.4.2 CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.4.2.1 Arrivée d’un nœud . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.2.2 Départ d’un nœud . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.2.3 Le routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4.3 Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.4.4 Analyse des systèmes basés sur les DHTs . . . . . . . . . . . . . . . . . . 28
1.5 L’aspect sémantique dans les réseaux P2P . . . . . . . . . . . . . . . . . . . . . 29
1.5.1 Détection implicite de la sémantique . . . . . . . . . . . . . . . . . . . . 29
1.5.2 Détection explicite de la sémantique . . . . . . . . . . . . . . . . . . . . 29
1.6 Performances des systèmes P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.7 Problèmes ouverts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2 Internet à Quatre Niveaux (I4N ) 32

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 Identification des nœuds et des ressources . . . . . . . . . . . . . . . . . . . . . 33
2.4 Architecture du réseau I4N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5 Placement des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.6 Construction de la table de routage . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.7 Recherche de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.8 Arrivée d’un nœud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.9 Départ d’un nœud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.10 Accélération de la recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.11 Propriétés de protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.12 L’évolution du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3 Les différentes plateformes P2P 39

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 XtremWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 ProActive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
v
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4 Les Réseaux P2P et la technologie JXTA 43

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Le Projet JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Les Objectifs de projet JXTA . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1.1 Interopérabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1.2 L’indépendance de plateformes . . . . . . . . . . . . . . . . . . 44
4.2.1.3 Ubiquité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1.4 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2 Les concepts de la technologie JXTA . . . . . . . . . . . . . . . . . . . . 45
4.2.2.1 Les identificateurs . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2.2 Peers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2.3 Advertissement . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2.4 PeerGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2.5 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.2.6 Pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.2.7 Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.3 L’architecture de la plateforme JXTA . . . . . . . . . . . . . . . . . . . 50
4.2.3.1 La couche Noyau . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.3.2 La couche Service . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.3.3 La couche Application . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.4 Les protocoles de la plateforme JXTA . . . . . . . . . . . . . . . . . . . 51
4.2.4.1 Peer Discover Protocol (PDP) . . . . . . . . . . . . . . . . . . 51
4.2.4.2 Peer Resolver Protocol (PRP) . . . . . . . . . . . . . . . . . . 51
4.2.4.3 Peer Information Protocol (PIP) . . . . . . . . . . . . . . . . . 51
4.2.4.4 Rendez vous protocol (RVP) . . . . . . . . . . . . . . . . . . . 51
4.2.4.5 Pipe binding Protocol (PBP) . . . . . . . . . . . . . . . . . . . 51
4.2.4.6 Endpoint routing Protocol (ERP) . . . . . . . . . . . . . . . . 52
4.2.5 Le transport de messages Dans JXTA . . . . . . . . . . . . . . . . . . . 52
4.2.5.1 Le transport des messages sous TCP/IP . . . . . . . . . . . . 52
4.2.5.2 Le transport de messages sous HTTP . . . . . . . . . . . . . . 53
4.2.5.3 Le transport de messages sous TLS . . . . . . . . . . . . . . . 53
4.2.6 Les mécanismes de découverte dans la plateforme JXTA . . . . . . . . . 53
4.2.6.1 Découverte basée sur le réseau local . . . . . . . . . . . . . . . 53
4.2.6.2 La découverte par les invitations . . . . . . . . . . . . . . . . . 53
4.2.6.3 La découverte en cascade . . . . . . . . . . . . . . . . . . . . . 53
4.2.6.4 La découverte par les points de rendez-vous . . . . . . . . . . . 53
4.2.7 Le Shell JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.7.1 La syntaxe des commandes de JXTAShell . . . . . . . . . . . . 54
4.2.7.2 Les commandes de base de JXTAShell . . . . . . . . . . . . . . 54
4.2.7.3 Ajout des nouvelles commandes au JXTAShell . . . . . . . . . 55
4.2.8 La sécurité dans la plateforme JXTA . . . . . . . . . . . . . . . . . . . . 55
4.2.9 Les Firewalls et les NATs . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
vi
5 Performance de la plateforme JXTA à grande échelle 58
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Index distribué de partage de ressources (SRDI) . . . . . . . . . . . . . . . . . . 58
5.3 La recherche distribuée dans le réseau JXTA . . . . . . . . . . . . . . . . . . . . 59
5.3.1 Les avantages des approches distribuées . . . . . . . . . . . . . . . . . . 60
5.4 La recherche en largeur et la recherche en profondeur dans JXTA . . . . . . . . 60
5.4.1 La recherche en largeur . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4.2 La recherche en profondeur . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5 L’architecture de la recherche JXTA . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5.1 Les objectifs de JXTA search . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5.2 Les composantes de JXTA search . . . . . . . . . . . . . . . . . . . . . . 62
5.5.3 Les services de JXTA search . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6 La téléphonie Internet en mode P2P 67

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2 Généralités sur la téléphonie IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2.1 Les phases de la transmission de la voix sur le réseau IP . . . . . . . . . 69
6.2.2 Le protocole IP (Internet Protocol) . . . . . . . . . . . . . . . . . . . . . 69
6.2.3 La téléphonie IP et le RTC . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.4 La pile des protocoles Internet multimédia . . . . . . . . . . . . . . . . 70
6.2.4.1 La couche Physique . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.4.2 La couche Internet . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.4.3 La couche transport . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.4.4 La couche application . . . . . . . . . . . . . . . . . . . . . . . 71
6.2.5 Real time Transport Protocol (RTP) et RTP control protocol (RTCP) . 71
6.2.6 Le Protocole de réservation de ressource (RSVP) . . . . . . . . . . . . . 73
6.2.7 Codage de la parole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.7.1 Les techniques de codage . . . . . . . . . . . . . . . . . . . . . 73
6.2.7.1.1 La technique temporaire : . . . . . . . . . . . . . . . . 73
6.2.7.1.2 La technique paramétrique : . . . . . . . . . . . . . . 73
6.2.7.1.3 La technique par analyse et synthèse : . . . . . . . . . 74
6.2.8 Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3 Protocoles de signalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3.1 SIP (Session Initiation Protocol) . . . . . . . . . . . . . . . . . . . . . . 74
6.3.1.1 Bref historique du protocole SIP . . . . . . . . . . . . . . . . . 75
6.3.1.2 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.1.3 Adressage et nommage . . . . . . . . . . . . . . . . . . . . . . 75
6.3.1.4 Architecture de SIP . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.1.5 Ouverture d’une session . . . . . . . . . . . . . . . . . . . . . . 76
6.3.1.6 Format des messages SIP . . . . . . . . . . . . . . . . . . . . . 76
6.3.1.7 Exemple d’une session SIP . . . . . . . . . . . . . . . . . . . . 77
6.3.1.8 Limites de protocole SIP . . . . . . . . . . . . . . . . . . . . . 77
6.3.2 Le protocole H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3.2.1 ITU H.32x Famille des standards . . . . . . . . . . . . . . . . 79
6.3.2.2 Constitution de H.323 . . . . . . . . . . . . . . . . . . . . . . . 79
6.3.2.3 Exemple d’une session H.323 . . . . . . . . . . . . . . . . . . . 80
vii
6.3.3 SIP ou H.323 ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.4 Les Firewalls et les NATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.4.1 Protocoles de découverte des Firewalls et des NATs . . . . . . . . . . . 82
6.4.1.1 STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.4.1.2 TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.5 La téléphonie basée sur le protocole SIP . . . . . . . . . . . . . . . . . . . . . . 83
6.6 La téléphonie IP basée sur une architecture P2P . . . . . . . . . . . . . . . . . 84
6.6.1 La registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.6.2 Architecture de P2P-SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.6.3 La registration d’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.6.4 Défaillance d’un nœud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.6.5 Localisation des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.6.6 Les messages Off-line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.7 Skype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.7.1 Architecture de Skype . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.7.2 Les composantes software de Skype . . . . . . . . . . . . . . . . . . . . . 90
6.7.3 Les fonctions de Skype . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Conclusion générale et perspectives 94
Bibliographie 96
viii
Liste des tableaux
1.1 Quelques actions dans les messages Napster . . . . . . . . . . . . . . . . . . . . 11

1.2 Comparaison entre les différents systèmes P2P . . . . . . . . . . . . . . . . . . . 30
6.1 La famille de protocoles H.32x . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2 Comparaison des protocoles SIP et H.323 . . . . . . . . . . . . . . . . . . . . . 81
6.3 Les boostaps super nœuds dans Skype . . . . . . . . . . . . . . . . . . . . . . . 91
ix
Liste des algorithmes
1 Algorithme probabiliste de recherche et localisation des services . . . . . . . . . 16

2 Simple algorithme de recherche générale (Chord ) . . . . . . . . . . . . . . . . . 21
3 Algorithme de recherche avec des tables de raccourcis (Chord ) . . . . . . . . . . 23
4 Algorithme de recherche avec tolérance aux fautes (Chord ) . . . . . . . . . . . . 24
5 Algorithme de recherche de données (I4N ) . . . . . . . . . . . . . . . . . . . . . 36
6 Algorithme de stabilisation (I4N ) . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7 Programme d’ajout d’une nouvelle commande au Shell JXTA . . . . . . . . . . 55
x
Table des figures
1.1 Taxonomie des systèmes P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Architecture de Napster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Mécanisme de routage dans Gnutella . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Le mécanisme de recherche dans Gnutella . . . . . . . . . . . . . . . . . . . . . 14
1.5 Problème de tolérance aux pannes dans Gnutella . . . . . . . . . . . . . . . . . 15
1.6 Le routage dans l’algorithme de plaxton . . . . . . . . . . . . . . . . . . . . . . 17
1.7 Le réseau virtuel au dessus du réseau physique . . . . . . . . . . . . . . . . . . 18
1.8 Principe de base des fonctions de hachage . . . . . . . . . . . . . . . . . . . . . 20
1.9 Interface d’application pour les systèmes P2P structurés basés sur les tables de
hachage distribuées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.10 Exemple de recherche dans Chord . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.11 Les tables de raccourcis (Fingers) dans Chord . . . . . . . . . . . . . . . . . . . 22
1.12 Le routage dans Chord avec des tables de raccourcis . . . . . . . . . . . . . . . 22
1.13 Procédure de Join dans Chord . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.14 Construction des tables de raccourcis (Fingers) dans chord . . . . . . . . . . . . 24
1.15 Espace de coordonnées cartésiennes de dimensions 2 partagé entre 6 nœuds CAN 25
1.16 (a) : espace de coordonnées cartésiennes avant que le nœud F arrive, (b) : espace
de coordonnées cartésiennes après que le nœud F arrive . . . . . . . . . . . . . 26
1.17 (a) : espace de coordonnées cartésiennes avant que le nœud D quitte, (b) : espace
de coordonnées cartésiennes après que le nœud D quitte . . . . . . . . . . . . . 27
1.18 Tous les chemins amènent à Roman . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.19 Exemple de routage dans Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1 La structure du réseau P2P (I4N) . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2 La table de routage d’un nœud dans I4N . . . . . . . . . . . . . . . . . . . . . 35
2.3 L’évolution du système I4N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Les opérations de base d’un peer . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Le resolver Service pour les requêtes . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Les Types de Pipes JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 La communication entre les peers. . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 L’architecture logique de la plateforme JXTA . . . . . . . . . . . . . . . . . . . 50
4.6 La communication P2P avec la présence des firewalls . . . . . . . . . . . . . . . 56
5.1 La propagation des requêtes dans le réseau JXTA . . . . . . . . . . . . . . . . . 59

5.2 La recherche en profondeur et en largeur dans JXTA . . . . . . . . . . . . . . . 61
5.3 Le recherche dans JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 La recherche distribuée dans la plateforme JXTA . . . . . . . . . . . . . . . . . 66
xi
6.1 La transmission de la voix sur le réseau IP . . . . . . . . . . . . . . . . . . . . . 69
6.2 La téléphonie IP et le RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3 La pile des protocoles Internet Multimédia . . . . . . . . . . . . . . . . . . . . 71
6.4 Format des messages SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.5 Exemple d’une session SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.6 Tests de performances de protocole SIP . . . . . . . . . . . . . . . . . . . . . . 78
6.7 Constitution de H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.8 Exemple d’une session H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.9 La téléphonie internet classique . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.10 La recherche et l’enregistrement des utilisateurs . . . . . . . . . . . . . . . . . . 84
6.11 La téléphonie IP en mode P2P. . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.12 La recherche et l’enregistrement des utilisateurs . . . . . . . . . . . . . . . . . . 85
6.13 Diagramme d’un nœud P2P-SIP . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.14 Node startup and outgoing registration . . . . . . . . . . . . . . . . . . . . . . . 87
6.15 Défaillance d’un super nœud dans le DHT . . . . . . . . . . . . . . . . . . . . . 88
6.16 La localisation des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.17 Les messages off-line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.18 Architecture de Skype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.19 Organigramme de login dans Skype . . . . . . . . . . . . . . . . . . . . . . . . . 92
xii
Remerciements
D ’ABORD je tiens à exprimer mes plus vifs remerciements à

mon promoteur, le professeur MEDDAHI Ahmed pour les
nombreux conseils, orientations et encouragements qu’il a su me
prodiguer durant la réalisation de ce mémoire, ainsi que mon co-
promoteur Vanwormhoudt Gilles.
Je remercie les membres du jury d’avoir accepté de juger ce modeste
travail.
Je remercie M r TARI Kamel pour ses contributions à l’école doc-
torale (ReSyd).
Je remercie spécialement mon collègue Bouaissa Mohamed Abdel-
ghani pour ses critiques sur le protocole I4N que j’ai proposé dans
le deuxième chapitre.
Je désire également remercier mes collègues de l’école doctorale
d’informatique (reseau et système distribué Resyd 01 et Resyd 02 )
pour leurs soutien moral.
Mes vifs remerciements s’adressent aussi à tous les professeurs de
l’intérieur et de l’extérieur de l’Algérie, qui ont contribué dans notre
formation de premiere année magistère à l’école doctorale d’infor-
matique de l’université Abderrahmane Mira de Bejaïa.
Mes remerciement s’adressent aussi à tous mes étudiants, qui m’ont
encouragés durant toute l’année.
Merci à tous qui ont contribué à la réalisation de ce travail, de prés
ou de loin.
Novembre, 2005 AMAD Mourad
xiii
Résumé
Résumé : Popularisés par différents logiciels de partage et d’échange de fichiers, les sys-
tèmes Pair à Pair (peer-to-peer ou P2P ) reposent sur le principe de mutualisation de ressources
(par exemple les données, les programmes, les services, les capacités de stockage et de calcul ) à
l’échelle de l’Internet. Le modèle P2P est une alternative au modèle client-serveur : Les peers
sont tous au même niveau, peuvent à la fois offrir (rôle serveur ) et demander (rôle client)
des ressources. Ils peuvent librement rejoindre et quitter le système (ou tomber en panne) et
fournissent les ressources de manière intermittente. Dans ce contexte, on a proposé un nou-
veau protocole (I4N ) de découverte et localisation de services en mode P2P. Le modèle P2P
semble particulièrement intéressant pour les systèmes d’information répartis à grande échelle,
qui sont par nature, hétérogènes et instables. Plusieurs types d’applications commencent à se
migrer de l’architecture client- serveur vers l’architecture P2P, comme la téléphonie IP. Ces
différents protocoles sont incapables d’interchanger des informations entre eux, pour cela, diffé-
rentes plateformes P2P ont été mise en œuvre, JXTA a pris une grande partie dans ce mémoire.
Mots clés : P2P, protocole de routage, Plateforme P2P, JXTA, La telephonie Internet,
I4N.
Abstact : Popularized by various softwares of sharing and exchange of files, the systems
Peer to Peer (P2P ) are based on the principle of mutualisation of resources (par example
data, programs, services, capacities of storage and calculation ) on the scale of the Internet.
The model P2P is an alternative to the client-server model : The peers are all on the same
level, can at the same time offer (role server ) and to ask (role customer ) of the resources.
peers can freely join and leave the system (or to break down ) and provides the resources in
manner intermittent. In this context, we have proposed a new protocol (I4N ) for the disco-
very and localisation of services in P2P model. The model P2P seems particularly interesting
for the information systems distributed on a large scale, which by nature, are heterogeneous
and unstable. Several type of applications starts to be migrated of architecture client server
towards architecture P2P, as telephony IP. These various protocols are unable to interchange
information between them, for that, different plateforms P2P were implemented, JXTA take
a great part in this thesis.
Keys Words : P2P, routing protocols, P2P plateform, JXTA, Internet telephony, I4N.
xiv
Introduction Générale
D E nos jours, on constate une augmentation des capacités de stockage, des puis-
sances de calcul des processeurs, des débits des réseaux, du nombre d’utilisateurs
connectés à Internet et de la quantité de données hébergées par les utilisateurs. Les ques-
tions qui peuvent être posées sont : Comment construire un système ayant pour but
de stocker des données à grande échelle ? ou qui peut faire des calculs qui consomment
beaucoup de temps ? Comment faire pour qu’il soit robuste, extensible et peu coûteux ?
Comment trouver ces données à travers Internet ?. A travers ce mémoire on va essayer
de répondre à ces différentes questions.
Le terme Pair à Pair (P2P ) fait référence à une classe de systèmes ou d’applications
qui utilisent les ressources distribuées pour réaliser une opération d’une manière dé-
centralisée. Un système P2P ne dispose d’aucune structure centralisée pour réaliser ses
objectifs. Depuis quelques temps, les systèmes pair à pair font l’objet d’une attention
considérable, en raison de leur architecture sous-jacente, particulièrement adaptée au
passage à l’échelle des applications distribuées que l’on trouve sur internet. Dans un
système pair à pair, il n’y a aucun contrôle centralisé, ni aucune organisation hiérar-
chique. Chaque pair est équivalent en fonctionnalité et coopère avec d’autres pairs dans
l’objectif de réaliser une tache collective. Les systèmes pair à pair ont évolué depuis le
simple système de partage de fichiers comme Napster, jusqu’aux systèmes évolués de
gestion de données distribuées comme Seti@home.
La caractéristique fondamentale d’un réseau P2P est qu’il permettre l’interconnexion

(logiquement) d’un ensemble d’utilisateurs de façon privilégie afin que ceux ci puissent
mettre en commun des données ou des calculs. La difficulté de conception des systèmes
P2P provient de l’extreme volatilité des utilisateurs qui se connectent et se décon-
nectent à volonté. Les utilisateurs des réseaux P2P effectuent de nombreuses requêtes
de recherche dans le réseau, les réponses à ces requêtes doivent être données dans des
1
Introduction générale 2
délais aussi brefs que possible. De nombreuses propositions ont été faites dans la littéra-
ture pour la construction des réseaux Pair à Pair, mais quelques prototypes seulement
qui ont été implementés.
Notre mémoire est organisé en six chapitres comme suit :
Dans le premier chapitre, on a décrit les différents protocoles P2P, leurs architec-
tures et leurs caractéristiques. On les a regroupé suivant deux grands types : les réseaux
structurés comme Chord, CAN, Pastry qui sont basés sur les tables de hachage distri-
buées et les réseaux non structurés comme Napster qui est basé sur un index global et
Gnutella dont laquelle la recherche est basée sur la technique de diffusion (Flooding).
On a conclu le chapitre par une comparaison entre ces différents protocoles P2P sui-
vant plusieurs critères comme la scalabilité, la décentralisation, le coût de recherche et
la tolérance aux fautes.
Dans le deuxième chapitre on a proposé un nouveau protocole de localisation de

ressources en mode P2P. I4N pour Internet à Quatre Niveaux. Le protocole I4N repose
sur une topologie virtuelle en anneaux imbriqués, il appartient aux protocoles de la
troisième génération (réseaux structurés).
Dans le troisième chapitre, on a fait un survol sur les différentes plateformes P2P
largement utilisées comme XtremWeb, ProActive et JXTA.
Dans le quatrième chapitre, on a étudié la plateforme open source JXTA développée

par SUN Microsystem. JXTA est définie comme étant un ensemble de protocole P2P
généralisés et open sources qui permettent de faire communiquer n’importes quelles ap-
pareils dans le réseau (PDA, PC, Serveur,...). Elle est indépendante des protocoles de
transport (TCP/IP, HTTP,...) et des systèmes d’exploitation (Windows, Linux, ...),
ainsi que des languages de programmation (Java, C/C++, Perl,...).
Le cinquième chapitre est consacré à l’étude de performances de la plateforme JXTA

et l’extensibilité de la recherche et la localisation de services dans les réseaux P2P à
grande échelle.
Le sixième chapitre est consacré à la téléphonie IP en mode P2P. Nous avons com-
mencé par une introduction sur quelques protocoles de signalisation comme H.323 et
SIP pour arriver à détailler deux grandes approches de la téléphonie IP en mode P2P.
La première est Skype, un protocole P2P propriétaire qui est mis en oeuvre et qui
est en augmentation continue d’utilisateurs ces dernières années. La deuxième est une
architecture de la téléphonie IP en mode P2P pur basée sur le protocole SIP pour la
signalisation.
Introduction générale 3
Enfin, notre mémoire s’achève par une conclusion générale résumant les grands
points qui ont été abordés dans ce mémoire, ainsi que des perspectives que l’ont sou-
haite accomplir prochainement.
Chapitre I
Découverte et localisation de services
en mode P2P
1.1 Introduction
Les systèmes pair à pair (P2P ) constituent une plateforme récente pour exécuter
des applications reparties dans des environnements à grande échelle. Contrairement à
l’approche Client-Serveur, les nœuds sont connectés entre eux directement au dessus du
réseau physique. Ces systèmes permettent de partager les ressources et les services entre
les différents nœuds, tels que : Le contenu de leurs disques durs, largeur de bande pas-
sante et leur CPU. Cela permet d’avoir une très grande mémoire d’archivage, des bons
résultats de recherche et une puissance de calcul plus accrue que n’importe quel utilisa-
teur aurait pu avoir individuellement. Dans ce type de systèmes, les nœuds peuvent se
comporter à la fois comme client et serveur. En restant autonome, chaque ordinateur
prend part du réseau global indépendamment de son type de connectivité. Les peers ne
nécessitent pas obligatoirement une adresse IP permanente, contrairement aux serveurs
dans les architectures client-serveur qui doivent avoir une adresse IP permanente [50].
Les systèmes P2P sont devenus une forme commune d’interchangement on-line des
données [61]. Ils sont par nature distribués, sans aucune organisation hiérarchique ou
contrôle centralisé. Le problème fondamental qui confronte les applications peer-to-peer
est la recherche et la localisation des nœuds qui stockent des données particulières [60],
l’optimisation du nombre de messages traversés d’un peer à un autre pour maintenir la
4
Chapitre 1 : Découverte et localisation de services en mode P2P 5
stabilité du système, ainsi que pour la recherche de données, c’est le cœur de chaque
système P2P.
Il y a deux grandes classes des réseaux P2P : structuré et non structuré.

Dans les réseaux non structurés (ex : Napster, Gnutella,...) la recherche se fait par inon-
dation. L’inconvénient majeur est la difficulté de trouver les clés (données) recherchées
sans utiliser largement les requêtes distribuées, pour cette raison les systèmes P2P non
structurés sont considérés inscalables [62].
Dans les réseaux structurés, les données sont stockées dans des emplacements bien dé-
finis et par conséquent la recherche revient à trouver ces emplacements par la même
méthode de stockage (ex : Chord, Can, Pastry, Tapestry,...). Le problème de scalabilité
n’est pas posé dans ce type de systèmes.
De nombreuses approches permettent de construire un réseau reposant sur le pa-

radigme pair à pair (P2P ), structuré ou non, ont récemment émergés. Ces approches
forment des systèmes distribués de grande taille et améliorent l’efficacité de ces réseaux
à grande échelle.
1.2 Les réseaux peer-to-peer

Le réseau P2P est un réseau logique qui utilise un réseau physique. Le peer-to-peer
est pour beaucoup de personnes synonyme de "partage de fichiers", cette idée précon-
çue donne une mauvaise image de ce domaine. En général, le terme P2P décrit un
environnement où les machines communiquent entre elles sans l’utilisation d’un point
de contrôle centralisé pour router le trafic de données [67].
Avec les réseaux peer-to-peer, les ordinateurs partagent les données et les ressources,
en communiquant directement entre eux sans utiliser un serveur central. Quelques ob-
servateurs d’industrie disent que les réseaux peer-to-peer deviennent une technologie
réseau significative [6].
1.2.1 Les applications Peer-to-Peer

Il y a plusieurs types d’applications peer-to-peer qu’on peut les regrouper en quatre
grandes classes : le partage de fichiers , collaboration, traitement distribué et la com-
munication.
– Partage des fichiers (File Sharing)

Les systèmes d’échange de fichiers sont parmi les premiers à avoir fait découvert
le concept du P2P. Ces systèmes permettent le partage direct des documents de

natures différentes (texte, multimédia, image, ...) comme Napster, Gnutella, Free-
net, ...
– Le calcul distribué (distributed computing)

Le calcul distribué est probablement le domaine qui peut tirer les grands bénéfices
d’une architecture P2P. Un problème qui peut être décomposable et parallélisable,
c’est-à-dire divisé en plusieurs parties susceptibles d’être résolues d’une manière
quasi-simultanée par plusieurs unités, sera plus profitant de le faire sur une archi-
tecture P2P [12]. Dans ce type d’applications, les peers coopèrent pour réaliser
le traitement désiré. Ce type d’applications permet l’utilisation des ressources
des ordinateurs non exploitées, tels que la puissance du processeur ou l’espace de
stockage du disque dur. La mise en commun de celles-ci peut servir pour le fonc-
tionnement de plus grosses applications, impliquant un coût d’exploitation élevé.
Certains experts estiment que 80% à 90 % de la puissance processeur des ordina-
teurs est non exploitées. Seti@Home (1999) qui s’inscrit dans un projet américain
de recherche d’intelligence extraterrestre est un exemple d’applications P2P basé
sur le traitement distribué.
– Communication
Elle regroupe la messagerie instantanée (AOL, ICQ, MSN Messenger, Yahoo Mes-
senger,...), la téléphonie par Internet (WebPhone, Skype,...), ainsi que la vidéo-
conférence (CUseeME,...).
– Collaboration
Celle-ci est la moins connue, elle regroupe les applications de groupeware tels que
Groove Network qui facilite le travail en-ligne.
1.2.2 Les aspects des réseaux P2P

Les réseaux P2P sont caractérisés par plusieurs aspects :
– Scalabilité
Le nombre d’utilisateurs dans les réseaux P2P peut augmenter d’une manière im-
prévisible. Un système P2P doit pouvoir gérer un tel nombre d’utilisateurs.
– Tolérance aux fautes

C’est la capacité des systèmes de continuer à fournir des services d’une manière
régulière malgré la présence des fautes dans le software ou le hardware, ainsi que
les arrivées et les départs fréquents des nœuds [58]. En général la décentralisation
rend les systèmes P2P robustes aux fautes.
– Sécurité
C’est la capacité des systèmes de gérer et de protéger des informations sensibles.
Plusieurs définitions du mot sécurité existent. Une approche pour définir ce mot
est de le définir en terme de services qui peuvent être fournis. Les services de
sécurité les plus appropriés à la couche réseau de modèle OSI sont : la confiden-
tialité, l’intégrité, l’authentification et la non repudiation avec preuve de l’origine
de données.
Définition 1. La confidentialié de données est la propriété par laquelle l’information
n’est pas rendue disponible ou n’est pas relevée aux individus, aux entités ou aux proces-
sus non autorisés [55].
La confidentialité peut être assurée en utilisant les algorithmes de cryptographie

asymétrique comme RSA ou les algorithmes de cryptographie symétrique comme
AES et DES.
Définition 2. L’intégrité de données est la propriété par laquelle les données n’ont pas
été changées, détruites ou perdues d’une façon non autorisée ou accidentelle [55].
L’intégrité de données est assurée par les fonction de hachage, comme à titre
d’exemple : MD4, MD5 (Message Digest), SHA-1(Secure Hash Algorithm 1) ou
SHA-2 .
Définition 3. L’authentification de l’origine des données garantit que les données re-
çues proviennent de l’expéditeur déclaré [55].
Définition 4. La non repudiation avec preuve de l’origine de données fournit au des-

tinataire une information qui peut être utilisée comme preuve de l’origine des données
recues. Elle protege ainsi le destinataire contre une tentative de nier l’envoi de données
par l’origine [55].
La non repudiation peut être assurée par les signatures digitales ou les certificats
à clé publique.
Au début, les systèmes P2P n’ont pas implémenté les mécanismes de sécurité, mais
la communauté des chercheurs est de plus en plus attirée vers ce problème [58].
Dans l’architecture Client-Serveur, les serveurs sont des points faibles dans le
réseau (coté sécurité), car ils sont peu nombreux, très chargés et facilement iden-
tifiables, cela les rend vulnérables à des surcharges des requêtes qu’elles aient une
cause naturelle ou liée à une attaque de type déni de service (envoi d’un nombre
important de requêtes simultanément afin de rendre un serveur inutilisable).
– Anonymat
Elle est définie comme étant le degré pour lequel les systèmes P2P tiennent compte
des opérations non identifiées [58].
– Dynamisme
Les systèmes P2P doivent supporter le dynamisme, c’est-à-dire les ressources
comme par exemple les peers, peuvent joindre ou quitter le système de manière
continue, sans qu’ils affectent le fonctionnement de ce dernier.
– Décentralisation
Il n’y a pas un contrôle centralisé, ni une vue globale de tous les peers dans le
réseau. La majorité des systèmes P2P ne sont pas purement distribués, mais ils
sont hybrides.
– Connectivité ad Hoc
Pour permettre d’établir une communication sans aucune architecture préexis-
tante, car les systèmes P2P visent à faire communiquer les différents nœuds dans
les différents types de réseaux (réseau filaire, mobile, ad hoc).
– Robustesse
La robustesse doit être maintenue dans les trois composantes des systèmes P2P
suivantes : sécurité, l’agrégation des ressources et la fiabilité.
1.2.3 Les obstacles du réseau P2P

Parmi les problèmes des réseaux P2P on trouve :
– Sécurité
L’utilisation des logiciels de partage de fichiers P2P peut soulever des problèmes
sérieux de sécurité [56]. Les applications P2P permettent aux ordinateurs l’accès
direct aux autres ordinateurs, donc à leurs dispositifs du stockage, par conséquent,
la sécurité sera touchée. Le téléchargement des documents à partir d’autres sys-

tèmes rend ces derniers exposés aux virus. La deuxième raison est que les machines
sont incapables d’authentifier les identités des machines avec lesquelles elles com-
muniquent [6]. A un moment donné, un simple peer peut devenir un serveur pour
un autre peer, mais il ne pourra pas remplir tous les aspects de sécurité fournis
par les serveurs.
La scalabilité et la tolérance aux fautes dépendent de nombre de peers dans le

réseau et de leurs interconnexion, par contre, la sécurité dépend de la nature ou-
verte des systèmes P2P et de l’infrastructure de transmission, car n’importe quel
peer peut entrer en contacte avec les autres [58].
– Interopérabilité
Dans les réseaux P2P, Les applications utilisent différentes technologies réseaux
ainsi que différentes plateformes. Le fait que plusieurs plateformes puissent coha-
biter au sein de celles-ci, avec différents systèmes de sécurité, rend l’interopérabi-
lité difficile. Aujourd’hui, les services des systèmes P2P sont relativement simples
comme le transfert de fichiers musicaux, mais dans le futur ça ne sera pas le cas.
– Bande passante
Parce que les utilisateurs des réseaux P2P dans le monde ne cessent d’augmenter,
le trafic causé par ce type de systèmes peut saturer le réseau P2P.
– La découverte des ressources

Comme il n’ y a pas de serveurs dans les réseaux P2P, ainsi que les adresses IP ne
sont pas toujours permanentes, l’utilisation d’un bon algorithme de découverte et
localisation des ressources est indispensable [6].
1.2.4 Les systèmes basés sur la technologie P2P et leurs classi-
fications
Les systèmes P2P peuvent être classifiés suivant le type de recherche utilisé, la main-
tenance et l’organisation de la structure du réseau comme il est montré sur la figure 1.1.
Dans les architectures structurées, le système correspondant est organisé suivant une
topologie virtuelle connue, comme à titre d’exemple (Chord (Anneau), CAN(Tore),...).
Dans les architectures non structurées, la topologie virtuelle et la topologie physique
sont les mêmes. Différents protocoles dans les deux types d’architectures sont décrits
dans [41].
Les protocoles P2P
Recherche Structure
Exhaustive Organisé
Renseigné Non Organisé
Fig. 1.1 – Taxonomie des systèmes P2P
1.2.5 Le futur des réseaux P2P

L’augmentation généralisée des lignes à haut débit établissant le peer-to-peer comme
un véritable moyen de communication sur internet, elle va permettre l’apparition de la
téléphonie et de la vidéoconférence de bonne qualité. Pour réaliser les pleins avantages
des applications P2P, nous devons établir une infrastructure de calcul [30].
1.3 Réseaux non structurés

La première grande classe est les systèmes P2P non structurés, ceux-ci reposent
sur une construction aléatoire du graphe de connexion, un nœud joint le réseau par
l’intermédiaire d’un autre nœud déjà connecté. La recherche des services dans un tel
réseau se fait généralement selon la technique d’inondation : Un nœud désirant localiser
une ressource r demande à ses voisins s’ils connaissent cette ressource, à leurs tours, ses
voisins demandent à leurs voisins s’ils ont des connaissances de cette ressource r et ce,
jusqu’à une profondeur fixée par le système. Le nœud possédant la ressource r renvoie
une réponse qui parcourt le chemin initial dans le sens inverse.
1.3.1 Napster
C’est l’un des plus vieux et plus célèbres des systèmes P2P, il est destiné pour le
partage de fichiers musicaux. C’est un système P2P hybride dont lequel la recherche de
services est centralisée. Dans Napster, les utilisateurs ont recours à un serveur central
possédant l’index de tous les utilisateurs connectés, ainsi que leurs données partagées.
Le serveur se charge de mettre en relation un peer demandeur avec un peer possédant
les fichiers désirés. Le stockage des fichiers demeure sur les machines utilisateurs. Le
processus de transfert s’effectue directement entre les peers sans passer par le serveur
central. L’avantage principal de Napster est la localisation rapide et efficace, par contre,
elle présente un inconvénient majeur, qui est la résistance aux pannes. La figure 1.2
présente l’architecture générale de Napster.
Réponse
Requête
Téléchargement
Serveur
Client
Fig. 1.2 – Architecture de Napster
1.3.1.1 La structure de messages Napster
Les messages de Napster sont composés de trois parties :
Longueur (16 bits) type (16 bits) données...
– Longueur : C’est la taille du bloc de donnée en octets.

– Type : l’action à réaliser. Le tableau 1.1 décrit quelques actions dans les messages
Napster.
– Données : Chaîne ASCII.
Type Code Description

0 0000 Error message
2 0200 Login
3 0300 Login Ack
4 0400 Version Check
5 0400 Auto upgrade
6 0600 New user login
7 0700 Nick check
8 0800 Nick not regist
9 0900 Nick already regist
10 0A00 invalid nick
14 00E0 Login options
110 60E0 Unchare all files
... ... ...
Tab. 1.1 – Quelques actions dans les messages Napster

1.3.2 Gnutella
Contrairement à Napster, Gnutella est un protocole de recherche P2P décentralisé.
Il a pris la suite en résolvant le problème de centralisation de Napster. Lors d’une
recherche, le peer envoie la requête à ses voisins, qui font de même et ainsi de suite,
jusqu’à atteindre les nœuds à distance 7 du demandeur, cette distance est l’équivalent
du nombre de sauts maximal d’une requête HTTP [23]. L’inconvénient majeur est que
la recherche n’est pas exhaustive (la requête peut échouer même si la donnée recherchée
est présente dans le système).
1.3.2.1 La structure de messages Gnutella
Tous les messages Gnutella ont un entête commun de la forme suivante :
Identificateur Type de TTL Sauts déja Longueur de message

de message message accomplis qui suit
(16 octets) (1 octet) (1 octet) (1 octet) (4 octets)
Avec :
– L’identificateur du message : Pour identifier les messages Gnutella.
– Type : C’est l’action à réaliser parmi les suivantes : Ping, Pong, Query, Query
Hit, Push, Bye.
– TTL : Le nombre de sauts non encore réalisés.
– Sauts : Le nombre de sauts réalisés.
1.3.2.2 Les principaux messages utilisés dans le protocole Gnutella
– Ping [0x00] : Il est utilisé pour découvrir les autres servents (Serveur-Client)
sur le réseau. Un servent qui reçoit un Ping doit répondre avec un ou plusieurs
Pong.
– Pong [0x01] : C’est la réponse à un Ping, elle contient l’adresse IP et le numéro
du port du servent, ainsi que le nombre et la quantité de données partagées.
Avec :
– Port : Le port sur lequel le pair est en attente.
– Adresse IP : L’adresse IP par laquelle le pair est atteignable.
– Query [0x80] : Est utilisé pour la recherche d’un fichier, il a la forme suivante :
Vitesse minimum des servents Critères de recherche

Avec :
– Vitesse : Débit minimum pour qu’un pair répond (ko/s)
– Critère : Chaîne de caractères terminée par 0x00.
– Query Hit [0x81] : Pour la réponse à une requête Query.

– Push[0x40] : Permet de télécharger des données depuis un servent situé derrière
un firewall . Si les deux servents sont derrière des firewalls, le téléchargement est
impossible [24].
– Bye : Pour quitter.
1.3.2.3 Mécanisme de routage
Un nœud (peer ) se connecte sur le réseau Gnutella, il commence par rechercher tous
les nœuds Gnutella présents, pour cela il transmit une trame d’identification (ping) à
tous ses voisins qui eux-mêmes le transmettons à leurs voisins. Ces envois sont encapsu-
lés dans une trame TCP. Le mécanisme de recherche joue sur le TTL (Time To Live)
de la trame pour borner le nombre de sauts des messages. A chaque nœud du réseau,
le TTL est décrémenté et lorsqu’il devient égal à zéro, la retransmission est stoppée.
Un mécanisme permet d’éviter les boucles causées par les transmissions successives,
lorsqu’une trame est reçue, elle est stockée pendant un court laps du temps. Si le nœud
reçoit pendant ce laps du temps une trame identique, il la rejette, car elle est déjà trai-
tée. Lorsqu’un nœud est identifié, il envoie à l’émetteur une trame de réponse (pong).
La figure 1.3 met en evidence le mécanisme de routage dans Gnutella.
D
C
B TTL=1
A
TTL=2 E
TTL=3
F
X I TTL=1
TTL=2 TTL=2
G
TTL=1
K J
H
Fig. 1.3 – Mécanisme de routage dans Gnutella

1.3.2.4 Recherche de données
Le nœud X cherche la donnée D1, il transmit sa requête vers ses voisins, si un voisin
ne possède pas la donnée recherchée, il continue de transmettre la requête vers ses voi-
sins et ainsi de suite, jusqu’à l’expiration de la requête (TTL=0 ). Tous les nœuds qui
ont reçu la requête et qui possèdent la donnée, la retransmettent. Le nœud qui a émis
la requête utilise le protocole HTTP pour télécharger les données trouvées. Le coût de
la recherche dans Gnutella est O(n) ce qui limite la scalabilité dans ce système [22]. la
figure 1.4 met en evidence le mécanisme de recherche dans Gnutella.
Dans l’exemple décrit sur la figure 1.4, le nœud X recherche la donnée D1, il envoie
D
C
B
A Rech D1
Rech D1 E
Rech D1
Resul G F
X I Rech D1
Resul G,K
Resul G
Rech D1
Rech D1 Resul K G
Rech D1
J Liens entres les noeuds
K
Requête
H
Réponse
Resul K
Fig. 1.4 – Le mécanisme de recherche dans Gnutella
une requête Query à tous ses voisins, après l’expiration de TTL (TTL = 0 ), la donnée
est trouvée dans les nœud K et G, ces derniers répondent par des Query Hit, le nœud
X envoie un Push aux deux nœuds K et G en utilisant leurs adresses IP retournées
dans Query Hit.
L’avantage principal du protocole Gnutella est la simplicité du mécanisme de routage

utilisé, qui est basé sur l’inondation (diffusion) : Envoi de la requête à tous les voisins,
puis à tous les voisins de tous les voisins, etc, à distance bornée afin de ne pas saturer
le réseau. L’inconvénient majeur est que la recherche n’est pas exhaustive, c’est-à-dire
qu’une recherche sans réponse ne signifie pas que la donnée cherchée n’existe pas dans
le réseau, mais simplement elle n’est pas trouvée.
1.3.2.5 La tolérance aux pannes
Dans le protocole Gnutella, les nœuds ne gardent que les liens avec leurs voisins
dans leurs tables du routage, cela présente un inconvénient majeur lors d’une décon-
nexion involontaire (défaillance). Si par exemple dans la figure 1.5, le nœud E quitte
involontairement le réseau, alors ce dernier sera divisé en trois parties, qui ne sont pas
reliées entre elles.
D D
C C
B B
A A
E
F F
X I X I
G G
K J K J
H H
Fig. 1.5 – Problème de tolérance aux pannes dans Gnutella
1.3.3 Les protocoles probabilistes

Menascé [33][34] propose un protocole probabiliste de localisation de services dans
les réseaux P2P. Soit s le peer qui émet la requête (source) et soient les notations sui-
vantes :
r : M(a,b,c) : Le peer r reçoit le message M avec les paramètres a,b,c.

[X]p : Executer X avec la probabilité P.
Et soient les deux fonctions suivantes :
SearchRequest(s, res, rp, TTL) : Requête émet par la source s pour localiser
les ressources res, le message ne peut propager au maximum TTL peers, rp est la sé-
quence des peers qui ont reçu le message, cette séquence sera utilisée dans le chemin
inverse ramenant à la source.
RessourceFound(s, res, rp, v) : Indique que la ressource res cherchée par la

source s est trouvée sur le peer v, le chemin amenant à la source s est rp.
Quand un peer reçoit une requête SearchRequest, il cherche en premier lieu dans
son répertoire local (LC), ensuite dans son répertoire de cache (DC). Si la ressource est
trouvée dans son répertoire local, il envoie le message RessourceFound par le chemin
inverse parcouru par la requête SearchRequest jusqu’à atteindre la source s. Ce message

met à jour les DCs de chaque peer visité. Si la ressource est trouvée dans le DC, un
message SearchRequest est envoyé au peer pointé par le DC. Si un peer ne trouve pas
la ressource, ni dans son répertoire local, ni pointé dans son DC, il envoie la requête à
tous ses voisins avec une certaine probabilité P.
Algorithm 1 Algorithme probabiliste de recherche et localisation des services

1 : debut
2 : r : SearchRequest( source, res, (s1,s2,...sm),TTL)
3 : Si (res est dans LC) alors
4 : Envoyer RessourceFound(source, res, (s1,s2,...sm-1), r) à sm
5 : Sinon
6: Si (res, loc) est dans DC alors
7: Envoyer la requête au peer pointé dans DC
8: Envoyer SearchRequest (source, res, (s1, ...sm, r), TTL-1) à loc
9: Sinon
10 : Si (TTL > 0) alors
11 : Pour chaque peer voisin faire
12 : Envoyer [SearchRequest(source, res, (s1, ...sm, r), T T L − 1)]p
13 : r : RessourceFound (source, res, (s1,...,sm), v)
14 : Si (r <> source) alors
15 : Envoyer RessourceFound (source, res, (s1,...sm-1), v) à sm
16 : Ajouter (res, v) dans DC
17 : Sinon // La ressource est trouvée
18 : Télécharger la ressource res de peer v.
19 : Fin
1.3.4 L’algorithme de Plaxton

Plaxton [44] propose un algorithme de localisation de ressources et de routage dans
un environnement complètement distribué. Le nommage des objets et peers est construit
de manière aléatoire selon une fonction de hachage unique et connue. Chaque identifi-
cateur possède une longueur fixe. Il est écrit dans une base identique pour les objets et
les peers.
Chaque peer P maintient une table de routage de plusieurs niveaux. Chaque niveau
N de la table contient une liste de voisins de P , dont les N premiers chiffres sont
communs à ceux de P , Dans la figure 1.6 chaque nœud possède un identifiant écrit
sous forme hexadécimale d’une longueur de quatre chiffres. Le nœud d’identifiant 0325
fait parvenir un message à un nœud d’identifiant 4598, il va alors consulter le premier
niveau de sa table de routage et y cherche un voisin dont le dernier chiffre est 8 (ici
le nœud B4F8 ), puis lui faire suivre ce message. A son tour, ce dernier va consulter le
second niveau de sa table de routage et cherche un voisin dont l’identifiant se termine
par 98 (ici 9098 ) et lui faire suivre le message. Ce processus se répète jusqu’à atteindre
le nœud considéré. Cette méthode de routage garantit qu’un nœud présent dans un
système de N peers peut être joint en lnb (n) itérations, avec b la base des identifiants.
B4F8 0 1 ......... E F
N1
N1 xxx0 xxx1 xxxE xxxF
N1 0325
N2 xx05 xx15 xxE5 xxF5
N1
9098 2BB8 0098 3E98 N3 x025 x125 xE25 xF25
N1 N1 N1
N4 0325 1325 E325 F325
7598 4598 1698
N1
N1 N1
87CA D598 2118

N1
Fig. 1.6 – Le routage dans l’algorithme de plaxton
1.4 Réseaux structurés

La deuxième grande classe est celle des réseaux P2P structurés, ils sont dits struc-
turés, car au dessus du réseau physique sous-jacent, les nœuds sont reliés par un ré-
seau recouvrant construit sous certaines contraintes, répondant à plusieurs propriétés
et connectant les peers selon une structure particulière donnée (Anneau (Chord)[59],
Espace de coordonnées cartésiennes (CAN) [48]).
Les méthodes de routage et localisation déployées dans ce type d’architectures P2P

consistent à organiser la topologie virtuelle en vue de la faire correspondre à une topo-
logie connue (hypercube, anneau, tore,...). Chaque topologie présente des méthodes de
nommage, routage et localisation qui lui sont propre. Les principales études sont basées
sur les tables de hachage distribuées (Distributed Hash Table). L’avantage principal de
ces topologies est qu’elles garantissent de trouver la donnée une fois elle est présente
dans le système [2].
1.4.1 Le protocole chord

La base de protocole Chord [59] est le protocole de Plaxton. Chord repose sur une
topologie en anneau. Un nœud Chord à la connaissance de son prédécesseur et de son
successeur. Une fonction de hachage régulière génère une clé pour chaque nœud à partir
de son adresse IP, ensuite chaque nœud est placé dans l’anneau de manière à ordon-
ner les clés par ordre croissant, ainsi chaque nœud est responsable de l’intervalle [clé
(nœud actuel), clé (nœud suivant) [. La clé K est assignée au premier nœud dont son
identificateur est supérieur ou égal à K dans l’espace des identificateurs. La localisation
de données peut être implémentée facilement dans le protocole Chord par l’associa-
tion de clé pour chaque donnée et la sauvegarde du pair (Clé/Donnée) dans le nœud
responsable de cette clé [59].
1.4.1.1 Le réseau virtuel
Chord repose sur une topologie en anneau. Le prédécesseur d’un nœud et son suc-
cesseur dans le protocole Chord ne sont pas nécessairement adjacents dans le réseau
physique, comme il est montré sur la figure 1.7.
Réseau virtuell (Chord)
Internet
Réseau physique
Fig. 1.7 – Le réseau virtuel au dessus du réseau physique
1.4.1.2 L’identificateur du nœud
Les systèmes P2P structurés utilisent les tables de hachage distribuées pour obtenir
des identificateurs de données et de nœuds d’une manière unique dans le réseau. Les
clés peuvent être obtenues par le hachage des noms de données et les identificateurs
des nœuds par le hachage de leurs adresses IP [10]. Dans Chord, les identificateurs se
construisent de la même manière pour les données et les nœuds, ils sont de la forme
h(x) avec h est la fonction de hachage comme par exemple SHA-1(Secure haching
Algorithm) et x est l’adresse IP du nœud concaténée avec un index d’un nœud virtuel
entre zéro et une valeur maximale.
1.4.1.3 Le hachage consistent (Cohérent)
Les algorithmes de hachage utilisent des fonctions de hachage H, pour mettre les
clés correspondent aux données dans leurs emplacements. H : K → L, où K est l’en-
semble de toutes les clés et L est l’ensemble de tous les emplacements. La clé est un
identificateur unique qui représente la donnée. Les algorithmes usuels de hachage loca-
lisent les données en un temps constant par exemple O(ln(k)) où k est le nombre de
clés dans la table de hachage.
Le hachage consistent assigne à chaque nœud (ou donnée) un identificateur de m

bits (Chord utilise 128 bits) en utilisant une fonction de hachage comme SHA-1. La
longueur m de l’identificateur doit être suffisamment grande pour que la probabilité
d’avoir la même clé pour deux entités différentes par la même fonction de hachage soit
négligeable. Avec m bits, la plage d’adressage sera [0, 2m [ et donc (2m − 1) valeurs
différentes. Le hachage consistent permet aux nœuds de joindre et de quitter le réseau
avec un minimum de changement de clés, il permet donc l’équilibrage de charge [60].
Chaque nœud reçoit presque le même nombre de clés et donc les ressources sont uni-
formément distribuées sur les nœuds [15]. Pour maintenir la correction des successeurs,
quand un nœud N rejoint le réseau, certaines clés qui sont assignées au successeur de N
seront assignées au nœud N . Quand un nœud P quitte le réseau, toutes ses clés seront
assignées à son successeur et donc les changements d’attribution de clés lors d’arrivée
et de départ des nœuds sont petits. Avec une probabilité élevée, quand un nœud re-
joint ou quitte le système, uniquement O(1/N ) fraction de clés qui sera transférée vers
différents nœuds. Les tables de hachage distribuées sont des bonnes fondations pour
les algorithmes de recherche et de localisation de services en mode P2P, car elles n’im-
posent aucunes contraintes sur la structure des clés de données [2]. La figure 1.8 illustre
le principe des fonctions de hachage.
Un exemple de fonction de hachage est SHA-1, elle peut hacher un nombre ar-
bitraire de données en L = 2160 emplacements différents . Les fonctions de hachage
doivent permettre de hacher des clés similaires en des emplacements différents [61], par
exemple dans la figure 1.8, l’emplacement de H(0 peer0 ) est indépendant de l’empla-
cement de H(0 peers0 ). Les opérations de base que doivent implementer les interfaces
d’applications avec les tables de hachage distribués (figure 1.9) peuvent être résumées
dans put(key, value), get(key), remove(key).
Pgm Peer Chord

Peers Food Napster
1 2 L
H (’Chord’)
Fig. 1.8 – Principe de base des fonctions de hachage
Application P2P structurée
API Interface API Interface API Interface
Put (Key, Value) Remove (Key) Value = Get (Key) Value
Table de hachage distribué (DHT)
Peer Peer Peer Peer
Fig. 1.9 – Interface d’application pour les systèmes P2P structurés basés sur les tables
de hachage distribuées
1.4.1.4 Placement des ressources
La clé K, identificateur de ressource est générée par le hachage du nom de la res-

source (hash(ressource) = K), K est ensuite placée sur Successeur (k) qui est le nœud
d’identificateur immédiatement supérieur ou égal à K.
1.4.1.5 Recherche de données
Chord présente un algorithme de recherche de données simple, il permet la recherche

d’une manière exhaustive, c’est-à-dire qu’il garantit la localisation de ressources si elles
sont présentes dans le système.
1.4.1.6 Exemple de recherche
Dans la figure 1.10, la clé K16 est localisée dans le nœud N21 et la clé K54 dans
le nœud N56. La simple connaissance du prédécesseur et du successeur permet certes
de construire une topologie en anneau, mais elle présente des performances médiocres
en terme de nombre de nœuds à parcourir pour acheminer une requête, cette valeur
Algorithm 2 Simple algorithme de recherche générale (Chord )

1 : Rechercher (mon-id,clé-id)
2 : Début
3 : N <- mon successeur
4 : Si (mon-id < n < clé-id)
5 : Rechercher (id) sur le pair n
6 : Sinon
7 : Retourner mon successeur
8 : Fin
N1
N56
N8
K54 Rechercher (K54)
N51
N14
N48
K16
N42
N21
N36
N32
Fig. 1.10 – Exemple de recherche dans Chord
pouvant atteindre (n − 1) pour un nœud N envoyant une requête de clé (précèdent

(n) -1 ). La figure précédente illustre ce type de problèmes avec un anneau contenant
10 nœuds et une plage d’adressage [0, 64[. On peut constater qu’un nœud de clé N8
désirant effectuer une requête de clé K54 s’effectuera en 8 sauts.
Afin de palier à ce problème, une table de routage distribuée est adoptée dans
le protocole Chord, ainsi chaque nœud ne nécessite pas trop d’informations de routage
concernant les autres nœuds, c’est uniquement O(ln(n)). Pour un espace de clés compris
dans l’intervalle [0, 2m [, chaque nœud N se voit doter d’une entrée vers les nœuds
(appelés fingers) de clé suivant(N/2i−1 ) avec 1 < i < m. Ainsi, chaque nœud maintient
une table des successeurs de m entrées, le successeur K qui correspond à la k iemme entrée
est le premier nœud sur l’anneau qui vérifie (i + 2k − 1) mod 2n, 1 <= k <= m. Le
nombre maximum de nœuds parcourus pour acheminer une requête est alors exprimé
en O(ln(n)).
1.4.1.7 Tables des raccourcis
La iiemme entrée de la table des raccourcis du nœud N contient le premier nœud

dont son identificateur est supérieur ou égal à N + 2i−1 , elle inclus aussi l’adresse IP et
le numéro de port du nœud pointé. La figure 1.11 est un exemple de table de raccourcis
N102 N1
N70 N32
N80
71 ... 71 N70 N8 33 ... 33 N40
72 ... 73 N79 N70 34 .. 35 N40
74 ... 77 N79 N14
36 .. 39 N40
78 ... 85 N80 N52
40 ... 47 N40
86 ... 101 N102 N21 48 ... 63 N52

N40
102 ... 5 N102 64 ... 95 N70
N32
N36 96 ... 31
6 ... 69 N32 N102
Fig. 1.11 – Les tables de raccourcis (Fingers) dans Chord
dans Chord. La figure 1.12 montre qu’une requête de clé K54 est acheminée en trois
N1
N56
N8
Rechercher (K54)
N51
N14
N48
N42
N21
N36
N32
Fig. 1.12 – Le routage dans Chord avec des tables de raccourcis
sauts, en utilisant les tables des raccourcis, alors qu’elle est acheminée en 8 sauts sans
utiliser les tables de raccourcis (figure 1.10).
1.4.1.8 Algorithme de recherche avec des tables de raccourcis
Algorithm 3 Algorithme de recherche avec des tables de raccourcis (Chord )

Rechercher (mon id, clé id)
1 : Début
2 : Trouver dans la tables des raccourcis le plus grand pair n tel que
mon id < n < clé id
3 : Si n existe alors
4 : Appeler rechercher (id) sur le pair n
5 : Sinon
6 : retourner mon successeur
7 : Fin
1.4.1.9 Arrivée d’un nœud
Il est difficile de ne pas recourir à des serveurs pour la première connexion à un

réseau P2P, c’est une phase préliminaire commune à tous les réseaux P2P, elle nécessite
de trouver au moins une machine du réseau qui servira d’introducteur, une structure
préexistante est donc nécessaire afin de connecter un nouveau nœud. Lors de l’arrivée
de ce dernier dans le réseau, il lui faut au moins un nœud pour qu’il puisse prendre
place, ce mécanisme s’appelle le Boostraping (voir figure 1.13). Plusieurs techniques
ont été étudiées dans [7], par exemple l’utilisation de quelques serveurs statiques qui
sauvegardent les adresses IP de quelques nœuds récemment connectés au réseau.
Boostrap Host
je suis un nouveau venu

voila quelques noeuds
récement joignez
1 Le réseau déja
2 construit
Nouveau noeud
Fig. 1.13 – Procédure de Join dans Chord
1.4.1.10 Construction des tables de raccourcis
Le protocole Chord est adapté efficacement aux arrivés et aux départs des nœuds [59].
Quand un nœud N rejoint le réseau, après avoir eu un identificateur, il doit initialiser
sa table de raccourcis (figure 1.14) de telle manière qu’elle contient m entrées, le début
de l’intervalle de la iiemme entrée doit être supérieur ou égal à N + 2i−1 et la fin de
l’intervalle doit être égale à (début de l’intervalle -1 ) de l’entrée suivante.
N1
N102
N20
N80 N8
21 ... 21
22 ... 23
N70 N14
24 ... 27
N20
28 ... 35
N52
36 ... 51 N21
N40
52 ... 83 N32
N36
84 ... 19
Fig. 1.14 – Construction des tables de raccourcis (Fingers) dans chord
1.4.1.11 Algorithme de recherche avec tolérance aux fautes
Algorithm 4 Algorithme de recherche avec tolérance aux fautes (Chord )

Rechercher (mon id, clé id)
1 : Début
2 : Trouver dans la table des raccourcis et dans la liste des successeurs
le plus grand pair n tel que mon id < n <clé id
3 : Si (n existe) alors
4 : Appeler rechercher (id) sur le pair //prochain saut
5: Si (l’appel échoue) alors
6: Retirer n de la table des raccourcis
7: Retourner (rechercher (mon id, clé id))
8: Sinon
9: Retourner (mon successeur).
10 : Fin
1.4.1.12 Les caractéristiques du protocole Chord
Le protocole Chord présente certaines caractéristiques importantes dans la pratique :
1. Equilibrage de charge : Chord est basé sur les tables de hachage distribuées,
qui fournissent un degré d’équilibrage de charge important.
2. Décentralisation : Le protocole Chord est purement distribué, aucun nœud
n’est important que les autres.
3. Scalabilité : Le coût de localisation de services est résolu en O(ln(n)), où n est

le nombre de nœuds, par conséquent, il peut implémenter un très grand système.
4. Disponibilité : Le nœud responsable d’une clé donnée peut être toujours trouvé,
même si le système est dans un état de changement continue.
5. Nommage flexible : Le protocole Chord n’impose pas des contraintes sur la
structure de clés recherchées.
Le protocole Chord est basé sur une recherche binaire. Une généralisation de ce
protocole à été faite dans [1].
1.4.2 CAN
Can [47] 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 1.15 montre un
exemple d’espace de coordonnées cartésiennes de deux dimensions [0, 1][0, 1] partitionné
entre six nœuds.
0.5
1.0 Les coordonnées cartésisiennes
D E F de chaque zone
0.5 A (0.0 −− 0.25 , 0.0 −− 0.5)

B (0.25 −− 0.5 , 0.0 −− 0.5)
A B C
C (0.5 −− 1.0 , 0.0 −− 0.5)
0.0 D(0.0 −− 0.5 , 0.5 −− 1.0)

0.5 1.0
E(0.5 −− 0.75 , 0.5 −− 1.0)
F (0.75 −− 1.0 , 0.5 −− 1.0)
Fig. 1.15 – Espace de coordonnées cartésiennes de dimensions 2 partagé entre 6 nœuds

CAN
CAN est construit de 3 pièces de base : Le routage, la construction de la couverture de

coordination et la maintenance de sa couverture [47]. Les peers 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).
Dans un espace de coordonnées cartésiennes de dimension d, deux nœuds sont dits

adjacents (voisins) si leurs espaces de coordonnées se diffèrent aux long de (d − 1)
dimensions et se chevauchent en une dimension. Par exemple sur la figure 1.15, les
voisins du nœud E sont D, F et C, par contre, C et D ne sont pas adjacents.
1.4.2.1 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 [29] ), 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 (figure 1.16), une zone est subdivisée premièrement
suivant l’axe des X, ensuite suivant l’axe des Y .
1.0 1.0
C C
0.75 A 0.75 A
D D
0.5 0.5
B E B E F
0.0 0.5 0.75 0.0 0.5 0.75 1.0

1.0
les coordonnées cartésiennes de chaque zone les coordonnées cartésiennes de chaque zone
A (0.0 −− 0.5 , 0.5 −− 1.0) A (0.0 −− 0.5 , 0.5 −− 1.0)
B (0.0 −− 0.5 , 0.0 −− 0.5) B (0.0 −− 0.5 , 0.0 −− 0.5)
C (0.5 −− 1.0 , 0.75 −− 1.0) C (0.5 −− 1.0 , 0.75 −− 1.0)
D (0.5 −− 1.0 , 0.5 −− 0.75)
D (0.5 −− 1.0 , 0.5 −− 0.75)
E (0.5 −− 0.75 , 0.0 −− 0.5)
E (0.5 −− 1.0 , 0.0 −− 0.5)
F (0.75 −− 1.0 , 0.0 −− 0.5)
(a)
(b)
Fig. 1.16 – (a) : espace de coordonnées cartésiennes avant que le nœud F arrive, (b) :
espace de coordonnées cartésiennes après que le nœud F arrive
1.4.2.2 Départ d’un nœud
Quand un nœud quitte le réseau (figure 1.17), la zone qui été occupée par ce nœud
sera occupée par un de ses voisins. Une mise à jours des listes de voisins est nécessaire
pour ces derniers .
1.0 1.0
C
0.75 A 0.75 A C
D
0.5
0.5
B E F B E F
0.0 0.5 0.75 1.0 0.0 0.5 0.75 1.0

Les coordonnées cartésiennes de chaque zone
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) A (0.0 −− 0.5 , 0.5 −− 1.0)
C (0.5 −− 1.0 , 0.75 −− 1.0) B (0.0 −− 0.5 , 0.0 −− 0.5)
D (0.5 −− 1.0 , 0.5, −− 0.75) C (0.5 −− 1.0 , 0.5 −− 1.0)
E (0.5 −− 0.75 , 0.0, −− 0.5)
E (0.5 −− 0.75 , 0.0, −− 0.5)
F (0.75 −− 1.0 , 0.0, −− 0.5)
F (0.75 −− 1.0 , 0.0, −− 0.5)
(a)
(b)
Fig. 1.17 – (a) : espace de coordonnées cartésiennes avant que le nœud D quitte, (b) :
espace de coordonnées cartésiennes après que le nœud D quitte
1.4.2.3 Le routage
Chaque nœud dans CAN maintient une table de routage qui contient les identifica-
teurs des nœuds adjacents et leurs adresses IP dans un espace de dimension d.
Comme il y a plusieurs chemins entre deux peers (ex : C et N dans la figure 1.18),
même si un peer intermédiaire (dans le chemin reliant C et N ) quitte le système, il y
aura toujours un autre chemin qui relie ces deux nœuds.
A B C D
E F G H
I J K L
M N O P
Fig. 1.18 – Tous les chemins amènent à Roman
Parmi les chemins qui relient les nœuds C et N dans La figure 1.18 on trouve :
C->B->F->J->N C->G->K->O->N C->D->H->G->K->J->N
C->G->F->J->N C->G->K->O->N C->D->H->L->P->O->N
C->G->K->J->N C->G->K->O->N C->D->H->L->K->O->N
C->G->K->O->N C->D->H->L->K->J->N C->D->H->G->K->O->N
C->D->H->G->F->J->N ..............
1.4.3 Pastry
Pastry [49] est un réseau recouvrant purement décentralisé, scalable et s’auto-
organise en anneau. Chaque nœud ou donnée dans Pastry à un identificateur unique de
128 bits obtenu d’une manière aléatoire lors de la première entrée dans le système, en
basant sur son adresse IP ou sa clé publique et en utilisant un mécanisme de cryptogra-
phie et de hachage. Ce mécanisme permet de générer des identificateurs uniformément
distribués sur l’espace des identificateurs. Pastry est basé sur un mécanisme de routage
fondé sur la notion de préfixe/suffixe.
Pasty assigne aléatoirement à chaque nœud du réseau un identifiant unique de n

bits compris entre 0 et 2n − 1 (typiquement n =128 ). L’espace d’adressage est considéré
circulaire, ainsi l’identifiant 0 est le successeur de l’identifiant 2n − 1. Pastry associé aux
données des clés de la même manière que pour les nœuds. La recherche d’une donnée
de clé K revient à rechercher le nœud dont son identificateur est numériquement plus
proche de celui de la donnée K. L’algorithme de routage utilisé dans Pastry est dérivé
de l’algorithme de Plaxton [44], il consiste à router le message de proche en proche
vers les nœuds qui partagent avec la clé un préfixe de plus en plus grand, ainsi, pour
un réseau de n nœuds, le routage nécessite au plus ln2b (N ) sauts, 2b est la base de
numération des identifiants. La figure 1.19 est un exemple de routage dans Pastry.
xx02 x012 0712

xxx0
8723 1712
x112
xxx1
x212 2712
xx22
x312 3712
xxx3 xx32
xx42 x412 4712
xxx4
x512 5712
xxx5 xx52
xx62 x612 6712
xxx6
xxx7 xx72 7712
Niveau 1 Niveau 2 Niveau 3 Niveau 4
Fig. 1.19 – Exemple de routage dans Pastry
1.4.4 Analyse des systèmes basés sur les DHTs

Les tables de hachage distribuées présentent quelques limitations par l’utilisation
de la localité spaciale des ressources [54]. Si par exemple la ressource cherchée est
une page web (http ://www.cnn.comand/weather ) et qui est immédiatement précédée
par la recherche de ressource (http ://www.cnn.comand ), le réseau doit être capable
d’utiliser les informations de la premiere recherche, afin de l’utiliser dans la deuxième

recherche. Cette fonctionnalité n’est pas présente dans les DHTs, car les ressources
sont indépendantes les unes des autres. Des nouvelles méthodes ont vues le jour pour
résoudre un tel problème, elles sont basées sur les Skip graph.
1.5 L’aspect sémantique dans les réseaux P2P

De nombreuses approches se penchent aujourd’hui sur la sémantique dans les reseaux
P2P pour capter non plus la localité géographique, mais la localité d’intérêt (séman-
tique). Ces techniques utilisent des similitudes d’intérêts entre les utilisateurs d’une
application donnée. Les méthodes permettant de gérer la localité sémantique peuvent
être classées en deux grandes familles :
1.5.1 Détection implicite de la sémantique

La premiere classe regroupe les méthodes permettant de prendre en compte les as-
pects sémantiques des nœuds de manière implicite. Dans ce cas, les systèmes cherchent
à deviner des intérêts et des préférences de chacun des utilisateurs, le plus souvent,
ces systèmes se basent sur l’utilisation d’un historique récent, afin de catégoriser les
nœuds du réseau P2P. En effet, différentes techniques de regroupement implicite des
nœuds basées sur la similarité des intérêts de chacun des participants ont été proposées :
XLRU : Chaque nœud possède une liste ordonnée de voisins. Pour chaque voisin
répondant d’une manière correcte à une requête, celui ci est placé en tête de la liste,
ainsi, par la suite, chaque requête est d’abord envoyée au voisin en tête de la liste, puis
au suivant et ainsi de suite.
XHistorique : La méthode historique choisit les x nœuds les plus utiles durant
une plage de temps déterminée.
XPopularité : Cette solution est une méthode hybride des deux méthodes précé-
dentes. Elle permet d’obtenir des listes sémantiques contenant la plupart du temps les
nœuds de même type, en conservant la simplicité de LRU.
1.5.2 Détection explicite de la sémantique

Dans la seconde grande classe de méthodes permettant de prendre en compte l’as-
pect sémantique dans les reseaux P2P, plusieurs méthodes ont été proposées.
X La première méthode est basée sur un regroupement explicite des nœuds au sein
du réseau P2P. Afin d’améliorer l’efficacité, celle ci introduit le concept du réseau recou-
vrant sémantique SON (Semantic Overlay Network ). Au dessus d’un réseau recouvrant
existant, les nœuds sont regroupés en plusieurs SONs en fonction de leurs intérêts com-
muns. Un nœud peut appartenir à plusieurs SONs, permettant ainsi à un utilisateur de
ne pas se limité à un seul thème.
1.6 Performances des systèmes P2P

Le tableau 1.2 récapitule les performances des systèmes P2P étudiés dans ce chapitre.
Napster Gnutella Plaxton Can Chord Pastry

Décentralisation Non Oui Oui Oui Oui Oui
Localisation Constant O(n) lnb (n) d.N O(ln(n)) ln2b (n)
Scalabilité Non Non Non Oui Oui Oui
Equilibrage de charge Non Non Non Oui Oui Oui
Tab. 1.2 – Comparaison entre les différents systèmes P2P
1.7 Problèmes ouverts

X Les systèmes P2P structurés comme par exemple CAN ou Chord sont générale-
ment basés sur l’utilisation des tables de hachage distribuées, ils utilisent des identifica-
teurs uniques sur les données, par conséquent, le résultat de la recherche d’une donnée
ne peut être que unique. Contrairement aux systèmes P2P non structurés, comme par
exemple Napster ou Gnutella, la recherche se fait par des mots clés et les résultats
peuvent être variés. La question qui peut être posée est : Es ce qu’on peut améliorer les
systèmes P2P structurés pour qu’ils puissent prendre en considération ce problème ?.
C’est-à-dire, dans les systèmes de partage de données, la recherche de " voiture " peut
retourner " voiture de sport " ?
X Un réseau P2P est constitué de peers inconnus et donc potentiellement dange-
reux, il convient de mettre en œuvre différents mécanismes de sécurité.
X Prendre en considération la notion de sémantique au cours de recherche dans les
systemes P2P structurés (basés sur les DHTs).
X L’utilisation efficace des réseaux P2P dans différents domaines comme par exemple
la téléphonie IP .
1.8 Conclusion
Dans ce chapitre, on a fait un tour d’horizon sur les systèmes P2P les plus connus,
on les a classifiés dans deux grandes classes, les systèmes non structurés comme Naps-
ter, Gnutella, etc, les systèmes structurés comme Pastry, CAN, Chord. On a énuméré
leurs avantages et leurs inconvénients. Notons qu’il y a aussi d’autres systèmes P2P qui
ne sont pas cités dans ce mémoire comme : KazaA, Freenet, Morpheus, Kademlia[32],
Edutella[42], ...
Les systèmes Pair à Pair (P2P ) sont confrontés à des problèmes liés à leurs tailles, leurs
sensibilités à la charge et leurs dynamismes. En effet, ces systèmes doivent potentielle-
ment pouvoir gérer des millions de machines en restant efficaces, malgré des connexions
et des déconnexions très fréquentes. Les recherches scientifiques dans les réseaux P2P
sont classifiées suivant trois grands axes :
1. Les plateformes P2P : Elles sont destinées principalement pour régler le pro-
blème d’interopérabilité dans les systèmes P2P, ainsi que pour faciliter l’implé-
mentation des applications P2P, JXTA (Voir chapitres 3, 4 et 5 ) est un exemple
de plateforme P2P .
2. Les algorithmes P2P : Comme le réseau Internet augmente sans cesse à une
grande accélération, l’architecture client-serveur commence à avoir des problèmes
de scalabilité. Les algorithmes P2P sont devenus intéressants au fur et à mesure
de cette augmentation, on peut citer à titre d’exemple CAN, Chord.
3. Les applications P2P : Une application P2P est un algorithme P2P implé-
menté au dessus d’une plateforme P2P.
En outre, les réseaux P2P ne doivent pas être systématiquement associés aux appli-
cations de partage de fichiers, ces réseaux sont actuellement utilisés dans de nombreux
autres domaines tels que : le travail collaboratif ou le calcul distribué . Si l’on considère
l’évolution actuel de l’informatique, avec les réseaux ad hoc, les réseaux sans fils, la
mobilité, l’accroissement de la puissance des machines et de la bande passante, il nous
semble que dans ce contexte, les réseaux P2P prennent leur places et occupent une
partie importante du trafic réseau.
Les architectures P2P précédentes constituent chacune un système distinct, inca-

pable de communiquer avec les autres. Aux vues de ce constat, certaines entreprises,
telles que Sun Micro System ont entrepris des efforts de standardisation des proto-
coles de communication indépendants des systèmes d’exploitations et des langages de
programmation, comme JINI et JXTA 1 .
1
JXTA se prononce juxta
Chapitre II
Internet à Quatre Niveaux (I4N )
Résumé : un problème fondamental qui confronte les applications P2P est la décou-
verte et la localisation efficaces des nœuds qui stockent des données particulières. Dans
ce chapitre on a proposé I4N (Internet à Quatre Niveaux ) : Nouveau protocole P2P
scalable et distribué qui traite ce problème.
Mots clés : P2P, protocole de routage P2P, systèmes P2P structurés, I4N.
2.1 Introduction
Les réseaux P2P sont classifiés en deux grandes classes. La première classe est les
réseaux P2P non structurés comme Gnutella [24] dans laquelle la recherche se fait
par la technique de diffusion (flooding), en utilisant les TTLs et donc la recherche de
ressources n’est pas déterministe. Une requête peut échouer même si la donnée cherchée
est présente dans le système. La deuxième classe est les réseaux P2P structurés, dans ce
type de système, les nœuds sont organisés suivant une architecture bien définie comme
Chord (Anneau)[60], CAN (Tore)[47]. Dans ce chapitre on va proposer un système
P2P, scalable à l’échelle de l’Internet et complètement décentralisé, structuré suivant
des anneaux à plusieurs niveaux.
32
Chapitre 2 : Internet à Quatre Niveaux (I4N) 33
2.2 Motivations
Le routage dans les réseaux P2P est un routage au niveau applicatif et par consequent,
le nombre du sauts correspondant dans la couche réseau sera plus grand. L’objectif dans
le routage P2P est de diminuer au maximum possible le nombre de sauts.
2.3 Identification des nœuds et des ressources

Chaque nœud est identifié par un identificateur unique N qui est la iemme partie de
son adresse IP (1 ≤ i ≤ 4) tel que i est le niveau où appartient ce noeud, ainsi, le nœud
d’adresse IP : 176.210.12.14 aura comme identificateur N176 s’il appartient au niveau 1,
N210 s’il appartient au niveau 2, N12 s’il appartient au niveau 3 et N14 s’il appartient
au niveau 4. Plusieurs nœuds peuvent avoir le même identificateur, mais ils appar-
tiennent à des anneaux différents, par exemple : Les nœuds d’adresse IP : 176.210.12.14
de niveau 1 et 176. 176.14.12 de niveau 2, ont tous les deux l’identificateur N176. Les
nœuds appartenant au même niveau ont des identificateurs différents.
Les ressources à leurs tours, sont identifiées par des identificateurs uniques générés
par les tables de hachage distribuées. La clé d’une ressource est composée de quatre
parties de la forme (A.B.C.D).
2.4 Architecture du réseau I4N

Le réseau est structuré en plusieurs anneaux imbriqués, chaque anneau contient au
maximum 256 nœuds. L’anneau de niveau 1 contient les nœuds d’adresses IP varient
entre 1.x.y.z et 255.x.y.z, de telle manière que si le nœud d’adresse IP : 1.214.125.16 ap-
partient à l’anneau de niveau 1, alors le nœud d’adresse IP : 1.215.125.16 appartient à un
anneau de niveau supérieur (2, 3, ou 4 ), ainsi, les nœuds d’adresses IP : 213.16.25.114,
213.16.25.214, 213.16.25.145 et 213.16.25.146 peuvent appartenir au même anneau (ni-
veau 4 ) et donc ils sont logiquement et physiquement proches. Dans chaque anneau, les
nœuds sont ordonnés suivant leur identificateurs (figure 2.1).
Les nœuds appartenant à deux anneaux de niveaux différents sont les nœuds appar-
tenant à l’ensemble Z = X ∩ Y tel que :
X = { l’ensemble des nœuds appartenant à l’anneau de niveau i , leurs adresses IP
sont de la forme P1.Pi.P3.P4 } (ici i =2 ).
Y= { l’ensemble des nœuds appartenant à l’anneau de niveau i + 1, leurs adresses
IP sont de la forme M1.M2.M3.M4 et le nœud d’adresse IP M1.x1x2x3x4.M3.M4 n’ap-

partient pas à l’anneau de niveau i − 1 }.
Chaque nœud maintient une table de routage qui contient les adresses IP et les
numéros du port des nœuds qui lui sont reliés logiquement et qui lui sert pour la
recherche de ressources. Cette table contient au maximum 2 ∗ ln(256) entrées, ln(256)
entrées pour chaque niveau, car chaque peer peut appartenir à deux anneaux de niveaux
successifs.
N90
N72
N74 N69
Niveau 1
N81 N62
N50
N99
N60
N41
N50 N66
Niveau 2
N38
N29
N111
N120 N67
N31
Niveau 3
Niveau 4 N61
N210
N200 N21 N52
Fig. 2.1 – La structure du réseau P2P (I4N)
2.5 Placement des ressources

Les ressources sont identifiées par des identificateurs uniques de la forme A.B.C.D
générés par les fonctions de hachage distribuées. Une ressource d’identificateur A.B.C.D
sera placée dans le nœud d’adresse IP : WXYZ tel que W (respectivement X,Y,Z ) est
la plus petite valeur supérieure ou égale à A (respectivement B, C, D).
2.6 Construction de la table de routage

Quand un nouveau nœud arrive sur le réseau, il initialise sa table de routage de telle
manière quelle contient 2 ∗ ln(256) (16 entrées), huit (8) entrées pour chaque niveau. Le
début de l’intervalle de la iemme entrée doit être supérieur ou égal à N + 2i−1 et la fin de
l’intervalle doit être égal au (début de l’intervalle -1) de l’entrée suivante et ceci pour
les deux niveaux. La figure 2.2 montre la table de routage du nœud d’identificateur N50
dans l’anneau du niveau 1 et d’identificateur N52 dans l’anneau du niveau 2.
N90
finger table N50/N52
N50 + 1 N60
N72 N50 + 2 N60
N74 N69 N50 + 4 N60
Niveau 1
N50 + 8 N60
Niveau 1 N50 + 16 N69
N81 N62
N50
Niveau 2 N52 Niveau 2

N60
N99 N52 + 1 N60
Niveau 2
N52 + 2 N60
N60 N52 + 4 N60
N41 N52 + 8 N60
N52 + 16 N29
N50 N66
Niveau 2
N38
N29
N111
N120 N67
N31
Niveau 4
Niveau 3 Niveau 4
N61
N210
N200 N21 N52
N20
Fig. 2.2 – La table de routage d’un nœud dans I4N
2.7 Recherche de données

I4N présente un algorithme de recherche simple et exhaustive, c’est-à-dire, il garan-
tie de trouver la donnée une fois elle est présente dans le système P2P. Le coût de la
recherche de ressources dépend du nombre de niveaux parcourus dans le réseau, il est
P
donné en (ln(ni )), i ≤ 4, ni est le nombre de nœuds dans l’anneau de niveau i.
Un nœud désire rechercher la donnée X, il calcule la clé de cette dernière (soit

c1 c2 c3 c4 ) en utilisant la même fonction de hachage par laquelle elle était placée, ensuite
il invoque l’algorithme de recherche rechercher (c1 c2 c3 c4 ).
Algorithm 5 Algorithme de recherche de données (I4N )

Rechercher (clé c1 c2 c3 c4 )
1 : Début
2 : Localiser le nœud X dans le même niveau d’adresse IP (P1 P2 P3 P4 ) tel que P i
est la plus petite valeur supérieure ou égale à Ci.
3 : Si ∃ cj tel que cj > Pj et j < i alors
4 : Aller au nuveau (i − 1) et appeler Rechercher (clé c1 c2 c3 c4 )
5 : Sinon
6: Si la donnée est présente alors
7: télécharger la donnée
8: Sinon
9: Aller au niveau (i + 1) et appeler Rechercher (clé c1 c2 c3 c4 ) (si i < 4)
10 : Fin
2.8 Arrivée d’un nœud

Quand un nouveau nœud rejoint le réseau, il obtient quelques adresses IP de nœuds
qui sont déjà dans le réseau par le mécanisme de boostrapping[7], il contacte l’un de
ces nœuds pour qu’il puisse se placé dans le système I4N, ensuite il construit sa table
de routage.
2.9 Départ d’un nœud

Dans le départ volontaire d’un nœud, les clés de données sur lesquelles il est respon-
sable seront assignées à son successeur dans tous les anneaux où il appartient (maximum
deux anneaux ). Dans un départ involontaire d’un nœud (défaillance), les clés de don-
nées sur lesquelles il est responsable seront republiées par leurs propriétaires. Dans les
deux types du départ, l’algorithme de stabilisation (Algorithme 6) est lancé .
Soient : n : le nœud d’identificateur n, ni et ni+1 les deux niveaux à lesquels il

appartient.
Algorithm 6 Algorithme de stabilisation (I4N )

depart (n, ni , ni+1 )
1 : Début
2: Si (ni+1 est vide) alors
3: mettre à jour la table de routage
4: Sinon
5: Si ∃ (n0 , n0i , n0i+1 ) tel que n0i = ni+1 alors
6: Si (n0i+1 = vide) alors
7: n0i = ni ; n0i+1 = ni+1 ;
8: mettre à jour la table de routage
9: Sinon
10 : n0i = ni ; n0i+1 = ni+1 ;
11 : mettre à jour la table de routage
12 : depart (n0 , ni , ni+1 )
13 : Fin
2.10 Accélération de la recherche

La recherche dans I4N peut être accélérée, en adoptant la technique de broadast dans
chaque niveau et donc la recherche se fera en 4 sauts maximum (un saut dans chaque
niveau). Le nombre de messages pour une recherche sera évidemment plus grand.
2.11 Propriétés de protocole

Le protocole I4N présente plusieurs caractéristiques intéressantes dans la pratique :
– La scalabilité : I4N est indépendant du nombre de nœuds dans le réseau. La

P
recherche se fait d’une manière exhaustive, elle est de l’ordre de ln(ni ) sauts,
ni est le nombre de nœuds dans le niveau i.
– La décentralisation : Le protocole I4N est complètement décentralisé, tous les
nœuds sont similaires (aucun nœud n’est important que les autres).
– L’équilibrage de charge : La génération des clés de données se fait par les
tables de hachage distribuées, qui garantissent l’équilibrage de charge entre les
nœuds.
– La tolérance aux fautes : le protocole I4N maintient toujours la stabilité du
système en cas de départ (volontaire ou involantaire) ou d’arrivée d’un nouveau
nœud.
– le coût : La table de routage dans le protocole I4N est distribuée sur tous les
nœuds, chacun d’eux maintient des informations sur uniquement 2 ∗ O(ln(s))
autres nœuds, s ≤ 256 (le nombre maximum de nœuds dans un seul anneau).
2.12 L’évolution du réseau

Après un certain temps de fonctionnement du système, ce dernier ressemble à la
figure 2.3.
N3
N3
N3
N2
N2 N4
N3
N3
N1
N2
N4
N3
N2
N3
N3
N4 N3
N4
N4
N4
Fig. 2.3 – L’évolution du système I4N
2.13 Conclusion
Les protocoles P2P de la troisième génération basés sur les tables de hachage distri-
buées, possèdent plusieurs avantages par rapport à ceux de la deuxième génération et
ceux de la premiere génération, qui sont basés respectivement sur la diffusion et l’index
centralisé, car, le coût de recherche est considérablement diminué. Par nature, les DHTs
maintiennent un équilibrage de charge, mais elles sont difficiles à mettre en œuvre. L’as-
pect sémantique est très loin d’etre implementé avec ces dernières. Le protocole I4N
(Internet à Quatre Niveaux ) que nous avons proposé dans ce chapitre, divise le réseau
des réseaux en des sous réseaux imbriqués, il est équivalent au protocole Chord en coût
P Q
de recherche car ln(n) = (ln(ni )) tel que n = (ni ). Il utilise les DHTs pour générer
uniquement les clés de ressources, celles des nœuds sont construites à base des adresses
IP.
Chapitre III
Les différentes plateformes P2P
3.1 Introduction
Les applications P2P sont en pleine expansion et les programmes P2P actuels im-
plémentent généralement une seule fonction (service réseau), par conséquent, elles sont
incapables d’échanger directement des données avec d’autres applications similaires (par
exemple eDonkey avec KazaA ). Ainsi, les applications P2P ne peuvent fonctionner que
sur une seule plateforme, ce qui est contradictoire avec le principe des systèmes P2P.
C’est pour ces raisons que plusieurs plateformes P2P ont été proposées.
3.2 XtremWeb
XtremWeb est une plateforme expérimentale de global Computing à l’université
paris-sud. L’idée derrière le global computing est de récupérer le temps libre des ordi-
nateurs connectés à Internet, ces ordinateurs étant repartis à travers le monde. L’ob-
jectif principal de XtremWeb est la conception et le développement d’un environne-
ment de calcul pair à pair et d’exécuter d’une manière complètement distribuée de
très grosses applications pluridisciplinaires. XtremWeb est destinée à des applications
de types SPMD1 (Single Program Multiple Data), ce type d’applications est aisé à
la distribution. On divise le programme en des morceaux de codes indépendants et
on les distribue chacun sur un peer. Avec XtremWeb, les participants ne réalisent pas
1
SPMD est une sous classe de SIMD
39
Chapitre 3 : Les différentes plateformes P2P 40
seulement la tache de calcul, mais ils peuvent aussi proposer leurs applications qui né-
cessitent une puissance de calcul pour être distribuées.
XtremWeb nécessite sur chaque peer un ensemble de serveurs et d’applications (Ap-
pache, PHP, MySQL). Ces besoins logiciels sont difficilement compatibles avec des
petites machines comme les PDAs.
XtremWeb peut être utilisée de deux manières différentes :
1. Volontaire : Un volontaire s’enregistre d’abord sur un serveur d’administration

d’XtremWeb, télécharge l’application et l’installe en local ou en réseau. Pendant
le temps d’oisiveté, ces machines peuvent collaborer pour un calcul global.
2. Collaborateur : Un collaborateur aussi s’enregistre sur un serveur d’administra-

tion d’XtremWeb, les collaborateurs téléchargent des applications leurs permet-
tant de configurer leur propre application. Lorsque un collaborateur n’a pas une
tache à exécuter et aucun travail à envoyer à sa communauté de PCs, il fonctionne
comme étant un client formant un P2P computing.
3.2.1 Principe de fonctionnement

XtremWeb distingue trois rôles essentiels pour un pair : Client, Serveur et Worker .
Le rôle principal de serveur, appelé également coordinateur est d’assurer la mise en
relation entre les demandes de ressources du calcul émanant des clients et les ressources
mises à leurs dispositions par les Workers. Le rôle de Worker est de fournir les ressources
de machine d’un utilisateur pour l’exécution d’un calcul XtremWeb. Un client soumet
une tache en fournissant la référence de l’application et l’ensemble des paramètres qui la
définissent. L’une des limites de la plateforme est l’absence d’un mécanisme permettant
aux Workers d’échanger directement ou indirectement des données [35].
Comme tous les environnements de calcul global en particulier et de P2P en général,
XtremWeb doit satisfaire des contraintes sévères [5] :
1. Extensibilité : Le système doit être extensible jusqu’à des centaines de milliers

de nœuds avec une augmentation de performances correspondantes.
2. Hétérogénéité : Les machines possèdent des configurations matériels et des
configurations systèmes très variées.
3. Dynamicité : La communication dans le système varie constamment, ainsi que
la latence et le débit de communications.
4. Disponibilité : Le propriétaire d’une ressource doit pouvoir définir une politique

qui limite la contribution de sa ressource, le système de calcul global doit respecter
cette politique.
5. Tolérance aux pannes : Une défaillance de serveurs de calcul ou de collecteur
de résultats ne doit pas avoir d’incidences sur les machines de calcul. La perte
d’une machine participante ou d’un ensemble de machines participantes est un
événement intrinsèque au système.
6. Utilisabilité : Le système doit être simple à utiliser, à déployer et à maintenir.
7. Sécurité : Les machines participantes et les données doivent être sécurisées.
3.3 ProActive
ProActive est une bibliothèque JAVA pour le calcul parallèle, distribué et concurrent,
prenant en charge la mobilité et la sécurité sur des grilles de calcul. Elle est développée
à l’université Sophia Antipolis de Nice, elle offre un ensemble de primitives et des APIs
de programmation pour faciliter la mise en œuvre des applications distribuées sur des
LANs, des clusters, ainsi que sur des grilles de calcul.
ProActive repose sur le modèle MIMD (Multiple Instruction Multiple Data), elle
est basée sur le concept d’Objet Actif. Elle s’appuie aussi sur le MOP(Meta Object
Protocol ) et utilise la librairie standard JAVA RMI(Remote Method Invocation) comme
une couche de transport portable.

Le développement et la distribution des applications concurrentes en utilisant ProAc-
tive sont basés sur les objets actifs (AO), chaque objet actif a son thread qui execute ses
propres méthodes invoquées par d’autres AOs. Les AOs peuvent être crées sur n’importe
quel hôte.
3.4 JXTA
La plupart des applications P2P, actuellement existantes, sont dédiées à une seule
fonction ou une seule classe de problèmes, de plus, elles ne peuvent s’exécuter que sur
un seul type d’architecture et elles ne permettent pas de partager directement leurs
ressources avec les autres. C’est dans le cadre de cette problématique que SUN Micro-
system a créé le projet JXTA [37].
Le but de projet JXTA est de créer une plateforme P2P qui permet de construire
simplement, facilement et efficacement un ensemble de services d’applications distri-
buées pour tout dispositif qui pourrait être un pair. JXTA permet aux développeurs de
concentrer sur le développement de leurs applications en créant des logiciels interopé-
rables .

JXTA propose un ensemble de protocoles ouverts pour interconnecter des dispositifs
allant du téléphone cellulaire jusqu’aux serveurs, en faisant abstraction de la topologie
physique. Le fonctionnement repose sur le découpage du réseau réel en réseaux virtuels,
dans lesquels chaque pair peut accéder aux ressources des autres sans se préoccuper de
leur localisation ou de leur environnement d’execution, JXTA propose une base de six
protocoles dans lesquels la communication se fait par des messages XML. On y trouve
les services de découverte des peers, de rendez-vous, d’informations sur les peers, de
communication et de routage.
JXTA est faite pour que toutes ses applications puissent s’exécuter sur n’importe
quelle plateforme (PC, Serveur, PDA, Station de travail, téléphone,...). La philosophie
de JXTA est de fournir les mécanismes de base et de laisser les choix d’implémentation
des applications aux développeurs. Pour ce faire JXTA s’appuie sur des standards tels
que XML, JAVA.
3.5 Conclusion
Différents protocoles P2P ont été proposés dans la littérature, chacun d’eux a ses
avantages et ses inconvénients. L’inconvenient principal de ces protocoles dans les ré-
seaux P2P est qu’ils sont indépendants les uns des autres, ils sont incapables d’échanger
des services, chacun d’eux crée sa communauté d’utilisateurs. Pour ces raisons, plusieurs
plateformes P2P ont été proposées ces dernières années, malheureusement, la majorité
de ces plateformes sont dédiées à une classe de problèmes limitée, comme par exemple
ProActive pour le calcul global et le Grid computing. La plateforme la plus généraliste
est JXTA, dans laquelle la plupart des services peuvent être implémentés, comme le
partage de fichiers, la messagerie instantanée , la téléphonie IP, le calcul distribué, etc.
Chapitre IV
Les Réseaux P2P et la technologie
JXTA
4.1 Introduction
Le vocabulaire Peer to Peer (P2P ) est aujourd’hui un des mots les plus à la mode.
Il n’est pas un nouveau concept, il existe depuis l’apparition de l’Internet en 1970 [18].
Ces dernières années, il a attiré l’attention des industrielles et des universitaires. Cette
nouvelle technologie est de plus en plus utilisée, elle constitue une méthode efficace
de partage de ressources entre membres d’une même communauté. Par ailleurs, en
plus des utilisateurs grand public les plus connus (partage des fichiers et messagerie
instantanée), cette technologie peut résoudre un ensemble de problèmes liés à l’utili-
sation optimale des ressources disponibles dans les réseaux et les entités constituant
ceux-ci. Le P2P peut être défini comme étant le partage des ressources par l’échange
direct entre peers. Cependant, aujourd’hui, les implémentations d’architectures P2P
sont non-intérropérables et en générale sont limitées à des plateformes dédiées. C’est
dans l’optique de supprimer ces défauts que Sun Microsystem a proposé le framework
peer-to-peer Open Source JXTA.
43
Chapitre 4 : Les Réseaux P2P et la technologie JXTA 44
4.2 Le Projet JXTA

La technologie JXTA est une plateforme de calcul et de programmation réseau,
désignée pour résoudre un ensemble de problèmes dans le calcul distribué moderne [17],
spécialement dans les réseaux Peer-to-Peer (P2P ). C’est une panoplie de protocoles qui
facilitent la communication P2P.
4.2.1 Les Objectifs de projet JXTA

L’originalité du Projet JXTA est Sun MicroSystem, il est conçu pour répondre aux
objectifs suivants :
4.2.1.1 Interopérabilité
Plusieurs systèmes peer-to-peer ont été conçus pour un seul type de service, comme
à titre d’exemple Napster pour le partage de musique, Gnutella pour le partage des
fichiers, AIM pour la messagerie instantanée, Skype pour la téléphonie IP, etc. Chaque
système construit sa propre communauté d’utilisateurs dans le réseau des réseaux. Pour
qu’un peer profite des autres communautés dont il n’appartient pas, il faut qu’il soit
capable de supporter les différentes implémentations des réseaux peer-to-peer. JXTA
permet à tous les peers de toutes les communautés de communiquer entre eux grâce à
une même plateforme P2P.
Citation : "le projet JXTA a pour but d’offrir au monde de P2P ce que le browser
a apporté à Internet".
4.2.1.2 L’indépendance de plateformes
JXTA est indépendante de tout langage de programmation (Java, C, Perl,...), de

tout système d’exploitation (Unix, Windows, Solaris,...), ainsi que de toute technologie
réseau (TCP/IP, UDP, WiFi, ...).
4.2.1.3 Ubiquité
Elle matérialise le désir que le framework JXTA soit implémentable sur n’importe
quel périphérique doté d’un cœur digital : Des sensous, l’électronique grand public, les
PDAs, les GSMs, les routeurs réseaux, les ordinateurs du bureau et les serveurs, ...
4.2.1.4 Sécurité
La sécurité a été prise en compte à différents niveaux dès le noyau JXTA.
4.2.2 Les concepts de la technologie JXTA
4.2.2.1 Les identificateurs
JXTA utilise un identificateur UUID de 128 bits pour référencer n’importe quelle
entité dans le réseau (Peer, Advestissement, Service, ...). Toutes les ressources dans
JXTA utilisent un UUID unique, l’unicité de UUID est indépendante du temps et de
l’emplacement [20]. Ils existent deux identificateurs spécifiques : null et NetPeerGrou-
pID.
Un exemple d’identificateur d’un peer est :
urn :jxta :uuid-59616261646162614A78746150325033F3BC76FF13C24414CBC0AB6
63666DA53903.
Un exemple d’identificateur de pipe est :
urn :jxta :uuid-59616261646162614E504720503250338E3E786229EA460DADC1A17
6B69B731504
4.2.2.2 Peers
Le peer peut représenter n’importe quelle entité dans le réseau, il peut être un
processeur, processus, machine, routeur, utilisateur, etc. Ils existent plusieurs types de
peers : un simple peer, RendezVous peer, peer Router, Relay peer, etc. Un peer JXTA
Ouvrir renseigner obtenir ouvrir

publier ses les pipes
Boostrap joindre le groupe input sur les output
Adv pipe autres peers Adv pipe
charger les classes de charger le groupe Adv publier charger charger charger lier
la plateforme JXTA
instancier le groupe localement les pipes adv le peer adv les pipes adv
rejoindre le goupe l’extrémité
par defaut demande d’adhésion publier ouvrir obtenir les obtenir les
ouvrir listener sockets joindre le groupe à distance input end de sortie
peers éloignés
etc pipes éloignées
Fig. 4.1 – Les opérations de base d’un peer
nécessite d’effectuer une série d’opérations pour joindre et participer dans le réseau
JXTA [19] (figure 4.1) :
1. Boostrap dans la plateforme JXTA
2. Joindre un peerGroup
3. Publie ses advertissements

4. Ouvre un input pipe
5. Renseigne sur les autres peers
6. Obtenir des pipes advertissements
7. Ouvre un output pipe
4.2.2.3 Advertissement
C’est un document XML structuré pour nommer, décrire et annoncer les ressources
comme le peer, peerGroup, pipe, etc. Toutes les ressources réseaux sont des advertisse-
ments. La technologie JXTA définit un ensemble d’advertissements de base [16].
1. Peer Advertissement : décrit les ressources de peers. L’utilisation principale

de ce type d’Advertissement est pour contenir les informations spécifiques à un
peer comme son nom et son identificateur.
2. PeerGroup Advertissement : décrit les ressources spécifiques à un peerGroup
comme son nom, son identificateur et la description de ses services.
3. Pipe Advertissement : décrit le canal de communication de pipe, il est utilisé
par les services de pipes pour créer et associer un input pipe end points et un
output pipe end points. Chaque pipe Advertissement contient un identificateur
unique, ainsi que son type (point à point, propagé, sécurisé).
4. Module Class Advertissement : pour décrire un module class.
5. Module Specification Advertissement : pour définir un module specification.
6. Module Implementation Advertissement : définit une implémentation d’un
module de specification.
7. Rendez-vous Advertissement : décrit le peer qui est défini comme un rendez-
vous peer d’un peerGroup.
8. Peer Information Advertissement : pour décrire les informations de res-
sources d’un peer, elle est utilisée principalement pour contenir des informations
spécifiques à l’état courante d’un peer.
4.2.2.4 PeerGroup
C’est une entité virtuelle, constituée d’une collection de peers qui partagent les
mêmes intérêts. Les peerGroups subdivisent le réseau en des régions sécurisées qui ne
respectent pas les frontières physiques du réseau. les peers s’auto-organisent dans un
peerGroup identifié par un seul identificateur. Un peer peut appartenir à un ou plu-

sieurs peerGoups simultanément. Tout peer appartient au groupe par défaut qui est le
netPeerGroup. JXTA ne dicte pas où, quand et pourquoi les peerGroups sont créés, elle
décrit seulement comment un peerGroup est créé, publié et découvert [64].
Il y a plusieurs motivations pour créer les peerGroups [40] :
• Pour créer un environnement sécurisé : Le groupe crée un contrôle de

domaine local, renforcé par une politique de sécurité spécifique qui peut varier
d’un simple nom d’utilisateur avec un mot de passe, jusqu’a l’utilisation des al-
gorithmes de cryptographie à clé publique.
• Pour créer un environnement étendu : Un groupe permet de créer une

spécialisation dans un domaine local. Par exemple pour le partage des ressources
(fichiers, CPU, memoire, ...), les frontières de peerGroup définissent la portée de
recherche de contenu d’un peerGroup .
• Pour créer un environnement surveillé : Permet de surveiller un ensemble

de peers pour un but spécial.
Les services de peerGroup : ils existent plusieurs services pour le peerGoup :
1. Les services de découverte : Le service de découverte est employé par les

peers pour chercher des ressources de peerGroup tels que : Les peers, peerGroups,
les pipes, les services,...
2. Les services des adhérents (Membership service) : Ils sont utilisés par les
membres courants de peerGroup pour accepter ou rejeter une demande d’adhé-
sion au peerGoup (c’est-à-dire pour permettre à un nouveau peer de joindre un
peerGoup). Les peers voulant joindre un peerGroup doivent découvrir au moins
un membre de ce dernier, puis lui demandent de se joindre. Cette demande est
acceptée ou rejetée par l’ensemble collectif de tous les membres courants de ce
peerGoup ou par un représentant de ce dernier.
3. Service d’accès : les services d’accès sont utilisés par les peers pour valider les
requêtes provenant d’un autre peer. Le peer qui reçoit la requête, vérifie si celui
qui a envoyé la requête est autorisé ou non (le service d’accès est limité à quelques
actions pour quelques peers dans le peerGoup).
4. Le service de pipe : les services de pipe sont utilisés pour créer et gérer les
connexions entre les membres d’un peerGroup.
5. Resolver service : ce type de services est utilisé pour envoyer des requêtes
génériques aux autres peers. La figure 4.2 est un exemple de resolver service.
Peer Requête 1
H1 Réponse 1
H2 Requête 2
Resolver service
Fig. 4.2 – Le resolver Service pour les requêtes
6. Monitoring service : ils sont utilisés pour autoriser un peer de surveiller les
membres d’un même peerGroup.
4.2.2.5 Module
C’est une abstraction utilisée pour représenter une pièce du code afin d’implementer
un comportement dans la plateforme JXTA. Un module peut être une classe JAVA, un
fichier JAR, DLL, un ensemble de messages XML ou un script. Il y a trois types de
modules dans la plateforme JXTA :
1. Module Class : le module class est principalement utilisé pour publier un

comportement. Chaque module class est identifié par un identificateur unique
(ModuleClassID).
2. Module Specification : il est utilisé principalement pour accéder au module,

il contient tous les informations nécessaires pour accéder et invoquer ce module.
Dans le cas d’un service, le module specification contient un pipe advertissement
lui permettant de communiquer avec ce service. Chaque module specification est
identifié par un identificateur unique (ModuleSpecID).
3. Module Implementation : c’est une implémentation d’un module specifica-

tion, chaque module implementation contient le ModuleSpecID de la specification
associée qu’il implémente.
4.2.2.6 Pipe
C’est un canal de communication asynchrone, unidirectionnel pour envoyer et rece-

voir des messages, donc il y a des pipes d’émission (Input pipe) et des pipes de réception
(Output pipe). Il y a deux mode d’opérations de pipe : unicast et propagé. Les pipes uni-
cast pour la communication un à un, alors que les pipes propagées c’est pour connecter
un peer émetteur avec plusieurs peers récepteurs (figure 4.3).
Input End Peer B
Output End Input End

Input End Peer C
Peer A Peer B Peer A
Input End
Peer D
Les pipes JXTA unicast Les pipes JXTA propagées
Fig. 4.3 – Les Types de Pipes JXTA
4.2.2.7 Message
L’information à transmettre à l’aide des pipes est empaquetée comme message (figure
4.4). Les messages sont les unités d’échange de données entre les peers, ils définissent une
enveloppe pour transférer n’importe quelle genre de données. Les peers communiquent
avec des messages XML ou binaires. Les liens entre les nœuds représentent les canaux
de communication (pipes), ils peuvent être de type 1 à 1, 1 à N, N à 1 ou N à N.
Peer source Input pipe Output pipe peer destination

EndPoint EndPoint
Message Pipe Message
Fig. 4.4 – La communication entre les peers.

4.2.3 L’architecture de la plateforme JXTA

JXTA est composée de trois couches : couche noyau, couche service et couche ap-
plication. Ces différentes couches sont représentées sur la figure 4.5.
Couche Application
JXTA community applications
JXTA
Couche Service Schell
JXTA community services
Couche Noyau
PeerGroup Pipes PeerMonitoring
Sécurité
Fig. 4.5 – L’architecture logique de la plateforme JXTA
4.2.3.1 La couche Noyau
Cette couche encapsule les primitives minimales et essentielles qui sont communes
à la gestion des réseaux P2P, y compris les peers, les peeerGroups, la découverte, la
communication, la surveillance ainsi que des primitives associées à la sécurité. Elle offre
les mécanismes de base tels que : Les PeerGroups, les Pipes et le Peer Monitoring.
4.2.3.2 La couche Service
Elle permet d’étendre les mécanismes de base offerts par la couche noyau, donc elle
les rend de plus haut niveau. Les principaux services proposés dans cette couche sont :
Les mécanismes de recherche, d’indexation, de partage de ressources, de stockage, de
traduction de protocoles et d’authentification.
4.2.3.3 La couche Application
Au sein de cette couche, les applications seront développées à base des services
disponibles dans la couche service accédant aux mécanismes de base fournis dans la
couche noyau, elle inclut la messagerie instantanée et les systèmes d’E-mail de P2P.
4.2.4 Les protocoles de la plateforme JXTA

JXTA est composée de six protocoles indépendants de langage de programmation,
ainsi que des protocoles de transport [40]. Les protocoles JXTA standardisent la manière
pour laquelle chaque peer peut découvrir les autres, s’auto-organise dans les peerGroups,
découvre les services dans le réseau, communique avec les autres peers et surveille chacun
d’eux.
4.2.4.1 Peer Discover Protocol (PDP)
PDP est utilisé par le peer pour publier ses propres ressources et découvre celles
des autres peers ou peerGroups. Les ressources sont décrites et publiées par des adver-
tissements. PDP constitue le protocole de découverte par défaut du WorldPeerGroup.
Il fournit des mécanismes de base permettant la découverte des advertissements tout
en servant de support à la conception éventuelle du service de découverte spécifique au
groupe et ayant une meilleure connaissance de la topologie du groupe. PDP utilise PRP
pour envoyer ses requêtes et recevoir les réponses, il travaille en mode "Best effort"1 .
4.2.4.2 Peer Resolver Protocol (PRP)
PRP permet d’envoyer une requête à un ou plusieurs peers et recevoir une ou plu-
sieurs réponses à une requête. Les requêtes peuvent être dirigées à tous les peers du
PeerGroup (Broadcast) ou à des peers spécifiques à l’intérieur d’un PeerGroup (Multi-
cast).
4.2.4.3 Peer Information Protocol (PIP)
Le Peer Information Protocol permet d’obtenir au moyen d’échange de messages

des informations sur les capacités et les statuts des autres peers. PIP est un protocole
optionnel (les peers ne sont pas obligés de répondre à ses requêtes).
4.2.4.4 Rendez vous protocol (RVP)
Le Rendez vous protocol est utilisé par PRP et PBP pour propager les messages.
4.2.4.5 Pipe binding Protocol (PBP)
Le Pipe Binding Protocol permet aux peers d’établir un canal de communication

virtuel ou pipe entre un ou plusieurs peers. Il sert à attacher deux ou plusieurs pipes
1
je fait de mon mieux
endpoint en fonction des advertissements recus ou envoyés et cela, quel que soit le type
de couche transport du peer endpoint (HTTP, TCP, UDP,...).
4.2.4.6 Endpoint routing Protocol (ERP)
Le Endpoint Routing Protocol permet à un peer de trouver les routes disponibles

pour l’envoi d’un message à un autre peer. Pour obtenir ces routes, le peer émetteur
interroge un peer Router, ce dernier lui fournit une liste de peer Routers menant jus-
qu’au peer de destination. Lorsque un peer doit envoyer un message jusqu’a un peer
Endpoint déterminé, il vérifie tout d’abord dans sa cache locale s’il connait déjà une
route menant à ce peer Endpoint. Si ce n’est pas le cas, il envoie un message contenant
une requête de résolution de route aux peer Routers qu’il connaît. Suite à la réception
d’une requête de résolution de route, si un peer router connaît une requête menant à
la destination, il répond à la requête en retournant l’information de route (une liste
ordonnée du peers routers amenant à la destination finale) qui sera utilisée par l’émet-
teur du message et les peers intermédiaires. S’il ne connaît pas de route, il effectue une
recherche auprès des peers routers auxquels il est connecté. Ce mécanisme est récursif,
car à chaque peer intermédiaire, si la route d’un message est obsolète elle nécessitera
une nouvelle recherche de route.
Chacun des protocoles JXTA est indépendant des autres, un peer n’a pas besoin
d’implementer tous ces protocoles pour être un peer JXTA, il met en application seule-
ment les protocoles qu’il va utiliser. Par exemple, un peer peut utiliser un ensemble
préconfiguré de peers pour envoyer ses messages, donc il n’a pas besion de mettre en
application le protocole ERP. Un peer peut décider de cacher des annonces découvertes
par le protocole PDP pour une utilisation postérieure, car ceci peut conduire à une
optimisation non négligente devant une deuxième recherche.
4.2.5 Le transport de messages Dans JXTA

Le transport des messages dans JXTA peut se faire de trois manières :
4.2.5.1 Le transport des messages sous TCP/IP
Les deux participants opèrent d’une manière symétrique. Les séquences de messages
suivent les quatre phases suivantes : Ouverture de la connexion, message Welcome,
message(s) et fermeture de la connexion.
4.2.5.2 Le transport de messages sous HTTP
Le transport de messages via HTTP [13] est logiquement divisé en deux fonctions :
l’initiateur et le récepteur. L’initiateur peut établir des raccordements, tandis que le
récepteur peut accepter des raccordements.
4.2.5.3 Le transport de messages sous TLS
Le TLS virtuel transport [8] implémente un transport sécurisé et bi-directionnel au

dessus de HTTP ou TCP/IP. Une authentification doit être faite par l’obtention d’un
certificat de root de peer avec lequel va se faire la communication sécurisée, ce certificat
contient une clé publique RSA de 1024 bits [64].
4.2.6 Les mécanismes de découverte dans la plateforme JXTA

Il y a plusieurs manières pour la découverte de services dans la plateforme JXTA [16].
4.2.6.1 Découverte basée sur le réseau local
C’est par l’envoi en multicast vers tous les peers dans le LAN.
4.2.6.2 La découverte par les invitations
Si un peer reçoit une invitation (de l’intérieur du réseau local ou de l’extérieur ),

l’information de peer qui est dans l’invitation peut être utilisée pour découvrir le peer
qui a envoyé l’invitation.
4.2.6.3 La découverte en cascade
Si un peer découvre un nouveau peer en utilisant les permissions de ce dernier, le

premier peer peut découvrir des nouveaux peers, groupes et services,...
4.2.6.4 La découverte par les points de rendez-vous
Un point de rendez-vous est un peer spécial qui a des informations supplémentaires

sur un ensemble de peers.
4.2.7 Le Shell JXTA

Le Shell JXTA est un outil (application P2P ) construit au dessus de la plateforme
JXTA [39]. Il est situé à cheval sur les couches service et application, il offre une inter-
face en ligne de commande semblable au Shell Unix et des commandes facilitant l’accès
au noyau JXTA, tel que lister les peers accessibles dans le PeerGroup du peer.
Comme le Shell UNIX, le Shell JXTA permet par une simple interface de ligne
de commandes, l’accès interactif à la plateforme JXTA. Contrairement au Shell Unix
où les commandes sont conçues pour être exécutées dans un environnement local, les
commandes de Shell JXTA sont conçues pour être exécutées dans un environnement
réseau [16]. En utilisant l’interpréteur de commandes Shell, les utilisateurs peuvent
travailler de façon interactive avec la plateforme JXTA pour publier, rechercher et exé-
cuter des codats 2 , découvrir des nouveaux peers ou peerGroups, créer des pipes pour
connecter deux peers, envoyer et recevoir des messages.
Le Shell JXTA est limité à un ensemble de commandes. Chaque commande est

composée d’un nom suivi par des options et des arguments séparées par des blancs. Ces
commandes sont choisies de telle manière à être similaires à celles de Shell UNIX (eg :
ls,cat,etc. )[38].
4.2.7.1 La syntaxe des commandes de JXTAShell
Chaque commande a la syntaxe suivante :
Command [< pipe] [>pipe] options arguments ;

avec :
– < : pour la redirection de la sortie de la commande.
– > : pour la redirection de l’entrée de la commande.
– : : pour séparer l’ensemble des commandes.
4.2.7.2 Les commandes de base de JXTAShell
Les opérations de base dans la plateforme JXTA ont été implementées par des
commandes telles que : Shell, cat, env, exit, groups, leave, newpipe, peers, rev, man,
etc. La commande man permet d’énumérer les différentes commandes de JXTA avec
des indications d’utilisation.
2
codat : données de n’importe quel contenu
4.2.7.3 Ajout des nouvelles commandes au JXTAShell
Toutes les commandes de Shell sont dans le package net.jxta.impl.shell.bin. Pour une
nouvelle commande, le fichier de la classe JAVA correspondante doit être copié dans
le repertoire Shell bin class. Il n’est pas nécessaire de recompiler le Shell JXTA pour
prendre en compte la nouvelle commande [36].
Le programme suivant décrit comment construire et ajouter une nouvelle commande

au Shell JXTA.
Algorithm 7 Programme d’ajout d’une nouvelle commande au Shell JXTA

1 : Package net.jxta.impl.shell.bin.myHelloWorld
2 : public class myHelloWorld extends ShellApp {
3 : private ShellEnv myEnv ;
4 : public int startApp (String[]args) { //args est l’argument de la commande.
5 : myEnv = getEnv() ; // récupérer l’environnement de commandes
// extraire le peerGroup courant de l’environment
6 : ShellObject obj = myEnv.get ("stdgroup") ;
7 : PeerGroup group = (PeerGroup) obj.getObject() ;
8 : if (args == null) {//println écrit sur le console
9 : println("Hello my peergroup is" + group.toString()) ;
10 : } else { // aucun argument n’est autorisé
11 : println ("Sorry no argument supported !") ;
12 : } return ShellApp.appNoError ;
13 : }
14 : public void stopApp () {
// rien à faire ici
15 : }
16 : }
4.2.8 La sécurité dans la plateforme JXTA

Pour la confidentialité, seulement une personne autorisée peut lire le message. Pour
l’authentification, l’expéditeur est celui qui prétend être. Pour l’autorisation, l’expé-
diteur est autorisé à envoyer des messages. Pour l’intégrité, pas de changement des
messages durant le transfert. En ce qui concerne la réfutation, le message est envoyé
par un expéditeur identifié, c’est pas une copie d’une réponse transférée précédemment.
4.2.9 Les Firewalls et les NATs

Un peer derrière un firewall (figure 4.6) peut envoyer un message directement à un
autre peer à l’extérieur de firewall, mais ce dernier ne peut pas établir une connexion
directe avec le peer qui est derrière le firewall. Lorsque un peer reçoit une réponse posi-
tive à une recherche, de la part d’un autre peer situé derrière un firewall, la connexion
directe ne pourra pas être établie, dans ce cas, ce dernier initiera le téléchargement.
1111
0000
Internet
0000
1111
Peer C
Relay
Firewall
Peer B
Peer A
Fig. 4.6 – La communication P2P avec la présence des firewalls
La figure 4.6 décrit un scénario de routage de messages à travers les firewalls. Les
peers A et B veulent communiquer entre eux, mais le firewall ne permet pas d’établir
une connexion directe. Pour cela, le peer A contacte le peer C en utilisant un protocole
qui permet de pénétrer le firewall comme HTTP. De sa part, le peer C contacte le peer
B en utilisant un protocole comme TCP/IP, par conséquent une connexion virtuelle
sera établie entre le peer A et le peer B par l’intermédiaire de peer C.
4.3 Conclusion
Les architectures P2P précédemment décrites constituent chacune un système dis-
tinct, incapables de communiquer entre eux. Au vue de ce constat, certaines entreprises,
telle que Sun Micro System ont entrepris des efforts de standardisation des protocoles
de communication, indépendants des systèmes d’exploitations et des langages de pro-
grammation comme JXTA.
JXTA est une plateforme de programmation réseau, elle est destinée à être la fon-
dation des systèmes peer-to-peer, elle est définie comme étant un ensemble de six pro-
tocoles. Cette technologie est aussi indépendante des protocoles de transport (TCP/IP,
HTTP, ...), des systèmes d’exploitation (Linux, Windows, Solaris,...), ainsi que des
langages de programmation (Java, C/C++, Perl,...).
JXTA s’appuie sur des standart ouvert tels que XML, JAVA et sur les concepts
qui font d’UNIX un puissant et fléxible systéme d’exploitation : Shell avec commandes
intéroperables, ainsi que l’utilisation de pipes pour accomplir des taches complexes.
Chapitre V
Performance de la plateforme JXTA à
grande échelle
5.1 Introduction
La plateforme JXTA est un ensemble de protocole P2P généralisés et open sources,
qui permettent de faire communiquer n’importes quels appareils dans le réseau (PDA,
PC, Serveur, ...). C’est un réseau ad hoc, les peers peuvent joindre ou quitter le réseau
JXTA en n’importe quel moment. Comme la majorité des applications dans les réseaux
P2P, JXTA à ses propres méthodes de découverte et de localisation de services [4].
5.2 Index distribué de partage de ressources (SRDI)

La plateforme JXTA implémente le service de partage de ressources pour fournir un
mécanisme efficace de recherche de données, basé sur la propagation des requêtes dans
le réseau JXTA (figure 5.1). Le rendez-vous peer maintient un index d’Advertissements
publiées par les edge-peers. Quand ces derniers publient des nouvelles Advertissements
pour leurs rendez-vous, ils utilisent le service SRDI (Shared Ressources Distributed
Index ). Avec l’hiérarchie des rendez-vous edge-peers, les requêtes sont propagées entre
les rendez-vous peers pour réduire d’une manière significative le nombre de peers invo-
qués dans la recherche d’une Advertissement [63]. Chaque rendez-vous peer maintient
sa propre liste de rendez-vous dans le peerGroup.
58
Chapitre 5 : Performance de la plateforme JXTA à grande échelle 59
vers d’autres RDV peers
Requête
Internet
JXTA RDV
JXTA peer
Requête multicast
JXTA peer
JXTA RDV
JXTA RDV
vers d’autres RDV peers
Fig. 5.1 – La propagation des requêtes dans le réseau JXTA
5.3 La recherche distribuée dans le réseau JXTA

La communication dans le réseau JXTA est effectuée via un protocole XML nommé
protocole de routage des requêtes (QRP : Query Routing Protocol ). Ce dernier définit
des mécanismes pour envoyer et répondre aux requêtes, ainsi qu’un mécanisme pour la
définition des meta-données dans les nœuds. Trois entités peuvent participer dans la
recherche JXTA [66] :
1. JXTA Search Information Providers : C’est une entité qui peut répondre à
une requête composée par le producteur, elle est présentée en QRP, elle peut être
un peer, un serveur web, ...
2. JXTA Search Consumers : C’est une entité qui peut envoyer une requête en
QRP. Un consommateur peut être un peer, un serveur web avec une interface
client HTTP. Il y a deux types de peers consommateurs dans le réseau JXTA
search : JXTA peer consommateur pur et peer web consommateur [46]. la diffé-
rence entre les deux, est que JXTA peer consommateur peut envoyer directement
des requêtes à n’importe quels peers JXTA producteur (les hubs sont inclus) et
reçoit directement les réponses de ces peers. Par contre, le peer web consommateur
doit utiliser un hub comme médiateur pour accomplir les opérations de recherche
et de découverte.
3. JXTA Search Hub : C’est un mécanisme qui facilite le routage des requêtes
d’une manière efficace entre le producteur et le consommateur. Le producteur

enregistre une description avec le hub et attend les requêtes. le consommateur
interroge le réseau via le hub et attend les réponses. Les hubs peuvent être des
producteurs comme ils peuvent être des consommateurs, ces derniers sont enchaî-
nés entre eux.
Le consommateur envoie sa requête au plus proche hub, ce dernier détermine quel

producteur doit recevoir cette requête, il l’envoie au producteur approprié. Quand il
reçoit la réponse, il la renvoie au consommateur demandeur.
5.3.1 Les avantages des approches distribuées

Les méthodes de recherche par les approches distribuées possèdent plusieurs avan-
tages, citons à titre d’exemple : La vitesse de mise à jour, l’accès et l’efficacité.
5.4 La recherche en largeur et la recherche en profon-
deur dans JXTA

JXTA supporte deux types de recherche complémentaires : La recherche en largeur
pour les appareils distribués sur le réseau et la recherche en profondeur pour les index
des ressources comme les serveurs web [66] (figure 5.2).
5.4.1 La recherche en largeur

ils existent des variétés de méthodes pour faire la recherche en largeur. La première
méthode est purement distribuée, dont laquelle un peer envoie ses requêtes à tous les
peers qu’ils connaît. Cette méthode est chère, elle n’est pas efficace dans les réseaux à
grande échelle, car il y a une mauvaise utilisation de la bande passante. La deuxième
méthode est basée sur un peer serveur, ce dernier envoie toutes ses requêtes pour tous
les peers. Cette méthode présente des inconvénients comme la présence de point de
défaillance (le peer serveur ), ainsi qu’un goulot d’étranglement au niveau de ce serveur.
JXTA utilise un mécanisme efficace pour les requêtes distribuées en largeur, c’est un
compromis entre les deux méthodes extrêmes précédentes, il consiste en une série de
peers hub, chacun d’eux est responsable des requêtes d’un groupe de peers. Chaque
peer hub fait suivre la requête aux autres peers hub si cette dernière n’est pas satisfaite
ou si la requête vise un très grand nombre de peers.
5.4.2 La recherche en profondeur

JXTA est également conçue pour faire des recherches en profondeur comme les
moteurs de recherche (Google), car c’est une manière idéale pour l’indexation statique,
où les serveurs et les stations de travails changent lentement.
SGBD
Internet Serveur Web
Station de travail PC
PDA Téléphone IPPhone
Fig. 5.2 – La recherche en profondeur et en largeur dans JXTA
5.5 L’architecture de la recherche JXTA
5.5.1 Les objectifs de JXTA search

Pour une recherche efficace dans le réseau, JXTA vise les objectifs suivants :
• La simplicité : Une configuration minimale dans les applications pour utiliser

les bibliothèques JXTA.
• La structuration : Toutes les requêtes dans JXTA sont construites à l’aide des
messages XML.
• L’extensibilité : Des queryspace (voir section 5.5.2) peuvent être utilisées dans
le réseau de recherche JXTA, il n’ y a aucun besoin de centraliser la gestion de
ces queryspaces, simplifiant ainsi la collaboration ad hoc.
• La scalabilité : Le réseau JXTA est conçu pour supporter des millions d’uti-
lisateurs (producteurs et consommateurs) qui peuvent effectuer des milliards de
transactions par jour [66], supportant ainsi la scalabilité .
5.5.2 Les composantes de JXTA search

¨ Query routing protocol (QRP) : C’est un protocole en XML basé sur trois
composantes : les requêtes, réponses et les registrations.
1.Requête (Query messages) : Un exemple de query messages est le suivant :
< ?xml version=0 1.00 ?>

<request xmlns= http ://search.jxta.org
xmlns :t= http ://search.jxta.org/text
query-uuid= 1C8DAC3036A811D584AEC2C23
query-space= http ://search.jxta.org/text>
<t :query>
<t :text>
Messages
</t :text>
</t :query>
</request>
2. Réponse (Response messages) : Un exemple de response messages est le

suivant :

<responses xmlns= http ://search.jxta.org
xmlns :t= http ://search.jxta.org/tickerqs
query-uuid= 1C8DAC3036A811D584AEC2C23 >
<response>
<data>
<t :ticker>
Messages
</t :ticker>
<t :price>
20.59
</t :price>
</data>
</response>
</responses>
3. Registration (Registration messages : Un exemple de registration mes-

sages est le suivant :

<register xmlns= http ://search.jxta.org >
<title>JXTA Stock Quote Provider</title>
<link>http ://search.jxta.org</link>
<description>Given a ticker symbol, returns a 15-minute delayed quote
</description>
<query-server>jxta ://
59616261646162614A757874614D5047CF403C5700D44AE68F9FB626DD3F
18E500000000000000000000000000000000000000000000000000000000
00000401</query-server>
<query-space uri="http ://search.jxta.org/text">
<predicate>
<query>
<text>Messages</text>
</query>
</predicate>
</query-space>
</register>
¨ Queryspace : Une Queryspace est utilisée pour définir la structure d’une re-
quête valide en XML, car les données stockées sont de natures différentes. Elle
est destinée pour faire la coordination entre le producteur et le consommateur.
Queryspace doit incorporer les informations suivantes :
1. Structure : Pour spécifier des contraintes structurelles dans une forme

standard comme XML.
2. Semantics : Le producteur et le consommateur doivent être d’accord sur
le sens des messages interchangés.
3. Ranking : C’est pour classifier les résultats reçus par un client.
¨ Registration : La registration est une déclaration logique écrite en XML, carac-

térisée par un Queryspace. Le producteur s’enregistre dans le réseau de recherche
JXTA, identifie les requêtes auxquelles il souhaite répondre.
¨ Query formulation (formulation des requêtes) : Les utilisateurs et les ap-

plications présentent leurs requêtes au réseau JXTA en tant que XML arbitraire
adhérer à des Queryspaces spécifiques.
¨ Query resolution (résolution des requêtes) : Le resolver résout les requêtes

par une comparaison des termes de requête avec ceux de la registration. Le
consommateur dont ses termes de registration correspondent aux termes de re-
quête est retourné par le resolver.
¨ Query routing (routage des requêtes) : Les requêtes sont routées vers les
producteurs appropriés par l’envoi des messages XML au dessus de HTTP. Le
routeur envoie toutes les requêtes et attend les réponses, il surveille continuelle-
ment les producteurs pour déterminer la disponibilité et la fiabilité.
¨ Provider responses : les producteurs répondent aux requêtes en XML.
JXTA fournit un mécanisme de recherche efficace par la distribution des requêtes à

travers un réseau large, en utilisant des peers specialisés (Hub). Les Hubs peuvent se
spécialiser par exemple par géographie ou par applications. Les requêtes peuvent être
expédiées du Hub au Hub selon les besoins [65]. La figure 5.3 donne une vue de la
recherche dans JXTA. Le producteur d’information enregistre ses advertissements dans
le Hub, le message de registration contient un Queryspace, un ensemble de prédicats et
l’adresse du producteur. Le Queryspace est l’espace des requêtes pour lesquelles le pro-
ducteur peut répondre. Les prédicats définissent l’index des informations de producteur
exposé au réseau.
5.5.3 Les services de JXTA search

¨ JXTA search provider service : C’est des services qui reçoivent les requêtes
écrites en QRP provenant du hub (ou provenant directement de JXTA search
consumer ) et répondent à ces requêtes en QRP. Le service producteur n’execute
aucune indexation ou recherche interne, mais il appelle directement l’interface
appropriée de producteur lui même, comme JXTA CMS, recherche dans la base
de donnée, etc.
¨ JXTA search Consumer service : C’est des services qui envoient des requêtes
écrites en QRP au hub (ou directement au JXTA search provider ) et attendent
des réponses en QRP. Le service consommateur analyse la réponse pour la pré-
senter à l’utilisateur final ou l’application.
Fig. 5.3 – Le recherche dans JXTA
¨ JXTA search registration service : C’est des services qui envoient des re-
quêtes au hub pour la registration et mettent à jour le fichier d’enregistrement
pour le producteur.
¨ JXTA search Hub service : C’est des services qui sont responsables de rou-
tage des requêtes de consommateur vers le producteur. Le Hub service accepte
les requêtes, les résout aux fournisseurs appropriés, gère leurs routage vers les
producteurs appropriés et envoie les résultats assemblés aux consommateurs de-
mandeurs. Le hub service est constitué de deux composantes :
1. JXTA search router : C’est un software qui route et gère les connections
des requêtes, collecte les résultats et les retourne aux consommateurs.
2. JXTA search resolver : C’est un software qui envoie les requêtes aux
producteurs en utilisant un moteur de recherche à texte integral, il classe les
meta-données indiquées par les fournisseurs durant la registration.
requête registration de
producteur vers le Hub
JXTA JXTA search

registration
peer
Service
requête pour
JXTA search
registration de fichier
Resolver
JXTA imput
JXTA search Pipe JXTA
JXTA JXTA
provider Search
peer JXTA output peer Hub
Service
Pipe
JXTA search
Router
Requête
JXTA JXTA search
consumer réponse
peer
Service
Fig. 5.4 – La recherche distribuée dans la plateforme JXTA
5.6 Conclusion
L’architecture de la plateforme JXTA est très complexe, dont laquelle le réseau est
constitué de plusieurs types de peers (peer simple, rendez-vous peer, peerGoup, edge-
peer, ...). La recherche peut se faire de plusieurs manières. Tous ces aspects doivent être
pris en compte pour une bonne évaluation de performances de cette plateforme.
Chapitre VI
La téléphonie Internet en mode P2P
6.1 Introduction
La téléphonie Internet connue aussi sous le nom "la téléphonie sur IP" complémente
et remplace peu à peu la téléphonie classique [53]. La téléphonie Internet est la livraison
en temps réel de la voix et probablement d’autres types de données et de multimédia
entre deux parties ou plus à travers le réseau, en utilisant les protocoles internet. Le
problème principal est l’efficacité et la rapidité de transmission de la voix et de la vidéo.
Internet offre une infrastructure globale permettant de réaliser quasiment tous les
moyens de communications que nous connaissons actuellement (téléphone, fax, ...). En
comparaison, le RTC (Réseau Téléphonique Commuté) ne permet pas une grande flexi-
bilité, car il repose énormément sur des technologies propriétaires peu adaptées à une
utilisation autre que celles prévues au départ. Par opposition, Internet et sa composi-
tion autours de standards ouverts (tel que TCP/IP, HTTP,...) offre une infrastructure
généraliste et flexible apte à un grand nombre d’utilisations dont beaucoup n’ont pas
été prévues au départ.
Le transport de la voix sur un réseau IP et sur le RTC sont deux opérations radi-
calement différentes. Sur le RTC, la voix est acheminée sous forme d’un flux constant,
alors que sur le réseau IP, ce n’est pas de tout le cas. Le transport sur ce dernier se
fait en découpant la voix en paquets au départ, à envoyer ces paquets avec le protocole
adéquat sur le réseau IP et a tout reconstitué à l’arrivée.
67
Chapitre 6 : La téléphonie Internet en mode P2P 68
La qualité de service (QoS) constitue actuellement un problème pour l’Internet, car

c’est elle qui permet de s’assurer que des données auront un traitement propriétaire sur
d’autres. Cette fonctionnalité est essentielle pour toutes les données utilisées dans une
communication en temps réel.
La téléphonie Internet peut être implémentée au dessus d’une architecture du contrôle

centralisé "Client-Serveur" ou une architecture purement distribuée "Peer-to-Peer",
comme elle peut être implémentée au dessus d’une architecture hybride.
6.2 Généralités sur la téléphonie IP

La téléphonie Internet basée sur l’architecture client-serveur utilise L’IETF SIP
(Session Initiation Protocol ) ou L’ITU-T recommandation H.323, elle est basée sur
l’enregistrement dans un serveur de chaque domaine. L’utilisateur ou (IP Phone) en-
registre son adresse IP dans un serveur. Par l’intermédiaire de ce serveur, les autres
utilisateurs peuvent le contacté.
La téléphonie Internet peut être vue comme une application basée sur une archi-
tecture P2P, où les participants s’auto-organisent dans le système P2P, localisent et
communiquent avec d’autres participants [57].
Les communications téléphoniques imposent des contraintes au réseau que n’im-

posent pas les applications traditionnelles. Parmi ces contraintes on peut citer :
– Délai de transmission (temps de latence) : Il faut que le temps de trans-

port entre l’émetteur et le récepteur soit faible, il devrait être inférieur à 150
ms pour une bonne interactivité. Le retard est engendré principalement par les
routeurs traversés, ainsi que le traitement des éléments logiciels (lors de compres-
sion/décompression, codage/décodage,...).
– Bande passante : Sans compression, la voix nécessite 64 kbps de bande passante.

Avec compression, elle peut être diminuée jusqú’au 5 kbps. Dans ce cas, la qualité
du son est moins bonne. La compression/décompression augmente le temps de
latence.
– La perte de paquets : La voix supporte bien la perte des paquets par rapport
à d’autres applications.
– La gigue : C’est la variation de délai de transmission de l’information, ceci est

dû principalement aux chemins différents traversés par les paquets.
6.2.1 Les phases de la transmission de la voix sur le réseau IP

La transmission de la voix sur le réseau IP (figure 6.1) se déroule en quatre grandes
phases :
¨ Etape 1 : Les données sur Internet sont numériques. Pour cela, la voix doit être
digitalisée en utilisant le téléphone, Service Internet Provider (ISP) ou un PC.
¨ Etape 2 : La voix sous forme digitale est ensuite compressée et divisée en pa-
quets. En utilisant Internet protocol (IP ), ces paquets sont envoyés vers leurs
destinations.
¨ Etape 3 : Durant la transmission sur Internet, les paquets peuvent être retardés,
endommagés ou même complètement perdus. Des éventuelles corrections peuvent
être faites.
¨ Etape 4 : À l’arrivée des paquets, ces derniers seront réassemblés et décompressés
pour constituer la voix initiale.
Aquisition Paquétisation
Numérisation Codage
audio RTP
Internet
Réstitution Mémorisation Réception des

Décodage remise en ordre
audio paquets
des paquets
Recouvrement des
paquets perdus
Fig. 6.1 – La transmission de la voix sur le réseau IP
6.2.2 Le protocole IP (Internet Protocol)

Le protocol IP (Internet Protocol ) [45] à été conçu pour permettre les communica-
tions entre les systèmes informatiques. Sa principale fonction est d’acheminer les paquets
IP à travers l’ensemble des réseaux interconnectés, selon l’interprétation d’une adresse
identifiant les équipements. Le protocole IP s’occupe essentiellement des adresses qui
sont transportées dans l’entête de chaque datagramme et exploitées par les équipements
d’interconnexion pour réaliser le routage.
6.2.3 La téléphonie IP et le RTC

la figure 6.2 montre l’interconnexion entre un réseau IP et le réseau RTC .
Ordinateur
IP
Téléphone
Ethernet
Passerelle
PABX
RTC
Téléphone
IPphone
Fig. 6.2 – La téléphonie IP et le RTC
6.2.4 La pile des protocoles Internet multimédia

La figure 6.3 représente la pile des protocoles internet multimédia.
6.2.4.1 La couche Physique
La couche physique peut être un réseau local Ethernet, une ligne téléphonique (V.90)
en mode point à point (PPP ), ATM, réseau Ad Hoc (802.11),...
6.2.4.2 La couche Internet
Le protocole Internet (IP ) est utilisé dans cette couche pour router les paquets dans
le réseau à leurs destinations, il travaille en mode "best effort".
6.2.4.3 La couche transport
Cette couche utilise deux octets pour le numéro du port afin de délivrer le da-
tagramme à la destination. Quelques ports sont dédiés à des protocoles particuliers.
Signalisation Média Service

SDP Media Encoding
Couche
H.323 SIP RTP DNS DHCP
Application
Couche
Transport TCP UDP
Couche
IP
Internet
AAlx PPP
Couche
ATM V.90 Ethernet 802.11
Physique
Fig. 6.3 – La pile des protocoles Internet Multimédia
Ces ports sont appelés numéro du port "bien connus", par exemple (HTTP utilise le
port bien connu 80, tandis que SIP utilise les numéros du ports bien connus compris
entre 49152 et 65535 ). Trois protocoles sont utilisés dans la couche transport : TCP
(Transmission Control Protocol ), UDP (User Datagram Protocol ) et TLS (Transmission
Layer Sercurity).
6.2.4.4 La couche application
Cette couche inclut les protocoles de signalisation comme SIP (Session Initiation
Protocol ), les protocoles de transport média comme RTP (Real time Transport Protocol ).
H.323 qui est un protocole de signalisation alternatif au SIP, développé par l’union de
télécommunication international (ITU), protocole de description de sessions (SDP),
HTTP, SMTP, FTP et Telnet.
6.2.5 Real time Transport Protocol (RTP) et RTP control pro-
tocol (RTCP)
Real time Transport Protocol [51] est développé pour permettre le transport des
paquets en temps réel contenant la voix, la vidéo et autres informations. Le RTP peut
être véhiculé par des paquets multicast afin d’acheminer des conversations vers des des-
tinataires multiples. Le protocole RTP ne garantit pas l’arrivée des paquets, il n’assure
pas que chaque paquet va arriver, ni à temps, ni en séquence. RTP n’est pas un standard
définissant le type du codage transporté, cette information est décrite dans des descrip-
teurs de profils. Les principaux éléments qui rentrent en compte dans le fonctionnement
de RTP sont :
1. Payload : Les données temps réel transportées par RTP dans un paquet.
2. RTP Paquet : Un paquet de données est constitué d’un entête RTP fixe, d’une
liste de sources participant au flux et de payload.
3. RTCP Paquet : Un paquet de contrôle est constitué d’un entête fixe similaire
à celui de RTP, suivi par des éléments qui dépendent de type de paquet RTCP.
4. Port : Permet de distinguer les différentes destinations de paquets sur la même
machine.
5. Adresse de transport : C’est une combinaison d’une adresse réseau et un port
permettant d’identifier un point de terminaison au niveau transport (ex :Adresse
IP + port UDP ).
6. Session RTP : Association d’un ensemble de participants communiquant via
RTP. Pour chaque participant, la session est définie par un couple d’adresse de
transport (Adresse réseau + port RTP + port RTCP ). Dans le cas de multicast,
l’adresse transport peut être la même pour tous. Dans une session multimédia,
chaque média à sa propre session RTP et ses propres paquets RTCP identifiés par
des ports et/ou adresses multicast différentes.
7. Source de synchronisation (Synchronization Source SSRC) : Source d’un
flux de paquets RTP identifiée par 32 bits dans le header RTP. Tous les paquets
ayant le même SSRC ont une même référence temporelle et de séquencement.
8. Source contributive (Contributing Source CSRC) : Source d’un flux de
paquets RTP qui contribue au flux de sortie d’un mixeur.
RTCP transmet périodiquement des paquets de contrôle aux participants, utilisant

les moyens de diffusion de RTP, simplement avec un numéro de port différent. Il permet
aussi de recevoir des informations de retour des participants grâce aux messages "sender
report" et "receiver report". RTCP diffuse un identificateur pour chaque source RTP
appelé CNAME, c’est cet identificateur qui permet d’attribuer les flux RTP à tel ou tel
participant, car les SSRCs peuvent changer, cela permet aussi de synchroniser les flux
audio et vidéo venant d’un même participant. Ils existent plusieurs types de paquets
RTCP pour chaque type d’information :
1. Sender Report (SR) : Statistiques de transmission et de réception pour les

participants qui sont des émetteurs actifs.
2. Receiver Report : Statistiques de réception pour les participants qui ne sont
pas des émetteurs actifs.
3. SDES : Descripteurs de source dans les CNAMEs.
4. BYE : Fin d’une participation.

5. APP : Fonction spécifique à une application.
Le protocole RTP n’a pas été conçu pour effectuer la réservation de ressources ou
le contrôle de la qualité de service.
6.2.6 Le Protocole de réservation de ressource (RSVP)

RSVP (Ressource réSerVation Protocol ) n’est pas en lui-même un protocole de rou-
tage, mais c’est un protocole qui demande la réservation de ressources en vue d’obtenir
une certaine qualité du service.
6.2.7 Codage de la parole

Le codage de la parole est réalisé dans un premier temps par un prélèvement d’échan-
tillons du signal vocal analogique à un taux d’échantillonnage. Une résolution suffisam-
ment grande pour préserver la qualité désirée, généralement un taux de prélèvement de
8 KHz pour échantillonner la parole (8.000 échantillons par seconde). Le codage de la
parole permet la réduction de débit de transmission du signal et des communications
dans les canaux à largeur de bande limitée. La largeur de bande d’une transmission
devra être minimisée tout en préservant la qualité du signal vocal reconstruit, en ré-
pondant aux autres exigences liées à l’application. Dans le cas de transmission de la
voix sur IP, la réduction du débit limitera le nombre ou la taille des paquets à envoyer
sur le réseau [31].
6.2.7.1 Les techniques de codage
Ils existent trois principales techniques de codage de la parole :
6.2.7.1.1 La technique temporaire : Elle consiste à préserver la forme d’onde

du signal. Différents types du codage entrent dans cette catégorie, la modulation par
impulsion et codage (MIC) où le signal est échantillonné puis l’amplitude quantifiée
suivant des standards de compression (loi A par exemple), c’est le codage RNIS/RTC
à 64 bits/s selon la recommandation G.711 de l’UIT. Dans ce type du codage, le débit
est compris entre 16 et 64 kbit/s [9].
6.2.7.1.2 La technique paramétrique : Cette technique consiste à modéliser sous

forme simplifiée, à l’aide de paramètres pertinents le signal de la parole à la source, de le
transmettre sous forme numérique au récepteur qui se charge de reconstituer un signal
proche du signal initial. Cette technique ne conserve pas la forme temporelle du signal.
Dans ce type de codage le débit est compris entre 16 et 64 kbit/s [9].
6.2.7.1.3 La technique par analyse et synthèse : A l’heure actuelle, c’est la

plus performante et la plus utilisée. Elle utilise de façon complémentaire les avantages
de la technique temporelle et ceux de la technique paramétrique, pour obtenir des débits
faibles tout en préservant la qualité de restitution. Dans ce type de codage le débit est
compris entre 16 et 64 kbit/s [9].
6.2.8 Codecs
Les codecs sont développés pour être des codeurs et des décodeurs de digitalisation
des données analogiques (PCM, GSM,...). Des techniques de compression et de décom-
pression sont ajoutées afin de réduire la bande passante avec préservation de la qualité
de la voix.
6.3 Protocoles de signalisation

Les services multimédia sur IP sont gérés par des protocoles de signalisation assurant
l’établissement, le contrôle et la rupture d’une connexion temps réel. En effet, plusieurs
approches de normalisation existent actuellement pour fixer une qualité de service de
la téléphonie sur IP et permettre l’intéropérabilité des applications et des équipements.
Deux parmi les plus importants standards de la téléphonie IP sont : SIP (Session
Initiation Protocole) et H.323 [27].
6.3.1 SIP (Session Initiation Protocol)

Le protocole d’initiation de session (SIP ) normalisé par l’IETF [21] en 1999 est un
protocole de signalisation appartenant à la couche application du modèle OSI, son rôle
est d’ouvrir, modifier et libérer une session. SIP possède l’avantage de ne pas être at-
taché à un medium particulier, il est sensé être indépendant du protocole de transport
des couches basses. L’ouverture d’une session est nécessaire pour réaliser de l’audio, de
la vidéoconférence, de l’enseignement à distance, de la voix (la téléphonie ) ou de la
diffusion multimédia sur IP.
SIP est un protocole client-serveur, similaire dans la syntaxe et la sémantique à

HTTP[28]. Les requêtes sont envoyées par les clients et les réponses à ces requêtes sont
générées par les serveurs. Dans le cas de la téléphonie IP l’appelant est le client et
l’appelé est le serveur [52].
6.3.1.1 Bref historique du protocole SIP
Le protocole SIP est originalement développé par L’IETF Multi-Party Multimedia

Session Control Working Group, connue sous le nom MMUSIC. La première version du
protocole a été établie en 1997, des améliorations significatives ont été retenues dans
la version 2.0 en 1998. Le protocole SIP a été standardisé en mars 1999 et publié dans
RFC 2543 en avril 1999. Des clarifications et des rectifications de quelques bugs ont
été soumises au début juillet 2000 et publié dans RFC 2543 " Bis ", le RFC 3261 a
remplacé le RFC 2543 original du protocole SIP [25].
6.3.1.2 Fonctionnalités
Avec SIP, les utilisateurs qui ouvrent une session, peuvent communiquer en mode
point à point, en mode diffusif ou en un mode combinant ces deux.
1. Point à Point : Communication entre deux machines.
2. Diffusif : Plusieurs utilisateurs en multicast via une unité de control (Multipoint
Control Unit).
3. Combinatoire : Plusieurs utilisateurs pleinement interconnectés en multicast
via un réseau à maillage complet.
6.3.1.3 Adressage et nommage
SIP choisit l’Email comme adresse de la forme : "user@domain", " user@IP adresse",
"numéro telephone@gateway". Le nom de domaine peut être le nom du hôte sur lequel
l’utilisateur est logé. L’adresse de la forme "numéro telephone@gateway" désigne le
numéro du téléphone PSTN [52]. A l’inverse des numéros de téléphone, les adresses
SIP désignent une entité plutôt qu’un terminal. Cette différence fondamentale permet
à celles-ci de représenter un individu, quelque soit sa localisation physique et également
quelque soit le terminal à sa disposition.
6.3.1.4 Architecture de SIP
Pour établir et terminer des communications multimédias, SIP utilise les 5 fonctions
suivantes :
1. User location : Permet de localiser le poste terminal utilisé pour communiquer.
2. User capabilités : Détermine quels médias vont être échangés (voix, vidéo, don-
nées,...), ainsi que les paramètres associés.
3. User availability : Détermine si le poste appelé souhaite communiquer et au-
torise l’appelant à le contacter.
4. Call setup : Avertit les parties appelée et appelante de la demande d’ouverture
de session et met en place des paramètres d’appel.
5. Call handling : Gère le transfert et la fermeture des appels.
6.3.1.5 Ouverture d’une session
Les échanges entre un terminal appelant et un terminal appelé se font par l’inter-
médiaire de requêtes :
1. INVITE : Indique que l’utilisateur correspond à l’URL SIP spécifié est invité
à participer à une session. Le corps du message décrit cette session. En cas de
réponse favorable, l’invité doit spécifier les médias qu’il supporte.
2. ACK : Permet de confirmer que le terminal appelant à bien reçu une réponse
définitive à une requête INVITE.
3. OPTIONS : Un proxy server en mesure de contacter un terminal appelé, doit
répondre à une requête OPTIONS, en précisant ses capacités à contacter le même
terminal.
4. BYE : Cette requête est utilisée par le terminal de l’appelé afin de signaler qu’il
souhaite mettre fin à la session.
5. REGISTER : Cette méthode est utilisée par un client pour enregistrer son
adresse auprès du serveur auquel il est relié.
6.3.1.6 Format des messages SIP
Un message SIP peut être une requête d’un client vers un serveur (figure 6.4.a) ou
une réponse de serveur vers un client (figure 6.4.b). Les adresses IP sont difficiles à
retenir et les utilisateurs peuvent changés fréquemment les machines sur lesquelles ils
se connectent. Pour cela le protocole SIP utilise un niveau supérieur des adresses de la
forme user@domain [14].
Ligne de requête Ligne d’état

( Méthode, requête URI, Version SIP ) Version SIP, code d’état, Reason phrases
Entête général ou de requête ou d’entité Entête général ou de réponse ou d’entité
CLRF (permet de spécifier la fin du champ CLRF (permet de spécifier la fin du champ
d’entête et de début du corps du message ) d’entête et début de corps du message )
Corps du message corps du message

(a) : Requête d’un client vers un serveur (b) : Requête d’un serveur vers un client
Fig. 6.4 – Format des messages SIP
6.3.1.7 Exemple d’une session SIP
La figure 6.5 montre un exemple d’une session SIP.
Mourad Serveur Proxy (s) Ahmed

INVITE Ahmed
INVITE Ahmed@172.45.123.12
OK de Ahmed@172.45.123.12
OK de Ahmed@172.45.123.12
ACK Ahmed avec la route

Ahmed@172.45.123.12
ACK Ahmed@172.45.123.12
Conversation
BYE ahmed@172.45.123.12
BYE ahmed@172.45.123.12
OK
OK
Fig. 6.5 – Exemple d’une session SIP
6.3.1.8 Limites de protocole SIP
Les tests sur le protocole SIP (figure 6.6) qui ont été faits récemment dans le la-
boratoire ENIC Telecom Lille1, ont montré que dans certains conditions, les délais
d’établissement de session SIP pour la VoIP peuvent être importants et dépassent les
seuils de l’ITU. Ceci est dû, en particulier à la taille des messages SIP (non compres-
sés) qui peuvent atteindre 1500 bytes au format textuel(ASCII ), ainsi que le routage à
travers les proxys SIP (routage n’est pas forcement optimal ).
Agent Agent
Proxy
Utilisateur Utilisateur
01 1
0 0
1
Delai de post−selection
Invite
1010 10 0
1 0
1
Trying
0110
Invite 35
1010 01
001
11 0
LAN
Delai de pré−selection
180 Ringing 30 802.11b
1010 11 00 00
110
1 0
1
180 Ringing Cable Modem
00
11 1010
Delai en seconde
25 Modem 56 kbs
10 11 00 00
110
1 0
1
200 Ok
1010 00
11
200 Ok 20
00
11 00
110
1 0
1
Delai de connection
1010 11 00
11 1010
Ack
0
1
15
Bye
Ack
00 1010 00
11 00
11
00
110
1 0
1
00
11 0
1
10
101011
00 1010
Bye
10 11
00 10 01
001
11 0
5
00
11
200 Ok
200 Ok 0
S1 S2 S3
Scénario
(a) : un shéma d’execution de SIP (b) : delai de connection
11
00
3
01
30
1
0 11
00 00
11
LAN
0
1 10100110
LAN
0
1
2.5 802.11b
1010
25
00
11 00
11
Delai en seconde
802.11b Cable Modem
0
1 0
1 délai en seconde
2
0010
11
Cable Modem
00
11
20 Modem 56 Kbs
0
1 10101010
Modem 56 kbs 1.5
00
11 00
11
15
0
1
00
11
1
00
11
00
1110 001010
11
101010
10
5
0
10
1 0
1
00
11
0.5 00
11
00
11 1010 00
11
0
01
10
S1 Scénario0
1 S2
(c) : delai de post−connection
S3
0 00
11
S1 S2 (no trying)
Scénario
(d) : delai de pré−connection
S3
35000
(1.x) : Avec compression
30000 (2.x) : Classique
2500 (y.1) : Delai de connection
(1.1) (2.1) (y.2) : Delai de pré−selection
25000
délai en m seconde
SIP classique (y.3) : Delai de post−selection

2000 ITU−T rec (95%)
SIP avec compression 20000 (1.3)
longueur en bytes
1500 (1.2)
15000
(2.2)
1000 (2.3)
10000
500 5000
0 0
Message INVITE Trying Ringing Ok Ack 1.2 2.4 4.8 9.6 19.2 52
kbs
( e ) : Tailles des messages SIP ( f ) : Délais SIP avec et sans compression
S2 : 1 SIP Proxy (Redirect) S3 : 2 SIP Proxys

S1 : 1 SIP Proxy
Average 95 %
Appel local (1−4 noeuds) 3 sec 6 sec
Appel régional(5−7 noeuds) 5 sec 8 sec
Appel onternationnal (8−10 noeuds) 8 sec 11 sec
( g ) : Seuils ITU−T pour le délai maximal d’établissement

d’une séssion voix
Fig. 6.6 – Tests de performances de protocole SIP

6.3.2 Le protocole H.323

H.323 fait partie de la série H.32x qui traite la vidéoconférence à travers différents
réseaux, elle inclut H.320 et H.324 liés aux réseaux ISDN (Integrated Service Data
Network ) et PSTN (Public Switched Téléphone Network ).
Le standard H.323 est normalisé en 1996, il fournit une base pour la communication
utilisant de l’audio, vidéo et les données à travers le réseau IP. En se conformant au
standard H.323, les produits et les applications multimédias peuvent interopérer. H.323
est une recommandation venant de l’ITU (International Télécommunications Union).
La norme H.323 est la principale concurrente de SIP pour la transmission du son,
de données et de la vidéo en temps réel sur le réseau IP.
6.3.2.1 ITU H.32x Famille des standards
Le tableau 6.1 représente la famille des standards H.32x.
Protocole Titre
H.320 Communication au dessus de réseau ISDN
H.321 Communication au dessus de réseau ISDN (ATM)
H.322 Communication dans un réseau local avec qualité de service garantie
H.323 Communication dans un réseau local avec qualité de service non garantie
H.324 Communication au dessus de réseau PSTN
Tab. 6.1 – La famille de protocoles H.32x
6.3.2.2 Constitution de H.323
Quatre composantes sont spécifiées dans la recommandation H.323 (figure 6.7) :

terminal, passerelle, Gardes-barrières et l’unité du contrôle multipoints.
¨ Terminaux H.323 : équipements des utilisateurs, par exemple des PCs avec des
logiciels de la téléphonie.
¨ Passerelles (Gateways) : c’est un intermédiaire entre un réseau IP et le RTC.
Elles assurent entre autre le codage et le décodage de la voix, la mise en paquets.
Ces boites ont typiquement des interfaces Ethernet (connectée au réseau IP ) et
un ensemble de ports pour connecter les téléphones classiques ou PABX. Les
systèmes de la téléphonie IP peuvent fonctionner avec les téléphones traditionnels
en utilisant les gateways qui translatent les données transmises de et vers les
formats appropriés de téléphone et d’Internet [26].
Fig. 6.7 – Constitution de H.323
¨ Gardes-barrière (Gatekeepers) : éléments logiciels qui assurent la gestion des

adresses (IP et E.164 téléphonique [11] ) et contrôlent l’accès des terminaux au
réseau IP.
¨ Multipoint Control Units (MCUs) : éléments logiciels qui permettent de gérer
des flux multicast.
H.235 définit les mécanismes de sécurité.
6.3.2.3 Exemple d’une session H.323
Un exemple d’ouverture d’une session H.323 est schématisé sur la figure 6.8.
6.3.3 SIP ou H.323 ?

Ils existent de nombreux produits utilisant le standard H.323 adopté par des grandes
entreprises telles que SISCO, IBM, Intel et Microsoft. Il permet un niveau d’interopé-
rabilité très élevé, ce qui permet à plusieurs utilisateurs d’échanger des données audio
et vidéo sans faire attention aux types de média qu’il utilisent.
SIP est un protocole très rapide, indépendant de la couche transport, il peut bien
s’utiliser avec TCP qu’avec UDP, il sépare le flux de données de celui de signalisation,
ce qui rend plus souple l’évolution d’une communication.
Etablissement d’une connexion TCP

Ahmed Mourad
CONNECT H.245 adresse/port specifiés
Etablissement d’une connexion TCP

Messages H.245
Ouverture d’un cannal logique (RTCP adresse/port specifiés)
Ouverture d’un cannal logique ACK (RTCP & RTP adresse/port)
Ouverture d’un cannal logique (RTCP adresse/port specifiés)

Ouverture d’un cannal logique ACK (RTCP & RTP adresse/port)
flux RTP
flux RTP
Instructions RTCP
Fig. 6.8 – Exemple d’une session H.323
Les principales caractéristiques sont comparées dans le tableau 6.2.
H.323 SIP
Organisme initiateur ITU-T IETF
(Date) (1996 ) (1999 )
Protocoles de transport TCP TCP ou UDP
Caractéristiques lourde et robuste simple et leger
messages en ASN.1 messages textuels/UTF-8
protocole peu evolutif protocole supportant
evolutivité Codecs prédéfinis les extentions (nouveaux
Structure rigide de la entêtes, ajout de fonctions
trame H.221 aux serveurs)
Déploiement large faible
interoperable avec RTCP (en cours de normalisation)
Tab. 6.2 – Comparaison des protocoles SIP et H.323
6.4 Les Firewalls et les NATS

Quatre types de NATs sont décrits dans [43] :
1. Cône plein : Toutes les requêtes proviennent de même adresse IP et port interne
sont représentées par la même adresse IP et port externe. En outre, n’importe quel
dispositif externe peut envoyer des paquets au dispositif interne, par l’envoi de
ces paquets à l’adresse externe qui représente ce dernier.
2. Cône restreint : Toutes les requêtes proviennent de même adresse IP et port

interne sont représentées par la même adresse IP et port externe. Contrairement
au NAT cône plein, un dispositif externe d’adresse IP x peut envoyer des paquets
au dispositif interne uniquement si ce dernier à déjà envoyé des paquets au dis-
positif d’adresse x.
3. Cône à port restreint : C’est comme la cône restreint avec des numéros de
ports restreints. Un dispositif externe d’adresse IP x et numéro du port y peut
envoyer des paquets au dispositif interne uniquement si ce dernier a déjà envoyé
des paquets au dispositif d’adresse IP x et numéro du port y.
4. Symétrique : Toutes les requêtes proviennent de même adresse IP et port interne

vers une destination spécifique sont représentées par le même pair d’adresse IP et
port externe. Si un même dispositif veut envoyer des paquets avec le même numéro
du port vers des destinations différentes, différentes adresses de representation
seront utilisées. En outre, uniquement le dispositif externe qui a reçu des paquets
peut envoyer des paquets UDP vers le dispositif interne.
6.4.1 Protocoles de découverte des Firewalls et des NATs
6.4.1.1 STUN
STUN (Simple Traversal of UDP through NATs) est un protocole qui permet aux
applications de découvrir la présence, ainsi que le type des NATs et Firewalls entre elles
et l’Internet. Il permet aussi aux applications de déterminer leurs adresses IP publiques
alloueés par les NATs.
6.4.1.2 TURN
TURN (Traversal Using Relay NAT ) est un simple protocole qui permet à des
éléments situés derrière des NATs ou des Firewalls de recevoir des données à l’aide des
connexions TCP ou UDP.
6.5 La téléphonie basée sur le protocole SIP

Comme il est montré sur la figure 6.9. Quand un utilisateur Mourad lance l’applica-
tion SIP client sur son ordinateur ou sur son téléphone IP ou sur un autre appareil qui
supporte la téléphonie IP, il s’enregistre dans le serveur SIP en indiquant l’adresse IP
de son appareil. Le serveur enregistre l’identificateur de l’utilisateur et son adresse IP
pour pouvoir faire la correspondance. Quand un autre utilisateur Ahmed appel Mourad,
il envoie son appel au serveur, ce dernier s’occupe de l’acheminement de l’appel vers la
bonne destination.
home.com
(1) : REGISTER
(2): INVITE
Sipd
Téléphone de Ahmed (3): INVITE
Ordinateur de Mourad
Ahmed@office.net
Mourad@home.com
Fig. 6.9 – La téléphonie internet classique
Le contrôle centralisé peut être une cause de défaillance qui empêche le fonctionnement
de système. Deux solutions ont été proposées dans [57].
1. La première solution décrite dans la figure 6.10.(a) consiste à dupliquer les ser-
veurs et leurs contenus. Lors de la première phase, les utilisateurs s’enregistrent
dans tous les serveurs. Quand un autre utilisateur veut les contacter, il envoie sa
requête à l’un des serveurs. L’inconvénient de cette solution est que la registra-
tion et le départ des nœuds ne se font pas en temps réels. Par consequent, si par
exemple un utilisateur A quitte le système avant que les serveurs mettent à jour
cette information, il se peut qu’un autre utilisateur B contacte l’utilisateur A alors
que ce dernier a déjà quitté le système et donc il y a une information inconsistante.
2. La deuxième solution décrite sur la figure 6.10.(b) consiste à dupliquer les serveurs
et leurs contenus. Lors de la première phase, les utilisateurs s’enregistrent dans
l’un des serveurs. Quand un autre utilisateur veut les contacter, il envoie sa requête
à tous les serveurs. Celui dans lequel l’interlocuteur est enregistré s’occupe de
l’acheminement des requêtes. L’inconvénient de cette solution est que le nombre
(1) : REGISTER
(2) : INVITE (1) : REGISTER (2) : INVITE
.................. ..................
(a) : Tous les serveurs enregistrent (b) : La recherche d’interlocuteur

tous les utilisateurs dans tous les serveurs
Fig. 6.10 – La recherche et l’enregistrement des utilisateurs
de messages pour chaque nouvelle recherche est élevé, ainsi que la registration
dans un seul serveur ne garantit pas que les utilisateurs restent connectés au
réseau en cas de défaillance de serveur sur lequel il sont connectés.
6.6 La téléphonie IP basée sur une architecture P2P

La téléphonie IP peut être basée sur une architecture P2P comme par exemple
dans [57]. Dans la première configuration décrite dans la figure 6.11, les super nœuds
Noeud ordinaire
Noeud ordinaire
Super Noeud
Fig. 6.11 – La téléphonie IP en mode P2P.
forment le réseau P2P, alors que les nœuds ordinaires utilisent ce réseau à travers le
super nœud auquel ils sont attachés. Dans cette architecture, chaque nœud peut être
un super nœud ou un nœud ordinaire suivant ses capacités. Le coût de la recherche
dans les deux types d’architecture est O(ln n). La première solution est coûteuse en
maintenance de stabilité s’il y a fréquemment des nouveaux super nœuds qui arrivent
ou quittent. Alors que la deuxième solution présente un problème pour les nœuds de
capacités limités.
Dans la deuxième architecture (P2P pure) le problème qui se présente est que
quelques nœuds ont par exemple un faible CPU, une petite mémoire, une petite bande
passante ou ils sont derrière un NAT ou un Firewall, donc ils ne peuvent pas accomplir
leurs fonctions dans le réseau P2P. Ce problème peut être résolu en adoptant un réseau
P2P hybride, avec des super nœuds. Les nœuds qui ont une grande capacité (bande
passante, mémoire, CPU, ainsi que des adresses IP publiques), constituent des super
nœuds. Un nœud ordinaire est connecté à un des super nœuds. La décision de devenir
un super nœud ou un nœud ordinaire est locale. Quand un nouveau nœud rejoint le ré-
seau, il devient un nœud ordinaire. Quand il détecte qu’il a des capacités lui permettant
d’être un super nœud, il peut transiter vers un super nœud.
6.6.1 La registration
A l’arrivée d’un nouveau utilisateur (nœud ), il indique son nom (mourad@open.com).
En utilisant les tables de hachage distribuées, il obtient une clé à partir non pas de son
adresse IP, mais à partir de son nom, ensuite il se place dans le réseau P2P (La clé de
Mourad est 30 dans la figure 6.12.(a)). Quand un autre utilisateur qui possède l’adresse
75 52
50
Mourad@open.com Gilles@home.com
30 11 REGISTER Gilles@home.com= 50 13
41 15
REGISTER Mourad@open.com = 13
19
27 30
(a) : Rejoindre le réseau P2P sans registration (b ) : Rejoindre le réseau avec registration
Fig. 6.12 – La recherche et l’enregistrement des utilisateurs
de Mourad veut parler avec lui (Gilles qui a la clé 11 ), il calcule sa clé par la même
fonction de hachage en utilisant son nom et il lance la requête rechercher(clé 30). Après
établissement de la connexion, les deux utilisateurs peuvent parler entre eux. Cette
architecture ne contient pas de registration et par conséquent elle ne permet pas la
messagerie off-line (si Mourad n’est pas présent alors Gilles ne peut pas lui envoyer des
messages). Dans la deuxième architecture(figure 6.12.(b)) la clé du nœud et celle de
l’utilisateur sont calculées séparément. Un message SIP REGISTER est utilisé à la fois
pour l’insertion d’un nouveau nœud dans le réseau, ainsi que pour la registration de ce
dernier dans le même réseau.
Quand Mourad lance son application client, le nœud utilise son adresse IP pour
calculer sa clé, par exemple 30 et il prend place dans le réseau, ensuite, il calcule
la clé d’utilisateur en utilisant le nom d’utilisateur et publie cette clé par un message
REGISTER de clé 13. Le nœud 15 qui est responsable de la clé 13 accepte la registration
et maintient dans sa table de routage que la clé 13 se trouve dans le nœud 30. Si Gilles
n’est pas présent alors Mourad peut lui envoyer des messages off-line avec la clé 50, qui
vont être délivrés à Gilles quand il devient on-line.
6.6.2 Architecture de P2P-SIP

La figure 6.13 montre un diagramme d’un nœud P2P-SIP, il est composé de dif-
férents blocs lui permettant de s’enregistrer dans le réseau P2P, de localiser d’autres
utilisateurs, de transmettre et de recevoir des messages off-line et de détecter les Fire-
walls et les NATs derrière lesquels il est, ...
On Startup
User Interface
( Buddy list, ...)
Audio
Outgoing Devices
Registration User Location
Codecs
Détéction
des DHT Logic
Firewalls
RTP/RTCP
et NATs SIP
Fig. 6.13 – Diagramme d’un nœud P2P-SIP
6.6.3 La registration d’utilisateur

Pour qu’un nœud rejoint le réseau, il doit s’enregistrer par son adresse IP pour
pouvoir être localisé dans le réseau P2P et par son nom pour qu’il puisse transmettre
et recevoir des messages off-line. La figure 6.14 montre comment un nœud s’enregistre
dans le réseau.
Noeud ordinaire startup
User id =
Mourad@home.com
SIP registration thread Peer discovery thread
no exit Trouver DNS send REGISTER

thread NAPTR ou au dernier noeud vu
SRV ?
Expiration échoue
Oui du timer redirect
Multicast réponse
Send REGISTER (no loop)
TTL = 1
échoue Succés échoue
Succés
Utilisation des
relancer le timer
boostrap noeuds
relancer le timer
Expiration
du timer relancer le timer
Expiration du timer
Fig. 6.14 – Node startup and outgoing registration
6.6.4 Défaillance d’un nœud

Pour qu’un nœud ordinaire quitte le système (figure 6.15), il n’a qu’à envoyer un
message REGISTER au super nœud avec lequel il est attaché, ce dernier fait propager
ce message vers le super nœud qui est responsable de ce nœud (qui stocke sa clé). La
défaillance d’un nœud ordinaire n’influe pas sur le reste du système. Dans ce cas, le
super nœud sur lequel le nœud défaillant était attaché peut détecter la défaillance de
ce dernier par l’absence de réponses sur les messages de rafraîchissement périodique, il
peut le confirmer par l’envoi d’un message OPTIONS au nœud défaillant, s’il ne reçoit
pas de réponse, le nœud est défaillant.
Quand un super nœud quitte le système, ce dernier doit faire quelques mises à jour
qui concernent les nœuds ordinaires qui ont été attachés à ce super nœud, ainsi que ses
voisins. Dans la défaillance d’un super nœud, les nœuds ordinaires qui ont été attachés
à ce dernier seront ré-attachés à un autre super nœud. La défaillance d’un super nœud
est détectée par leurs voisins.
60 60
1
1
31
40 20
20
31
30 30
17 17
Fig. 6.15 – Défaillance d’un super nœud dans le DHT
6.6.5 Localisation des utilisateurs

Comme il est montré sur la figure 6.16. Quand un utilisateur (Ahmed de clé 38 )
désire communiquer avec un autre utilisateur (Ali de clé 62 ), il calcule la clé de ce
dernier en utilisant la même fonction de hachage, il demande au super nœud sur lequel
il est attaché de lui chercher le nœud de clé 62 (rechercher (62)). Le super nœud
s’occupe de la recherche dans le réseau P2P en utilisant un algorithme de recherche
comme Chord ou CAN et fournit le résultat au peer demandeur (l’adresse IP de nœud
cherché). Ainsi, l’utilisateur Ahmed peut communiquer avec l’utilisateur Ali sans passer
par les supers nœud. Une priorité de recherche peut être utilisée dans le réseau P2P
pour des utilisateurs spéciaux comme la police,...
Ali@home.com home.com
62
2 10
60
40 1 14
3 2 15
Farid@home.com
40
31 19
38
Ahmed@net.com 34
16
Kamel@exem.com
Fig. 6.16 – La localisation des utilisateurs

6.6.6 Les messages Off-line

Quand Mourad appelle Ahmed ou lui envoie un message instantané et Ahmed n’est
pas en ligne, le message devrait être enregistré à Ahmed quand il vient en ligne. En
générale il y a trois emplacements où les messages off-lines peuvent être enregistrés : La
source, la destination ou certains nœuds intermédiaires. Les messages audio classiques
de PSTN sont enregistrés dans les répondeurs de destination ou dans les PBX pour les
serveurs d’Email centralisés. Dans notre cas, qui est la téléphonie IP en mode P2P, ces
messages sont enregistrés dans des nœuds intermédiaires (figure 6.17).
60
59
le noeud 69 enregistre ses
messages dans son successeur
les messages destinés au noeud
50 sont stockés dans le noeud 69 69
10
41
19
40
37
15
35
18
les messages de noeud 18
ne nécessite pas d’ être enregistrés
Fig. 6.17 – Les messages off-line
6.7 Skype
Skype est une application P2P de téléphonie IP basée sur l’architecture KaZaa.
C’est un protocole propriétaire [57], il supporte la messagerie instantanée ainsi que les
conférences audio. Skype est un service téléphonique et n’est pas une architecture, le
plus important, c’est qu’il est centralisé dans l’authentification et par conséquent, si le
serveur présente une défaillance, tout le système sera défaillant.
6.7.1 Architecture de Skype

Dans Skype, il y a deux types de nœuds : Les nœuds ordinaires et les super nœuds.
Skype utilise une variété des protocoles pour traverser les firewalls et les NATs (figure
6.18).
Chaque client Skype (SC) maintient une table pour sauvegarder les adresses IP et les
Skipe login server
Super Noeud
Noeud ordinaire
Fig. 6.18 – Architecture de Skype
numéros du port des supers nœuds appelée le cache des hôtes (HC). Il utilise TCP pour
la signalisation et UDP/TCP pour le transfert des données. Le trafic de médias et la
signalisation ne sont pas envoyés sur le même port.
6.7.2 Les composantes software de Skype

1. Port : Le port utilisé par défaut dans Skype est celui choisi lors de l’installa-
tion. L’utilisateur de client Skype software peut changer le numéro du port à tout
moment.
2. Cache hote (HC) : C’est une liste qui contient les adresses IP est les numéros
du port des super nœuds. Le SC sauvegarde les données de HC dans HKEY-
CURRENTUSER / SOFTWARE / SKYPE / PHONE / LIB / CONNECTION
/ HOSTE-CACHE. Elle contient au maximum 200 entrées. Cette liste est utilisée
pour accélérer la recherche, elle est similaire à finger-table dans Chord. Une ana-
lyse qui a été faite dans [3] a montré que le HC est initialisé par les sept adresses
décrites dans le tableau 6.3. Ces nœuds sont appelés les Boostraps super nœuds.
3. Codecs : Skype utilise iLBC, iSAC, ou GlobalIPSound.
4. Liste des Amis : C’est une liste qui contient des informations concernant les
amis de l’utilisateur. Elle est digitalement signée et encryptée, elle n’est pas sto-
ckée dans le serveur central de Skype.
Adresse IP Port Serveur

66.235.180.9 33033 Sls-cb10p6.dea2.superb.net
66.235.181.9 33033 Ip9.181.susc.suscom.net
80.161.91.25 33033 0x50a15b19.boanxx15.adsl-dhep.tele.dk
80.160.91.12 33033 0x50a15b0c.albnxx9.adsl-dhep.tele.dk
64.246.49.60 33033 rs-64-246-49-60.ev1.net
64.246.49.61 33033 rs-64-246-49-61.ev1.net
64.246.48.23 33033 ns2.ev1.net
Tab. 6.3 – Les boostaps super nœuds dans Skype
5. Cryptage/ Décryptage : Skype utilise AES 1 (Advanced Encryption Standard )

pour chiffrer et déchiffrer les appels et les messages instantanés avec 256 bits, donc
1.1∗1077 clés possibles. Par conséquent l’attaque en force n’est pas pratique. Skype
utilise RSA 2 (1536 à 2048 bits) pour partager la clé symétrique AES.
6. NAT et Firewall : Le client Skype utilise une variété de protocoles STUN et

TURN pour déterminer le type des NATs et des Firewalls derrière lesquels il est.
Le SC met à jour ces informations périodiquement.
6.7.3 Les fonctions de Skype

Il y a 7 fonctions principales dans Skype [3] : Startup, login, user search, call eta-
blishment, tear down, media transfert et presences messages.
1. Startup : Après l’installation de l’application client, elle envoie une requête

HTTP 1.1 GET au serveur Skype (skype.com). La première ligne de cette requête
contient le mot clé ’installed’, ensuite elle envoie une autre requête HTTP 1.1
GET au serveur Skype, la première ligne contient le mot clé ’getlatestversion’.
2. Login : Durant cette phase, le client Skype s’authentifie par son nom d’utilisa-
teur et son mot de passe, dans le serveur de login, donc il déclare sa présence à
ses amis ainsi que les autres peers. Il détermine le type de NAT ou de Firewall
derrière lesquels il est et il découvre les autres nœuds Skype qui sont connectés.
Dans une analyse de skype qui a été faite dans [3], ils ont remarqué que le client
Skype communique toujours avec le nœud d’adresse IP 80.160.91.11. Pour cela,
ils ont constaté qu’avec une très grande probabilité qu’il soit le serveur de login
1
AES : algorithme de cryptographie symétrique
2
RSA : algorithme de cryptographie asymétrique
de skype (skype.com). La figure 6.19 décrit l’organigramme de login dans Skype.
Start Oui
Connecté
Envoyer des paquets Non
UDP à HC l’adresse
Connexion TCP avec
IP et Port
adresse IP et le numéro de
port 443 (port HTTPS)
Réponse Oui
dans 5 secondes
Oui
Connecté
Non
Non
Connnexion TCP avec
adresse IP et le niméro de port Oui
Tentative connexion
=5
Non échec
Connexion Oui
Attendre 6 secondes
Non
Connexion TCP avec succès
adresse IP et le numéro de
port 80 (port HTTP)
Fig. 6.19 – Organigramme de login dans Skype
3. Le transfert de données : Si deux clients skype ont des adresses IP publiques,

alors le transfert se fait directement entre eux en utilisant UDP. La taille des
paquets de voix est de 67 octets, qui est la taille de payload UDP. Pour deux utili-
sateurs connectés à Internet avec 100 Mb/s Ethernet, sans qu’il y a une congestion
dans le réseau, le transfert peut aller jusqu’a 140 paquets de voix en une seconde.
Skype ne supprime pas le silence durant les appels, c’est-à-dire : Quand deux
utilisateurs skype établissent une communication, alors même les silences durant
la communication seront transmis comme tout autre paquet de voix.
4. La Recherche : Skype déclare que la recherche utilisée est distribuée, elle

garantie de trouver les utilisateurs s’ils étaient connectés durant les dernière 72
heures. Comme skype n’est pas un protocole ouvert et les messages sont cryptés,
il est très difficile de savoir sur quelle méthode il est basé pour faire la recherche.
6.8 Conclusion
Malgré la forte croissance de flux de données et de flux multimédia observés ces
dernières années, la téléphonie classique constitue encore le principal média pour les
entreprises, aussi bien pour les communications internes qu’externes. Par rapport à la
téléphonie classique, la téléphonie IP offre non seulement des perspectives intéressantes
de simplification d’architecture et d’administration des équipements, mais aussi des
nouveaux services enrichis, intégrant des applications informatiques. Le déploiement de
cette technologie permet de franchir un premier pas dans la convergence des réseaux
voix et données.
Plusieurs travaux ont été faits concernant la téléphonie IP en mode client-serveur,

mais comme on a vue dans le premier chapitre, le réseau Internet est en changement
permanent de l’architecture client-serveur vers le mode P2P. Pour cela, les recherches
en téléphonie IP commencent à se diriger vers le mode P2P, peu de travaux qui ont été
faits dans ce domaine.
Skype est le premier protocole de la VoIP basé sur la technologie P2P [3], trois
facteurs essentiels qui le rend populaire :
1. Il fournit une bonne qualité de voix.

2. Il peut fonctionner pratiquement derrière tous les NATs et les firwalls.
3. Il est facile à installer et à utiliser.
Malgré la croissance de la popularité de Skype, il présente quelques inconvénients,

par exemple la centralisation de l’opération de login (skype.com), car si ce serveur tombe
en panne, alors tout le réseau Skype devient infonctionnel. Une autre approche plus
intéressante est proposée dans ce domaine (la téléphonie IP en mode P2P en utilisant
le protocole de signalisation SIP ), elle est basée sur une architecture P2P pure, ainsi
que le protocole de signalisation SIP, donc elle rassemble et combine les avantages des
architectures P2P pures et ceux de protocole SIP.
Conclusion générale et perspectives
A VEC l’arrivé de l’Internet et son rôle actif croissant dans l’économie et la société,
l’informatique réseau n’a eu de cesse de trouver des innovations pour exploiter les
ressources qu’un réseau de cette ampleur contient. Aujourd’hui, on parle sérieusement
du peer to peer comme un modèle de communication capable de changer radicalement
certaines approches de l’informatique en réseau.
Les réseaux pair à pair connaissent un franc succès. Les domaines d’application du
P2P sont nombreux : Partage de ressources ( fichiers, CPU, mémoire,...,), travail col-
laboratif, calcul distribué...
Historiquement, Napster est le vieux système de partage de musique, il était la clé

de portes des réseaux P2P. La communauté des chercheurs s’interesse de plus en plus à
ce type de réseau, donnant naissance à plusieurs autres systèmes P2P. Actuellement, les
recherches commencent à se migrer de l’approche client-serveur vers des systèmes P2P,
c’est derniers se construisent autour d’une topologie virtuelle au dessus de la topologie
physique. Les protocoles P2P de la troisième génération sont basés sur les tables de
hachage distribuées. L’avantage de DHTs est qu’elles permettent de réduire le taux de
localisation de ressources d’une manière significative. Dans le deuxième chapitre, on
a proposé un nouveau protocole scalable à l’échelle de l’internet qui appartient à ce
dernier type de protocoles P2P.
La diversification et hétérogénéité de ces approches, ont donné naissance à plusieurs

problèmes, comme par exemple l’interopérabilité. Chaque système a sa propre méthode
de recherche et par consequent, la communication avec d’autres systèmes est pratique-
ment impossible, il y a donc création de plusieurs communautés d’utilisateurs pour le
même service.
94
Conclusion générale et perspectives 95
Pour résoudre ces différents problèmes, les grandes entreprises, ainsi que la commu-
nauté des chercheurs ont construit des plateformes de programmation réseau. Comme
à titre d’exemple ProActive qui est dédiée au calcul distribué, ainsi que JXTA qui sup-
porte pratiquement n’importe quel service.
Avec l’augmentation du nombre d’utilisateurs des réseaux P2P à cause de perfor-

mances et d’efficacité de ces derniers, les applications en mode client-serveur com-
mencent à se migrer vers le mode P2P, citons à titre d’exemple la téléphonie IP. Dans
le sixième chapitre, on a décrit deux architectures de la téléphonie IP en mode P2P :
Skype qui est un protocole propriétaire. La deuxième est un autre protocole de la télé-
phonie IP en mode P2P qui utilise SIP comme protocole de signalisation.
E N perspectives, nous allant simuler le protocole I4N que nous avons proposé pour
le comparer à d’autres protocoles P2P de même génération comme Chord. On va
le renforcer par un mécanisme de sécurité.
Nous voulons orienter nos recherches vers la téléphonie IP en mode P2P, car les
architectures P2P ont prouvé leurs efficacités dans la pratique, nous voulons utiliser
le protocole SIP comme protocole de signalisation, car ce dernier a été conçu pour
supporter des extensions. Au cours de ces dernières années, il est devenu le principal
concurrent de standard H.323. Nous voulons concevoir une architecture qui supporte un
bon nombre de services, ainsi, l’utilisateur n’a pas besoin de changer l’application pour
changer de service. Pour introduire l’aspect sémantique dans le protocole de recherche,
nous voulons utiliser les skip graphs. Pour résoudre le problème d’interoperabilité, nous
voulons choisir la plateforme open source JXTA de SUN micosystem qui nous semble
qu’elle a un très grand avenir dans le monde de réseau, à cause de son indépendance des
langages de programmation, des systèmes d’exploitation et des protocole de transport,
elle n’est pas destinée à un type particulier de machines ou d’applications.
Dans ce mémoire, on a soulevé le problème de sécurité dans les réseaux P2P, mais on
n’a pas abordé les solutions proposées. Pour assurer la confidentialité, les algorithmes
de cryptographie comme AES sont des bons outils. L’utilisation de ces derniers est
confrontée aux problèmes de partage de clés. Il nous semble que l’utilisation des proto-
coles d’accord des clés sont très adaptés aux protocoles P2P des réseaux structurés.
Bibliographie
[1] Sameh El Ansary, Design and analyses in structured peer to peer systems , doctorat
thesis, Swidich institute of computer science (2005).
[2] Hari Balakrishnan, Frans Kaashoek, David Karger, Robert Moris, and Ion Stoica.,
looking up data in P2P systems, Communication of the ACM, Vol 46, n 2 (2003),
P43–P48.
[3] Salman A. Baset and Henning Schulzrinne, An analysis of the skype Peer to Peer
Internet telephony protocol, Columbia university (2004).
[4] Sherif Botros and Steve Waterhouse, Search in JXTA and other distributed net-
works, Proceedings of the First International Conference on Peer-to-Peer Compu-
ting (P2P.01) (2002).
[5] Frank Cappello, Samir Djilali, Gilles fedak, Tangui Morlier, and Oleg Lodygensky.,
Calcul global , Desktop Grids et XtremWeb, (2004).
[6] David Clark, Face-to-Face with Peer-to-Peer Networking, IEEE internet computing
(2001).
[7] Curt Cramer, Kendy Kutzner, and Thomas Fuhrmann, Boostrapping Locality-
Aware P2P Networks, (2003).
[8] Tim Dierks and Christopher Allen, The TLS Protocol : Version 1.0, IETF RFC
2246. Internet Engineering Task Force. (1999).
[9] Zenkri Djamel and Marine Souheil, Téléphonie sur IP, Document IP-Tel/7-F,
Union internationale des télécommunications (2001).
[10] Peter Jan Doets, Routing in structured P2P networks, Technical report, Delft uni-
versity of technology (2005).
[11] P. Faltstrom, E.164 number and DNS, RFC 2916 (RFC3761) (2000).
[12] Jerome Ferbake, Neelakanth Nadjir, Greg Ruetsch, and Illya Sharapov, Framework
for Peer-to-Peer distributed computing in a heterogeneous decentralized Environ-
ment, Sun Microsystem, Inc , Palo Alto ca, 94303 USA (2002).
96
Bibligraphie 97
[13] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T.Berners-Lee, Hypertext Transfer

Protocol – HTTP/1.1, RFC2616 (RFC 2068, January 1997).
[14] Wenyu Giang, jonathan lennox, Sankaran Narayanan, and Henning Schulzrinne,
Integrating Internet telephony services, IEEE Internet computing (2002).
[15] Brighten Godfrey, Karthik Lakshninarayanan, Sonesh Surana, Richard Karp, and
Ion Stoica, Load balancing in dynamic structured P2P systems, IEEE INFOCOM
(2004).
[16] Li Gong, JXTA : A Network Programming Environment , Industry report, IEEE
internet computing (2001).
[17] , Projet JXTA : A technology overview, SUN Microsystem, Inc, White paper
(2002).
[18] Vikas Gupta, Avnish Dass, Harpreet Singh Matharu, Ankur Verma, and Yash-
raj Chahan., Peer-to-Peer application development : cracking the code, Dreamtech
Software Team. (2002).
[19] Emir Halepovic, The cost of using JXTA : initial benchmarking results, Third
International Conference on Peer-to-Peer Computing (P2P’03) (2002).
[20] Emir Halepovic and Ralph Deters, The cost of using JXTA, Proceding of the
third intenational conference on Peer-to-Peer computing (P2P’03), IEEE internet
computing (2003).
[21] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, SIP : Session Initiation
Protocol, RFC2543 (RFC3261, RFC3262, RFC3263, RFC3264, RFC3265) (1999).
[22] Fox Harrelm, Yuanfang Hu, Guilian Wang, and Huaxia Xia., Survey of locating
and Routing in Peer-to-Peer systems, (2001).
[23] Jonathan Hess and Benjamin Poon, Improving Performance in Gnuttella Protocol,
(2003).
[24] Igor Ivkovi, Improving gnutella protocol , (2001).
[25] Alan B. Johnston, "SIP : Understanding the Session Initiation Protocol " Second
edition , Artech House, Boston London. ISBN 1-58053-655-7 (2004).
[26] Sixto Ortlz Jr, Internet telephony jumps of the Wires, IEEE Computer society
Industry trends (2004), P16 – P19.
[27] Neal Leavltt, Will interoperability problems give IP telephony a busy signal ?, IEEE
internet computing (2004), P16–P18.
[28] Jonathan Michael Lennox, Services for internet telephony, doctorat thesis, colum-
bia university (2004).
[29] Yanhao Liu, Li Xiao, and Lionel M. Ni, building a scalable bipartite P2P overlay
network, IPDPS (2004).
Bibligraphie 98
[30] Alfred W. Loo, The futur of P2P computing, Communication of the ACM Vol 46.
N9 (2003), P56 – P61.
[31] Guillaume Madre, Application de la transformée en nombre entiers à l’étude et au
développement d’un codeur de parole pour transmission sur réseau IP , Thèse de
doctorat Université de Bretagne occidentale- Ecole doctorale SMIS (2004).
[32] Petar Maymounkov and David Maziére, Kademlia : a peer to peer information
system based on the XOR metric , http ://kademlia.scs.cs.nyu.edu (2001).
[33] Daniel A. Menascé, Scaling the web : scalable P2P search , IEEE internet compu-
ting (2003), P83 – P86.
[34] Daniel A. Menasce and Lavanya Kanchanapalli, probabilistic scalable P2P ressource
Location Services, Proc. 2002 ACM Sigmetrics Practical Aspects of Performance
Analysis (PAPA 2002) (2002).
[35] M. Mezmaz, N. Melab, and E-G Talbi, Optimisation parallèle hybride sur un sys-
teme pair à pair, (2002).
[36] SUN micosystem, Projet JXTA : technical Shell overview, JXTA White paper
(2001).
[37] SUN Microsystem, Projet JXTA , http ://www.jxta.org (2000).
[38] SUN MICrosystem, Project JXTA : An Open, Innovative collaboration, SUN Mi-
crosystem (2001).
[39] Sun microsystem, Projet JXTA : Getting started , Sun Microsystem, Inc, White
paper (2001).
[40] SUN Microsystem, Projet JXTA Version 2.0, JAVA Programmer’s Guide, SUN
Microsystem (2003).
[41] Dejan S. Milojicic, Vana Kalogeraki, Rajan Lukose, Kiran Nagaraja, Jim Pruyne,
Bruno Richard, Sami Rollins, and Zhichen Xu, Peer to Peer conputing Survey, HP
Laboratories Palo Alto, HPL-2002-57 (2002).
[42] Wolfgang Nejd, Boris Wolf, Changtao Qu, Ambjorn Naeve, Mikael Nilsson, Mat-
thias Palmer, and Tore Risch, EDUTELLA : A P2P networking infrastrucure based
on RDF, Journal of ACM (2005), P604 – P615.
[43] Victor Paulsamy and Samir Chatterjee, Network convergence and the
NAT/Firewalls problems, Proceeding of the 36th Hawaii international conference
on system science (HICSS’03) , IEEE computing society (2002).
[44] C.Greg Plaxton, Rajmohan Rajaraman, and Andrea W. Richa, Accessing nearby
copies of replicated Objects in a distributed environnement, Procceding of the 9th
Annual ACM Synposium on parallel algorithms and architectures (SPAA) (1997),
P311– P320.
Bibligraphie 99
[45] Defence Advanced Research project Agency, Internet protocol, RFC 0791 (1981).
[46] Changtao Qu and Wolfgang Nejdl, Exploring JXTA search for P2P educational
media discovery , (2002).
[47] Sylvia Ratnasamy, Paul francis, Mark Handley, Richard Karp, and Scott Shenker,
A scalable content adressable network, ACM SIGCOMM (2001).
[48] Sylvia Paul Ratnasamy, A scalable content adressable network, Doctorat thesis,
University of california at berkeley. (2002).
[49] Antony Rowstron and Peter Druschel, Pastry : a scalable, decentralized object lo-
cation and routing for large scale peer to peer systems, Proceding of the 18 th
IFIP/ACM international conference on distributed systems plateforms (Middel-
ware 2001), Heidelberg, Germany. (2001).
[50] German Sakaryan, Markus Wulff, and Herwig Unger, Search methods in P2P net-
works : a survey, (2004).
[51] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP : A Transport
Protocol for Real-Time Applications, RFC3550 (2003).
[52] Henning Schulzrinne and Jonathan Rosenberg, Signaling for internet telephony,
IEEE internet computing (2000).
[53] Hinning Schulzrinne, Internet telephony, Practical handbook of intenet computing.
(2004).
[54] Gauri Shah, Distributed data strucures for peer to peer systems, Doctorat thesis
(2004).
[55] R. Shirey, Internet security glossary, RFC 2828 (2000).
[56] Bartlomiej Sieka, Ajay D. Kshemkalyani, and Mukesh Singhal, On the Security
of Polling Protocols in Peer-to-Peer Systems, IEEE internet Computing, Procee-
dings of the Fourth International Conference on Peer-to-Peer Computing (P2P’04)
(2004).
[57] Kundan Singh and Henning Schulzrinne., Peer-to-Peer Internet telephony Using
SIP, Columbia university (2004).
[58] Clarke Siobhan, Dependability in Peer-to-Peer System, IEEE internet computing
(2004).
[59] Ion Stoica, Robert Morris, David Karger, M.Frans Kaashoek, and Haris Balakri-
shnan, Chord : A Scalable Peer-to-Peer lookup Service for Internet Application,
Proceeding of the ACM SIGCOMM’01, san Diego ,California (2001).
[60] Ion Stoica, Robert Morris, David Liben-Nowell, David Karger, M.Frans Kaashoek,
Frank Dabek, and Haris Balakrishnan, Chord : A Scalable Peer-to-Peer lookup
Service for Internet Application, IEEE Transactions on networking (2003).
Bibligraphie 100
[61] Egemen Tanin, Aaron Harwoodm, and Hanan Samet, Indexing distributed com-
plex data for complex queries, Proceedings of the National Conference on Digital
Government Research - DGO, pp. 81-90, 2004, Seattle, WA. (2003).
[62] Stephanos Androutsellis Theotokis, A survey of peer-to-peer files sharing techno-
logies, White paper , ELTRUN : Athens university of economics and business,
Greece. (2002).
[63] Bernard Traversat, Mohamed Abdelaziz, and Eric Pouyoul, Projet JXTA : A
loosely-consistent DHT rendez-vous walker, (2003).
[64] Bernard Traversat, Ahkil Arora, Mohamed Abdelaziz, Mike Duigou, Carl Hay-
wood, Jean-Christophe Hugly, Eric Pouyoul, and Bill Yeager, Projet JXTA 2.0
Super peer Virtuel Network , SUN microsystem, White paper (2003).
[65] Steave Watehouse, David M.Doolin, Gene Kan, and Yaroslav Faybisjenko, Distri-
buted search in distributed network, IEEE Internet Computing (2002).
[66] Steve Waterhouse, JXTA search : Distributed search for distributed network., Sun
Microsystem, JXTA White paper (2001).
[67] William Yeager and Joseph Williams, Secure Peer-to-Peer Networking : The JXTA
example, IEEE internet computing (2002).
Index
A Freenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
advertissements . . . . . . . . . . . . . . . 46, 64
G
algorithmes P2P . . . . . . . . . . . . . . . . . . 31
global computing . . . . . . . . . . . . . . . . . . 39
application P2P . . . . . . . . . . . . . . . . . . . 31
gnus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
aspects sémantiques . . . . . . . . . . . . . . . 29
Gnutella . . . . . . . . . . . . . . . . . . . . . . 12, 14
authentification . . . . . . . . . . . . . . . . . . . . . 7
H
B
H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Boostraping . . . . . . . . . . . . . . . . . . . . . . . 23
Boostrapping . . . . . . . . . . . . . . . . . . . . . . 26 I
Boostraps super . . . . . . . . . . . . . . . . . . . 90 I4N . . . . . . . . . . . . . . . . . . . . . . . 32, 35, 37
inondation . . . . . . . . . . . . . . . . . . . . . . . . 10
C
intégrité de données . . . . . . . . . . . . . . . . 7
calcul distribué . . . . . . . . . . . . . . . . . 6, 31
Can . . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 27 J
Chord . . . . . . . . . . . . . . . . . . . . . . . . . 18, 23 JINI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
client-serveur . . . . . . . . . . . . . . . . . . . . . . 31 JXTA . . . . . . . . . . . . . . . . . . . . . 31, 42, 95
codage de la parole . . . . . . . . . . . . . . . . 73
K
confidentialié . . . . . . . . . . . . . . . . . . . . . . . 7
Kademlia . . . . . . . . . . . . . . . . . . . . . . . . . 31
D KazaA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
décentralisation . . . . . . . . . . . . . . . . . 7, 37
M
DHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
messagerie instantanée . . . . . . . . . . 6, 42
diffusion . . . . . . . . . . . . . . . . . . . . . . 14, 32
messagerie off-line . . . . . . . . . . . . . . . . . 85
E Morpheus . . . . . . . . . . . . . . . . . . . . . . . . . 31
Edutella . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
N
ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Napster . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
F NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
firewall . . . . . . . . . . . . . . . . . . . . . . . . 13, 56 non repudiation . . . . . . . . . . . . . . . . . . . . 7
fonction de hachage . . . . . . . . . . . 16, 18
P
101
Index 102
P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5, 6 Skype . . . . . . . . . . . . . . . . . . . . . 89, 92, 95

pair à pair . . . . . . . . . . . . . . . . . . . . . . . . . . 4 SRDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
partage de fichiers . . . . . . . . . . . . . . . . . . 5 STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 super nœuds . . . . . . . . . . . . . . . . . . . . . . 84
PBP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
T
PDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
téléphonie . . . . . . . . . . . . . . . . . . . . . . . . . 10
PDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
téléphonie classique . . . . . . . . . . . . . . . 93
Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 43
téléphonie Internet . . . . . . . . . . . . . . . . 67
peerGroups . . . . . . . . . . . . . . . . . . . . . . . 46
téléphonie IP . . . . . . . . . . . . . . . . . . . . . . 30
PIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
table des raccourcis . . . . . . . . . . . . . . . 22
pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
tables de hachage . . . . . . . . . . . . . . . . . 28
plateforme P2P . . . . . . . . . . . . . . . . . . . 31
TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Plaxton . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
tolérance aux fautes . . . . . . . . . . . . 9, 37
ProActive . . . . . . . . . . . . . . . . . . . . . 41, 95
travail collaboratif . . . . . . . . . . . . . . . . . 31
protocole de signalisation . . . . . . . . . . 95
TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
protocole IP . . . . . . . . . . . . . . . . . . . . . . . 69
protocole probabiliste . . . . . . . . . . . . . 15 V
PRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
W
Q worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
QRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
qualité de service . . . . . . . . . . . . . . . . . . 68 X
Queryspace . . . . . . . . . . . . . . . . . . . . . . . 63 XtremWeb . . . . . . . . . . . . . . . . . . . . 39, 40
R
réseaux non structurés . . . . . . . . . . . . . . 2
réseaux structurés . . . . . . . . . . . . . . . . . . 5
registration . . . . . . . . . . . . . . . . . . . . . . . . 85
RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
S
sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . 7–9
scalabilité . . . . . . . . . . . . . . . . . . . . . . . . 5, 9
servents . . . . . . . . . . . . . . . . . . . . . . . 12, 13
Shell JXTA . . . . . . . . . . . . . . . . . . . . . . . 54
SIP . . . . . . . . . . . . . . . . . . . 74, 75, 79, 83

Thesis Magistere 05

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Thesis Magistere 05

Transféré par

Droits d'auteur :

Formats disponibles

République Algérienne Démocratique et Populaire

Ministère de l’enseignement supérieur et de la recherche scientifique

DÉCOUVERTE ET LOCALISATION DE SERVICES

Directeur de thèse : M r . MEDDAHI Ahmed

Soutenu le 05 Novembre 2005 devant le jury :

Président de jury : M r . KERKAR Moussa Professeur

c AMAD Mourad, Novembre 2005

Table des matières iv

Liste des Tableaux ix

Liste des Algorithmes ix

Table des Figures xi

1 Découverte et localisation de services en mode P2P 4

2 Internet à Quatre Niveaux (I4N ) 32

3 Les différentes plateformes P2P 39

4 Les Réseaux P2P et la technologie JXTA 43

6 La téléphonie Internet en mode P2P 67

Conclusion générale et perspectives 94

1.1 Quelques actions dans les messages Napster . . . . . . . . . . . . . . . . . . . . 11

6.1 La famille de protocoles H.32x . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

1 Algorithme probabiliste de recherche et localisation des services . . . . . . . . . 16

1.1 Taxonomie des systèmes P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 La structure du réseau P2P (I4N) . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1 Les opérations de base d’un peer . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 La propagation des requêtes dans le réseau JXTA . . . . . . . . . . . . . . . . . 59

D ’ABORD je tiens à exprimer mes plus vifs remerciements à

Novembre, 2005 AMAD Mourad

La caractéristique fondamentale d’un réseau P2P est qu’il permettre l’interconnexion

Dans le deuxième chapitre on a proposé un nouveau protocole de localisation de

Dans le quatrième chapitre, on a étudié la plateforme open source JXTA développée

Le cinquième chapitre est consacré à l’étude de performances de la plateforme JXTA

Découverte et localisation de services

Il y a deux grandes classes des réseaux P2P : structuré et non structuré.

De nombreuses approches permettent de construire un réseau reposant sur le pa-

1.2 Les réseaux peer-to-peer

1.2.1 Les applications Peer-to-Peer

– Partage des fichiers (File Sharing)

le concept du P2P. Ces systèmes permettent le partage direct des documents de

– Le calcul distribué (distributed computing)

1.2.2 Les aspects des réseaux P2P

– Tolérance aux fautes

rend les systèmes P2P robustes aux fautes.

sus non autorisés [55].

La confidentialité peut être assurée en utilisant les algorithmes de cryptographie

Définition 4. La non repudiation avec preuve de l’origine de données fournit au des-

par l’origine [55].

1.2.3 Les obstacles du réseau P2P

la sécurité sera touchée. Le téléchargement des documents à partir d’autres sys-

La scalabilité et la tolérance aux fautes dépendent de nombre de peers dans le

– La découverte des ressources

1.2.4 Les systèmes basés sur la technologie P2P et leurs classi-

Les protocoles P2P

Renseigné Non Organisé

Fig. 1.1 – Taxonomie des systèmes P2P

1.2.5 Le futur des réseaux P2P

1.3 Réseaux non structurés

présente l’architecture générale de Napster.

Fig. 1.2 – Architecture de Napster

1.3.1.1 La structure de messages Napster

Les messages de Napster sont composés de trois parties :

Longueur (16 bits) type (16 bits) données...

– Longueur : C’est la taille du bloc de donnée en octets.

Type Code Description

Tab. 1.1 – Quelques actions dans les messages Napster

1.3.2.1 La structure de messages Gnutella