Memoire Routage

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université Abderrahman Mira de Béjaia

Faculté des Sciences Exactes
Département Informatique
Mémoire de fin d’études

En vue de l’obtention du diplôme d’ingénieur d’état
En Génie Informatique.
Thème
Routage dans les réseaux pair à pair

Implémentation d’un protocole de routage
sous CORBA
Réalisé par :
CHEKKAL Kamel
HAMIDOUCHE Salim
Devant le jury composé de :
Président Mr. H. Moumen Maître assistant, U.Béjaia.
Promoteur Mlle. M. Yaici Maître assistant, U.Béjaia.
Co –promoteur Mme. S. Boutrid Maître assistant, U.Béjaia.
Examinateur 1 Mlle. S. Yessaad Maître assistant, U.Béjaia.
Examinateur 2 Mlle. Boulefkhar Maître assistant, U.Béjaia.
Juin 2008
A nos chers parents
A nos frères et sœurs
A tous nos proches, familles et amis.
Remerciements
Nous tenons à exprimer nos remerciements et notre gratitude à notre enseignante

et promotrice Madame Yaici, maître assistante à l’université de Béjaia, pour nous avoir
proposé un sujet très intéressant. Nous la remercions pour ses conseils avisés et sa
disponibilité durant toute cette année.
Madame Boutrid, notre co-promotrice pour ses orientations et son soutien moral.
Nous remercions les jurys, Monsieur Moumen de nous avoir fait l’honneur de
présider le jury de notre soutenance, Mesdemoiselles Yessaad et Boulefkhar d’avoir
accepté d’examiner et de juger notre travail.
Pour nos parents d’avoir su être à l’écoute et à la disposition de leurs enfants,

ainsi qu’à chaque membre de nos familles pour leurs encouragements. Nos collègues et
amis. Qu’ils trouvent ici un hommage pour tous qu’ils ont fait et enduré pour que nous
puissions aujourd’hui obtenir nos diplômes. Merci beaucoup !
Nos remerciements s’adressent à nos enseignants du département informatique
qui ont contribué à notre formation.
III
Résumé
Résumé : Dans ce mémoire, nous décrivons le contexte actuel des réseaux en donnant une
synthèse des protocoles de routage dans les réseaux Client/Serveur, ad hoc et pair à pair. Dans
le modèle P2P, les participants jouent le même rôle. L’absence d’une autorité centrale suppose
qu’un pair est capable de trouver un autre pair pour pouvoir communiquer avec lui, c’est la
fonction de recherche et localisation. Celle-ci doit être assurée par chaque pair. Une recherche
efficace dépend directement de la politique de routage des informations entre les participants
au système P2P. Depuis les débuts de ce modèle, on tente continuellement d’optimiser le
routage dans l’objectif d’utiliser parfaitement les ressources disponibles sur le réseau. Ceci a
constitué l’objet de notre étude.
Nous avons proposé une nouvelle approche de routage basée sur le principe des algorithmes à
permissions d’arbitres qui est une famille des algorithmes à quorums, nous visons
essentiellement à minimiser le nombre de messages utilisés pour garantir un routage efficace et
assurer un parcours exhaustif du réseau. Enfin, nous avons réalisé une application
communicante sous Corba qui implante les fonctionnalités du protocole proposé.
Mots clés : P2P, Protocoles de routage, Algorithmes à quorums, Corba.
Abstract : In this repport, we describe the current networks context by providing a synthesis of
routing protocols in Client / Server, ad hoc and peer to peer networks. In the P2P model,
participants play the same role. The absence of a central authority requires that a peer is able to
find another peer in order to communicate with him, this is called search and location function.
It must be ensured by each peer. An efficient search depends directly on routing policy of the
information between participants to the P2P system. Since its beginning, we try continually to
optimize routing in order to fully utilize the available resources on the network. This
represented the subject of our study.
We proposed a new routing approach based on the principle of quorum algorithms, we are
aiming primarily to minimize the number of messages used to guarantee an efficient routing
and ensure an exhaustive search on the network. Finally, we realised a communicating
application with Corba, in which we implemented features of the proposed protocol.
Keywords : P2P, Routing protocols, Quorum algorithms, Corba.
IV
Table des Matières
Dédicace ........................................................................................................................... II
Remerciements ............................................................................................................... III
Résumé ........................................................................................................................... IV
Table des matières ............................................................................................................V
Table des figures ............................................................................................................. IX
Table des algorithmes ..................................................................................................... XI
Liste des abréviations ................................................................................................... XII
Introduction Générale ....................................................................................................... 1
PARTIE I
1 Routage dans les réseaux ordinaires ............................................................................ 4

1.1 Définitions ......................................................................................................... 4
1.1.1 Le routage ................................................................................................. 4
1.1.2 Table de routage ....................................................................................... 4
V
Table des Matières
1.1.3 Le vecteur distance .................................................................................. 5

1.1.4 Etat de liens .............................................................................................. 5
1.1.5 Système Autonome ou Autonomous System (AS) .................................. 6
1.2 Routage direct .................................................................................................... 6
1.3 Routage indirect.................................................................................................. 7
1.3.1 Routage statique ........................................................................................ 7
1.3.2 Routage dynamique ................................................................................. 7
1.3.2.1 Routage dynamique interne (intra domaine) ................................ 7
1.3.2.2 Routage dynamique externe (inter-domaines) .............................. 8
1.4 Conclusion ......................................................................................................... 8
2 Routage dans les réseaux ad hoc ................................................................................ 10

2.1 Les protocoles de routage proactifs ................................................................. 10
2.1.1 DSDV (Dynamique Destination Sequenced Distance Vector) ............... 10
2.1.2 WRP (Wirless Routing Protocole) .......................................................... 11
2.1.3 GSR (Global State Routing).................................................................... 11
2.1.4 FSR (Fisheye State Routing) [8] HSR (Hierarchical State Routing) ..... 11
2.1.5 ZHLS (Zone-Based Hierarchical Link State Routing)............................ 12
2.1.6 CGSR (Clusterhead Gateway Swich Routing) ....................................... 12
2.1.7 DREAM (Distance Routing Effect Algorithme for Mobility) ................ 12
2.2 Les protocoles de routage réactifs ................................................................... 12
2.2.1 CBRP (Cluster Based Routing Protocol) ................................................ 13
2.2.2 DSR (Dynamique Source Routing) ......................................................... 13
2.2.3 AODV (Ad hoc On-Demande Distance Vector) .................................... 13
2.2.4 TORA (Temporary Ordering routing Algorithme) ................................. 13
2.2.5 ABR (Associativity Based Routing) ....................................................... 14
2.2.6 SSR (Signal Stability-based Routing) ..................................................... 14
2.2.7 LAR (Location Aided Routing) .............................................................. 14
2.2.8 RDMAR (Relative Distance Micro-discovery Ad hoc Routing) ............ 15
2.3 Conclusion ........................................................................................................ 16
3 Routage dans les réseaux pair à pair .......................................................................... 17
3.1 Définition des systèmes pair à pair ................................................................... 17

VI
Table des Matières
3.2 Caractéristiques des systèmes pair à pair ......................................................... 17

3.2.1 Décentralisation ...................................................................................... 17
3.2.2 Auto-organisation.................................................................................... 18
3.2.3 Connectivité Ad Hoc ............................................................................... 18
3.2.4 Un réseau virtuel (overlay) ..................................................................... 18
3.3 Classification des systèmes pair à pair ............................................................ 18
3.3.1 Systèmes centralisées .............................................................................. 19
3.3.2 Systèmes hybrides .................................................................................. 19
3.3.3 Systèmes purs ......................................................................................... 19
3.4 Classification des protocoles de routage dans les systèmes pair à pair ............ 20
3.4.1 Protocole de routage dans les systèmes centralisés ................................ 20
3.4.2 Protocoles de routage dans les systèmes hybrides par dissémination de
serveurs ................................................................................................... 21
3.4.3 Protocoles de routage dans les systèmes hybrides par élection de
serveurs .................................................................................................. 21
3.4.4 Protocoles de routage dans les systèmes purs non structurés ................ 22
3.4.5 Protocoles de routage dans les systèmes purs structurés ........................ 22
3.5 Domaines d’application ................................................................................... 23
3.5.1 Calcul parallèle et distribué ..................................................................... 23
3.5.2 Collaboration ........................................................................................... 24
3.5.3 Partage et distribution de contenu ........................................................... 24
3.5.4 Plates-formes de développement............................................................. 25
3.6 Conclusion ........................................................................................................ 25
PARTIE II
4 Problématique ............................................................................................................ 26
5 Proposition ................................................................................................................. 28
5.1 Introduction ........................................................................................................ 28

5.2 Principe des permissions d’arbitres ................................................................... 29
5.2.1 Contraintes sur les ensembles Ri .................................................................. 30
5.2.2 Construction d’ensembles Ri optimaux ....................................................... 30
VII
Table des Matières
5.2.3 Construction d’ensembles Ri presque optimaux .......................................... 32

5.3 Description du protocole ..................................................................................... 33
5.4 Comparaison ....................................................................................................... 40
5.5 Conclusion .......................................................................................................... 42
6 Conception et Réalisation .......................................................................................... 43
6.1 Modélisation ....................................................................................................... 43
6.1.1 Diagramme de classes .................................................................................. 44
6.1.2 Diagramme d’objets ..................................................................................... 45
6.1.3 Diagramme d’états ....................................................................................... 46
6.1.4 Diagramme de communication .................................................................... 46
6.1.5 Diagramme de séquence ............................................................................. 47
6.2 Réalisation ........................................................................................................... 49
6.2.1 Interface et service nommage dans jacorb .................................................... 49
6.2.2 Description de l’application ........................................................................... 50
6.2.2.1 Les interfaces IDL ........................................................................... 51
6.2.2.2 Description du fonctionnement de l’application .............................. 52
6.1 Conclusion ......................................................................................................... 56
Conclusion Générale .................................................................................................. 57
Bibliographie .............................................................................................................. 59
Annexe A .................................................................................................................. 63
Annexe B .................................................................................................................. 72
VIII
Table des Figures
3.1. Classification des systèmes pair à pair .................................................................... 20

3.2. Taxonomie des applications P2P ............................................................................. 23
5.1. Rôle décisif d’un arbitre .......................................................................................... 30
5.2. Plan projectif fini d’ordre 2 ..................................................................................... 32
5.3. Une Structure de communication matricielle .......................................................... 33
5.4. Organigramme de fonctionnement d’un servent ..................................................... 36
5.5. Organigramme de fonctionnement d’un servent suivant le protocole allégé .......... 39
6.1. Représentation de la classe « servent ».................................................................... 44
6.2. Diagramme de classes.............................................................................................. 45
6.3. Diagramme d’objets................................................................................................. 45
6.4. Diagramme d’état .................................................................................................... 46
6.5. Diagramme de communication ................................................................................ 47
6.6. Diagramme de séquence (cas général) .................................................................... 48
6.7. Cas Succès (réponse retournée) ............................................................................... 49
6.8. Schéma explicatif du fonctionnement de l’application ......................................... 52
6.9. Le programme Debut ............................................................................................... 53
6.10. Un servent intermédiaire........................................................................................ 54
6.11. Le servent cible de la recherche............................................................................. 54
IX
Table des Figures
6.12. Le servent initiateur de la recherche ...................................................................... 54

6.13. Le superviseur ........................................................................................................ 55
X
Table des Algorithmes
Algorithme 5.1. Algorithme du protocole ..................................................................... 37
Algorithme 5.2. Algorithme du protocole allégé ........................................................... 40
XI
Liste des Abréviations
ARP = Address Resolution Protocol.
AS =Autonomous System.
BGP = Border Gateway Protocol.
CAN = Content Addressed Network.
DHT = Distributed Hash Table.

DRP = Dynamic Routing Protocol.
GPS = Global Positioning System.
ICMP = Internet Control Message Protocol.

IGRP = Internet Gateway Routing Protocol.
IS-IS = Intermediate System to Intermediate System protocol.
LSP =Link State Packet.

NFS = Network File System.
OSPF = Open Shortest Path First protocol.
PFA = Path Finding Algorithm.

RIP = Routing Information Protocol.
SEQNO = Sequence Number.
SRP = Static Routing Protocol.

TTL = Time-To-Live.
TLU = Time Last Update.
XII
Introduction Générale
a simplicité d’utilisation et la maitrise acquise du modèle Client / Server

L ont fait de lui un modèle de référence pour développer tout type
d’application : messagerie, téléphonie IP, annuaires, etc. Et cela jusqu’à ce que le modèle
P2P soit sorti de l’ombre grâce à l’application Napster conçue pour partager de la
musique au format mp3, vers la fin des années 1990. Depuis, il captivait l’intérêt des
consommateurs que ce soient des particuliers ou des entreprises, et plusieurs études ont
été réalisées dans le but d’explorer ses possibilités et fonctionnalités. Actuellement, on
trouve beaucoup d’applications construites suivant ce modèle à l’image de Skype dans le
domaine de la téléphonie. La recherche et l’industrie voient en ce modèle une vraie
alternative aux applications Client/Serveur et contribuent à de nombreux travaux dans ce
domaine. En effet, cela ne concerne pas que la téléphonie mais que toutes les applications
actuelles qui sont construites selon le modèle Client/Serveur peuvent être repensées et
améliorées pour fonctionner selon ce nouveau modèle.
Un système construit suivant le modèle P2P est constitué d’un ensemble de pairs
interconnectés en réseau d’une façon complètement décentralisée. Chaque pair met ses
ressources à disposition des autres pairs et joue par là le rôle d’un serveur. En même
temps, chacun contacte les autres pairs pour obtenir les ressources dont il a besoin et joue
1
par cela le rôle d’un client. Ce type de systèmes a pour objectif de mutualiser les
ressources disponibles sur les pairs participants au système. Ajouté à cela le caractère
dynamique des participants qui peuvent à n’importe quel instant se déconnecter du
réseau. Les systèmes peer to peer sont classifiés en : centralisés, hybrides et purs.
Cependant pour réaliser les échanges et les communications entre les

participants, on doit définir une procédure de conduite qui sera suivie par chacun. Cette
procédure sera constituée d’un ensemble de règles qu’on regroupe sous l’appellation de
protocole. Notre thème traite du routage dans les réseaux P2P, c'est-à-dire
l’acheminement des informations échangées entre les participants sur le réseau, et cela
doit obéir à un ensemble de règles.
Nous proposons dans ce mémoire une nouvelle approche pour le routage des
informations dans un système P2P. Cette approche repose sur le principe des algorithmes
à permissions d’arbitres qui constitue une famille des algorithmes à quorums. Ce principe
à été introduit pour résoudre le problème de conflit d’accès à la section critique et aux
ressources partagées dans les systèmes répartis. Il se trouve que ce principe présente des
caractéristiques et respecte des contraintes très intéressantes sur la façon dont sont
répartis les nœuds du système. Cela nous a amené à penser à le réutiliser pour réaliser le
routage dans un système pair à pair. Dans un système construit sur ce principe, chaque
pair dispose d’un ensemble d’autres pairs qui font ses arbitres. Un pair voulant
communiquer avec un autre pair qu’il ne connait pas n’a qu’à envoyer sa requête vers ses
arbitres et attendre qu’il soit contacté par le nœud destinataire une fois la requête lui étant
parvenue. Le rôle d’un arbitre est d’acheminer la requête vers le pair cible ou vers ses
arbitres si la cible lui est inconnue.
Notre rapport est organisé en deux parties, chacune comprenant trois chapitres :
Le premier chapitre, portant sur les réseaux ordinaires suivant le modèle Client/Serveur,
présente les notions inhérentes au routage dans ces réseaux et les protocoles pour le
routage direct intra-domaine et le routage indirect inter-domaines.
Le deuxième chapitre, traitera des réseaux ad hoc, expose les principaux protocoles et
leurs principes de fonctionnement. Ils sont classés en deux grandes familles : proactifs et
réactifs.
2
Le troisième chapitre est le dernier de la première partie, il est consacré aux réseaux peer
to peer. Dans ce chapitre, nous avons présenté ce type de réseau, ses caractéristiques, une
classification possible de ses protocoles de routage et les domaines d’application.
Nous avons entamé la deuxième partie du rapport avec le quatrième chapitre qui annonce
la problématique du routage dans les systèmes peer to peer.
Le cinquième chapitre expose le détail de notre proposition. Nous avons commencé par
présenter le principe des algorithmes à permissions d’arbitres, suivi par la description du
protocole et terminé par une évaluation de ses fonctionnalités.
Le dernier chapitre comprend une modélisation dans le langage UML d’une application
communicante qui utilise le principe du protocole pour s’échanger les messages et la
description de la réalisation et de son implantation sous le bus JacORB de la norme
Corba.
3
Partie I
On essayera tout le long de cette partie de présenter d’une façon brève le

fonctionnement des principaux protocoles de routage de chaque catégorie de réseaux, en
expliquant la philosophie du routage et les domaines de leur utilisation. Cependant, la
part la plus importante de notre travail sera consacrée au troisième chapitre qui
présentera les caractéristiques du P2P, ses protocoles et ses domaines d’application.
Nous utiliserons les termes : pair à pair, P2P, égale à égale ou encore peer to peer pour
désigner un système ou un réseau pair à pair, et les mots : nœud, pair, utilisateur ou
participant pour désigner une machine qui participe au réseau. Une machine désigne un
ordinateur dans son ensemble matériel et logiciel lui permettant de rejoindre le réseau et
d’interagir avec les autres nœuds.
Chapitre Premier
Routage dans les Réseaux ordinaires
1.1 Définitions
Les protocoles de routage se scindent en deux grandes familles, une est basée sur
le principe de vecteur de distance et l’autre sur le principe d’état de lien. Ci-après, on
précisera la nature de l’information de routage utilisée par chacune des familles et le
mécanisme d’échange de ces informations et de mise à jour des tables de routage.
Quelques autres notions utilisées généralement par les protocoles de routage sont aussi
définies.
1.1.1 Le routage
Le routage consiste en la fonction d’aiguillage, qui permet aux messages

(paquets) envoyés d’atteindre leurs destinations. Le routeur ou celui qui fait le routage
utilise des tables d’information appelées tables de routages.
1.1.2 Table de routage
La table de routage est une base d’informations qui contient des informations
sur les nœuds qui forment le réseau, ces informations vont de l’adresse IP d’un voisin au
débit du lien, et bien d’autres informations plus ou moins complexe selon les cas et les
4
Chapitre Premier Routage dans les Réseaux Ordinaires
besoins de chaque protocole. Ces tables sont évidemment gérées par les protocoles de
routage qui les utilisent à cette fin.
1.1.3 Le vecteur distance [1,3]
Les protocoles qui utilisent ce critère sont itératifs : car ils continuent de
transmettre les informations de routage tant qu’elles sont disponibles, asynchrone :
chaque envoi se fait indépendamment de l’état du récepteur.
L’information de routage est constituée de l’adresse du prochain nœud et du coût

(distance) en termes de nombre de sauts pour l’atteindre.
Algorithme de mise à jour des tables de routage: Les routeurs diffusent leurs tables de
routage régulièrement (entre 10 et 90 seconds) à tous leurs voisins directs. Ces derniers
peuvent, si nécessaire, mettre à jour leurs tables en respectant les règles qui vont suivre.
Pour chaque nœud :
Si l’entrée n’existe pas dans sa table, il la rajoute.
Si le coût contenu dans la table reçue plus le coût pour aller au routeur
émetteur de cette table est inférieur au coût indiqué dans l’ancienne table,
alors cette entrée est remplacée par la nouvelle qui est plus courte.
Si non, il n y a pas de changement.
La mise à jour d’une entrée au niveau d’un routeur engendre l’émission de cette nouvelle
table aux nœuds et routeurs voisins.
Les échanges entre les routeurs continuent jusqu’à convergence de l’algorithme (jusqu'à
ce que toutes les tables soient identiques).
1.1.4 Etat de liens [1,3]
Les protocoles qui sont implémentés sur ce critère nécessitent des tables de
routages plus volumineuses que leurs semblables basés sur le vecteur distance, cela se
justifie par la nature de l’information de routage utilisée par ces derniers.
L’information de routage : l’état d’un lien peut être décrit par différentes informations,
citons par exemple : le délai de transmission, la fiabilité du lien, sa charge ou encore son
débit.
5
Algorithme de mise à jour des tables de routage: un routeur envoie un message

d’interrogation « HELLO » sur le réseau, et pas seulement aux routeurs voisins. Tous les
routeurs qui reçoivent le message répondront par leurs états de lien dans des paquets LSP
(Link State Packet). Ces derniers contiennent : l’ID du nœud qui a créé le LSP, une liste
des voisins qui lui sont directement connectés avec le coût de chaque lien, un numéro de
séquence SEQNO et un Time-To-Live (TTL) pour le paquet. À la réception de ces
informations, le routeur initiateur (émetteur de l’interrogation) calcule les coûts des
lignes qui mènent à ces routeurs comme suit :
Si une entrée n’existe pas dans la table alors l’ajouter, et diffuser le LSP à
tous les nœuds excepté l’émetteur.
Si l’entrée est présente, on compare le numéro de séquence du paquet reçu

avec celui stocké, si le numéro stocké est plus petit alors diffuser le LSP à
tous les nœuds excepté l’émetteur.
1.1.5 Système Autonome ou Autonomous System (AS) [2]
Les systèmes autonomes sont des ensembles de sous réseaux et de routeurs sous
une administration commune, toutes les parties d’un AS doivent être connexes, chaque
AS a un numéro propre à lui. Au sein d’un même système autonome, on utilise les
protocoles internes à l’exemple de RIP (Routing Information Protocol), OSPF (Open
Shortest Path First Protocol), etc. A l’extérieur d’un system autonome (Interconnexion
de plusieurs AS), on utilise les protocoles externes (Exterior Protocols ou Interdomain
Routing Protocols) à l’exemple de BGP (Border Gateway Protocol).
1.2 Routage direct
Ce type de routage se produit lorsque les deux machines, émettrice et

destinataire se trouvent sur le même réseau. Ceci est assuré par le protocole ARP
(Address Resolution Protocol), qui utilise l’adresse MAC (adresse physique de la carte
réseau) des machines pour router les paquets de données. Le protocole ARP utilise un
cache de correspondance entre les adresses MAC et les adresses IP des pairs. Par ailleurs,
il n’utilise aucun critère de routage spécifique.
6
1.3 Routage indirect
Ce type de routage, contrairement au précédant se produit lorsque la machine

destination ne se situe pas sur le même réseau que la machine source, il utilise une table
de routage qui peut contenir différents types d’informations, et dispose d’algorithmes de
mise à jours de ces tables, basés sur un ou plusieurs critères de performance de
recherche. On distingue deux sous types : statique et dynamique.
1.3.1 Routage statique
L’ajout de nouvelles routes ou la mise à jour des tables de routage se fait

manuellement, ce qui introduit un grand risque d’erreur lors de la saisie. Cette contrainte
réduit d’autant plus la taille des tables, ce qui fait que ce type de routage ne soit utilisé
que pour les petits réseaux. Cependant, la correction des routes peut se faire de façon
automatique grâce au protocole ICMP (Internet Control Message Protocol), qui récupère
les erreurs de routes et optimise les routes déjà existantes.
1.3.2 Routage dynamique
Dans ce type de routage, la modification des tables de routage se fait de façon

automatique. Les protocoles de routage dynamique se regroupent en deux familles :
Protocoles de routage internes et protocoles de routage externes. Ces derniers utilisent
deux notions pour définir l’information de routage, qui est stockée au niveau des tables
de routage, et qui sert à définir la nature d’un nœud (inter ou intra AS) dans le réseau : le
vecteur distance et l’Etat des liens.
1.3.2.1 Routage dynamique interne (intra domaine)
Les protocoles les plus utilisés sont les suivants: RIP (Routing Information
Protocol), IGRP (Internet Gateway Routing Protocol), OSPF (Open Shortest Path First
protocol), IS-IS (Intermediate System to Intermediate System protocol) (SISCO).
 RIP (Routing Information Protocol) [2]: ce protocole est utilisé dans les
réseaux ne dépassant pas 15 routeurs, basé sur l’algorithme de Belleman-
Ford qui utilise la notion de vecteur de distance. A chaque route est associée
une métrique M qui représente le coût de cette route en nombre de routeur à
traverser (sauts). Chaque routeur envoie systématiquement sa table de
routage à ses voisins (toute les 30 secondes). A la réception des informations
7
de routage le protocole calcule le coût de chaque route puis sélectionne les

meilleures, ou les ajoute directement si elles n’existent pas dans sa table. A la
fin il envoie a son tour sa table de routage si modification il y a eu.
 OSPF (Open Shortest Path First protocol) [2]: ce protocole est venu combler
les lacunes de RIP en introduisant la possibilité de gérer des domaines de
diamètre supérieur à 16 routeurs. Il utilise une métrique M plus sophistiquée
consistant en la prise en compte des débits et enfin la segmentation du
domaine en aires (morceaux du réseau physique). C’est un protocole basé sur
l’algorithme du plus court chemin (Shortest Path First) de Dijkstra qui utilise
la notion d’état de lien, chaque routeur construit un arbre de coût minimum à
partir d’une table d’information de routage commune à tous les routeurs.
Cependant ces performances ne sont pas sans prix, car il faut des routeurs
plus puissants et sa configuration est plus difficile que RIP.
1.3.2.2 Routage dynamique externe (inter-domaines)
Le plus connu est BGP, il s’occupe du routage entre les systèmes autonomes.
 BGP (Border Gateway Protocol) [2]: ce protocole n’est ni vraiment à vecteur

distance ni à état de lien, chaque système autonome définit le coût des liens à
sa manière a lui, donc il est pratiquement impossible de comparer les coûts
des différent liens pour en choisir le moins coûteux. Son rôle est de faire
communiquer les routes (chemins) entre les systèmes autonomes, tout en
respectant les politiques de routage interne de chacun d’eux, donc il doit être
indépendant du protocole de routage interne de chaque système autonome.
1.4 Conclusion
Tout au long de ce chapitre, nous avons relaté les algorithmes de routage les plus
utilisés dans les réseaux conventionnels client/serveur, qui sont les plus utilisés dans le
web et par la plupart des applications. Cependant, l’évolution des besoins en termes de
réseaux et de télécommunication a engendré l’avènement de nouveaux types de réseaux,
et par la même, de nouveaux algorithmes de routages adaptés à ces nouvelles topologies
de réseaux.
8
Dans le deuxième chapitre, nous allons présenter les protocoles de routage pour les
réseaux ad hoc. Ce type de réseau est utilisé dans de nombreuses applications, parmi
lesquelles nous pouvons citer les télécommunications (téléphone sans fil, réseaux Wifi)
et aussi les réseaux de capteurs.
9
Chapitre Deuxième
Routage dans les Réseaux Ad hoc
2.1 Les protocoles de routage proactifs
On distingue deux types de protocoles de routage dans les réseaux ad hoc selon
la philosophie de recherche des routes : les protocoles proactifs et les protocoles réactifs.
Les protocoles de routage proactifs essaient de maintenir les meilleurs chemins existants
vers toutes les destinations possibles éventuellement vers l'ensemble des nœuds du
réseau, au niveau de chaque nœud. Les routes sont sauvegardées mêmes si elles ne sont
pas utilisées. La sauvegarde permanente des chemins de routage, est assurée par un
échange continu des messages de mise à jour des chemins entre les nœuds qui constituent
le réseau, ce qui induit une surcharge du réseau surtout dans le cas des réseaux de grande
taille.
2.1.1 DSDV (Dynamique Destination Sequenced Distance Vector) [4]
Ce protocole est basé sur l’algorithme de Bellman-Ford. Le routage se fait

à l’aide d’une table qui contient, la destination, la distance en termes de sauts pour
l’atteindre et un numéro de séquence. Ce protocole utilise deux sortes de mise à
jour : une mise à jour complète où la station transmet la table entière à ses voisins
et une mise à jour incrémentale où uniquement les entrées modifiées seront
10
Chapitre Deuxième Routage dans les Réseaux Ad hoc
transmises. Un paquet de mise à jour contient : le nouveau numéro de séquence,

celui du nœud émetteur incrémenté, et pour chaque nouvelle route :
L'adresse de la destination.
Le nombre de noeuds (ou de sauts) séparant le noeud de la
destination.
Le numéro de séquence (des données reçues depuis la destination)
tel qu'il a été estampillé par la destination.
2.1.2 WRP (Wirless Routing Protocole) [5,6]
Ce protocole utilise principalement les algorithmes de recherche de

chemins (PFA : Path Finding Algorithmes). Le routage nécessite, premièrement,
une table de distances qui contient pour chaque destination la distance par rapport à
un certain voisin, une table de routage qui contient l’adresse de la destination, son
prédécesseur, son successeur et une étiquette, mais aussi une table des coûts et
enfin une liste de retransmission, qui contient l’ensemble des nœuds voisins qui
n’ont pas acquitté son message de mise à jour.
2.1.3 GSR (Global State Routing) [7]
C’est un protocole qui possède les mêmes caractéristiques que DSDV

auxquelles on a ajouté une vue globale du réseau et une dissémination (inondation
bornée) pour les échanges des paquets de mise à jour. Ce protocole utilise
plusieurs tables pour effectuer le routage, une table des voisins, une autre pour la
topologie qui contient les états des liens plus une estampille pour chaque entrée.
Mais aussi une table des suivants qui contient l’ensemble des nœuds qui conduisent
à une certaine destination. Enfin, une table des distances qui contient le plus court
chemin pour chaque destination.
2.1.4 FSR (Fisheye State Routing) [8]
Ce protocole peut être considéré comme une amélioration de GSR, plus le

fait d’utiliser la technique de l’oeil du poisson, dans laquelle les informations qui
concernent les voisins les plus proches sont plus précises que celles des autres.
Néanmoins, ce protocole n’utilise pas l’inondation pour les mises à jour.
11
2.1.5 HSR (Hierarchical State Routing) [9,10]
Ce mécanisme combine la notion de groupes dynamiques avec des nivaux

hiérarchiques et une gestion de la localisation, les adresses utilisées sont des
adresses hiérarchiques, qui peuvent être obtenues en utilisant les numéros de
groupes.
2.1.6 ZHLS (Zone-Based Hierarchical Link State Routing) [11]
Ce protocole découpe le réseau en un ensemble de zones, ce qui a pour

effet d’engendrer deux niveaux de topologies :niveau zone et niveau nœud, et par
conséquent deux types de paquets de routage : les paquets orientés nœuds, utilisés
dans le routage intra-zones (à l’intérieure d’une zone) et les paquets orientés
zones, utilisés dans le routage inter-zones. Les adresses sont de la forme <ID
zone, ID nœud>.
2.1.7 CGSR (Clusterhead Gateway Swich Routing) [10]
Ce protocole utilise essentiellement l’algorithme de routage DSDV,

auquel est ajoutée la notion de groupes dont les membres appartiennent à la
portée d’un nœud représentant de ce groupe. Un nœud intermédiaire est un nœud
qui appartiennent à la portée de deux ou de plusieurs représentants de groupe. Cet
algorithme utilise, pour assurer le routage, une table des membres de groupe et
une table de routage.
2.1.8 DREAM (Distance Routing Effect Algorithme for Mobility) [12]
Il se base sur les informations de localisation, en envoyant plus

fréquemment les informations de routage aux voisins les plus proches et moins
fréquemment aux autres.
2.2 Les protocoles de routage réactifs
Les protocoles de routage réactifs, représentent les protocoles les plus récents
proposés dans le but d'assurer le service de routage dans les réseaux sans fil. A l'inverse
des protocoles proactifs, ils créent et maintiennent les routes selon les besoins. Lorsqu’un
12
pair a besoin d'une route, une procédure de découverte globale de routes est lancée, et
cela dans le but d'obtenir une information spécifique, inconnue au préalable.
2.2.1 CBRP (Cluster Based Routing Protocol) [13]
C’est un protocole qui se base sur la notion de groupe tel que à chaque
groupe est associé un représentant qui dispose d’une table de groupes adjacents, où
chaque entrée est de la forme <ID groupe, Nœud de liaison, Nœud
représentant>, et une table des membres du groupe. Cette dernière contient
l’ensemble des nœuds membres du groupe. Les membres, quant à eux, disposent
d’une table de voisins qui contient ; pour chaque voisin ; le statut (membre ou
représentant de groupe) et l’état du lien (uni ou bidirectionnel). L’échange des
informations de routage se fait par inondation.
2.2.2 DSR (Dynamique Source Routing) [14,15]
La découverte de routes se fait en inondant le réseau d’une requête de

recherche de route qui va contenir la route à partir de la source jusqu’à la
destination. Cette même route va être retournée à la source à l’aide d’un paquet
réponse. Il utilise aussi le mécanisme de maintenance de route, qui maintient les
meilleures routes.
2.2.3 AODV (Ad hoc On-Demande Distance Vector) [16,17]
Il peut être considéré comme une amélioration de DSDV, il reprend les

deux mécanismes de découverte de route et de maintenance de route de DSR, tout
en gardant le principe des numéros de séquence et l’échange périodique du
DSDV. Toutefois, il effectue un routage nœud par nœud. Chaque nœud dispose
d’une table de routage, dont chaque entrée est constituée de l’adresse de la
destination, le nœud suivant, la distance en nombre de nœuds, le numéro de
séquence et le temps d’expiration de l’entrée de la table.
2.2.4 TORA (Temporary Ordering routing Algorithme) [18,19]
Il appartient à la classe des algorithmes à « inversement de liens », qui

essaient de maintenir la propriété appelée « orientation destination » des graphes
acycliques orientés, qui consiste à toujours trouver un chemin vers une
destination. Pour ce faire, on associe à chaque nœud une taille de telle sorte que
13
les liens soient orientés du nœud de plus grande taille vers celui de plus petite
taille. Les messages de mise à jour sont limités aux nœuds les plus proches de
l’occurrence du changement de la topologie (où s’est produit le changement).
2.2.5 ABR (Associativity Based Routing) [20,21]
Son but étant de trouver des routes de longues durées de vie, ce protocole
définit une nouvelle métrique appelé le degré de stabilité d’association, dont une
valeur est associé à chaque entrée de la table de routage et qui est incrémentée à
chaque fois que le nœud reçoit un signal du nœud auquel correspond l’entrée.
Plus le degré de stabilité d’association est grand plus la connexion entre les deux
nœuds est stable. De plus, une grande stabilité de la connexion entre deux nœuds
veut dire, dans le cas des réseaux ad hoc, un état bas de mobilité des nœuds
correspondants ; et le contraire engendre un petit degré de stabilité du réseau.
2.2.6 SSR (Signal Stability-based Routing) [22]
Ce protocole utilise deux notions, la stabilité de la localisation et la

puissance du signal entre les nœuds. Le routage se fait à l’aide de deux modules,
le DRP (Dynamique Routing Protocole), qui utilise une table de puissance des
signaux des nœuds voisins (SST), où les signaux sont considérés comme étant de
forte puissance ou de faible puissance, et le SRP (Statique Routing Protocole), qui
utilise une table de routage. Le protocole essaie d’atteindre la destination en
utilisant les liens de forte puissance mais le cas échéant, il utilise aussi les liens de
faible puissance.
2.2.7 LAR (Location Aided Routing) [23]
Ce protocole procède d’une manière très similaire à DSR sauf qu’il utilise
les informations de localisation fournies par le système de positionnement global
appelé GPS (Global Positioning System). A cela viennent s’ajouter deux
approches possibles.
 Dans la première, le nœud source définit une région circulaire dans

laquelle la destination peut être localisée. La position et la taille de la
région sont estimées en se basant sur :
La position de la destination, telle qu’elle est connue par la source.
14
L’instant qui correspond à cette position.

La vitesse moyenne du mouvement de la destination.
Le plus petit rectangle couvrant la région circulaire et le nœud source est
appelé la zone de requête. L'information calculée est rattachée au paquet de
requête de route. Cela est fait uniquement par le nœud source et les nœuds
qui appartiennent à la zone de requête.
 Dans la deuxième approche, le nœud source calcule la distance qui le

sépare de la destination, et l'inclut dans le paquet de requête de route. Ce
dernier est envoyé par la suite aux nœuds voisins. Quand un nœud reçoit
le paquet de requête, il calcule la distance qui le sépare de la destination,
et la compare avec la distance contenue dans le paquet reçu. Dans le cas
où la distance calculée est inférieure ou égale à la distance reçue, le nœud
envoie le paquet reçu. Lors de l'envoi, le nœud met à jour le champ de
distance avec sa propre distance qui le sépare du nœud destination.
2.2.8 RDMAR (Relative Distance Micro-discovery Ad hoc Routing) [24,25]
Il utilise principalement la Micro-découverte de Distance Relative ou

RDM (Relative Distance Micro-discovery). Donc l’idée est que la diffusion des
requêtes peut se faire en se basant sur une distance relative (RD) entre les unités
mobiles. La distance relative qui sépare deux nœuds est estimée en utilisant les
informations concernant la mobilité des nœuds : le temps écoulé depuis la
dernière communication et l'ancienne valeur de la distance RD. Chaque nœud
dispose d’une table de routage dont une entrée qui est associée à une destination
donnée contient les informations suivantes :
Le routeur par défaut : qui est un champ indiquant le nœud suivant

à travers lequel le nœud courant peut atteindre la destination.
Un champ RD : qui donne la distance estimée entre le nœud et la
destination.
Le temps de la dernière mise à jour : appelé TLU (Time Last
Update), qui représente l'instant de la dernière réception des
informations de routage qui proviennent de la destination.
15
Un champ appelé "RT_Timeout" : qui contient le temps

représentant la durée de vie de la route, i.e. la durée après laquelle
la route sera considérée invalide.
Un champ appelé "Route Flag" : qui précise si la route,
correspondante à la destination, est activée ou non.
2.3 Conclusion
On remarque que les protocoles utilisés dans les réseaux ad hoc, utilisent des
philosophies différentes de celles utilisées dans les réseaux conventionnels. Cela est dû
aux différences de topologies du point de vue du dynamisme des nœuds, de leur
autonomie et du type des connexions qui les relient (filaires et sans fil).
Dans le troisièmes chapitre, on va s’intéresser à un autre type de réseaux, à savoir les

réseaux pair à pair, qui présentent la même caractéristique de mobilité des nœuds mais
diffère des précédents systèmes par sa nature de réseau logique appelé ‘overlay’ ou
réseau virtuel. Ce réseau virtuel peut être perçu comme une couche au dessus du réseau
physique et qui utilise les ressources et protocoles de ce dernier. Toutefois cette couche
logique utilise ses propres règles et mécanismes pour communiquer, notamment les
applications P2P d’échange et de coopération et leurs protocoles.
16
Chapitre Troisième
Routage dans les Réseaux Pair à Pair
3.1 Définition des systèmes pair à pair [27]
Les systèmes pair à pair sont des systèmes distribués formés par
l’interconnexion d’ordinateurs qu’on désigne par nœuds, n’obéissant à aucune autorité
centrale, ces nœuds sont capables de s’auto-organiser en réseau dans l’objectif de
partager des ressources comme les contenus (fichiers de tout type), la puissance de
calcul, l’espace de stockage et la bande passante. Ces systèmes présentent des capacités
intéressantes de tolérance aux fautes et une aptitude à gérer le caractère dynamique des
nœuds participant au réseau, offrant ainsi un niveau de performance et de connectivité
acceptables.
3.2 Caractéristiques des systèmes pair à pair
Les systèmes pair à pair présentent les caractéristiques suivantes :
3.2.1 Décentralisation
Cette caractéristique est la principale différence par rapport à l’approche

client/serveur, en effet, les nœuds des réseaux pair à pair jouent en même temps le
17
Chapitre Troisième Routage dans les Réseaux Pair à Pair
rôle de client et de serveur. Chaque nœud partageant ses ressources sera considéré
comme serveur. Des mécanismes de dissémination et de duplication permettent
ainsi aux nœuds du réseau d’obtenir une ressource particulière sur une multitude de
serveurs. L’avantage de la décentralisation est qu’elle permet un niveau important
de tolérance aux fautes du fait de la duplication du serveur traditionnel.
3.2.2 Auto-organisation
La première caractéristique (décentralisation) induit directement la mise

en place de mécanismes d’auto-organisation et de gestion du réseau : sous l’aspect
fonctionnel en affectant par exemple certaines tâches spécifiques à des nœuds
particuliers, sous l’aspect communautaire en effectuant une segmentation suivant
les intérêts communs des utilisateurs, et sous l’aspect topologique en imposant ou
pas une structure de fonctionnement et de communication dans le réseau.
3.2.3 Connectivité Ad Hoc
Les nœuds dans les réseaux pair à pair présentent une connectivité de
nature intermittente et cela est dû principalement à deux phénomènes qui sont le
comportement imprévisible des clients et la mobilité des nœuds.
3.2.4 Un réseau virtuel (overlay) [26]
Ce réseau est formé au dessus de la couche application, permettant de faire

abstraction des différences de nature entre les nœuds (station, PC, PDA, …) et de la
distance physique entre ces derniers, en effet deux voisins dans la topologie
virtuelle peuvent se retrouver dans deux réseaux physiques différents. L’utilisation
d’un overlay nécessite toutefois la mise en œuvre des mécanismes de nommage et
routage dédiés. Les pairs ne sont donc plus représentés par leur adresse de niveau
transport ou adresse physique mais par un identifiant défini dans le cadre de
l’overlay.
3.3 Classification des systèmes pair à pair
De nature très dynamique et d’une existence très contestée, les réseaux P2P se
sont diversifiés surtout du coté de l’échange et de la recherche de contenus et de
ressources. Les systèmes pair à pair se scindent en trois grandes familles si on considère
18
le niveau d’autonomie des nœuds composant le réseau vis-à-vis de toute autorité centrale
si elle existe.
3.3.1 Systèmes centralisées
Les systèmes centralisés étaient les premiers à apparaitre. Nés en 1999, ils se
composent d’un serveur centralisé qui indexe les objets disponibles sur le réseau
(répertoire central), et de nœuds qui peuvent demander ou\et proposer ces objets par le
biais de ce serveur. Seule la récupération de ces objets se fait en mode pair à pair pur.
3.3.2 Systèmes hybrides
Les systèmes hybrides se basent sur un ensemble de serveurs qui se partagent la

fonction de routage, cela a pour effet de rendre le réseau plus sûr par rapport aux
systèmes centralisés qui sont, eux, très vulnérables aux attaques, puisque il suffit de
cibler le serveur central pour paralyser tout le système.
3.3.3 Systèmes purs
Les systèmes purs n’utilisent aucun serveur, du fait que tous les nœuds sont
égaux, puisque ils jouent tous le même rôle de serveur et de client en même temps.
La section qui va suivre présentera les cinq paradigmes qui en découlent. La figure 3.1
présente les différentes topologies existantes avec des exemples de systèmes pour chaque
type.
19
Systèmes
Distribués
Client-Serveur Pair à pair
Systèmes Systèmes Systèmes

Centralisés Hybrides Purs
Un seul Dissémination Election Pur Pur
Serveur Statique Dynamique Structurée Non
« Napster
Annuaire » eDonkey
De serveurs Kazaa
De serveurs CAN GNUTella
Structurée
Chord
Groove eMule GNUTella 2 Freenet
Pastry
Magi
Figure 3.1. Classification des systèmes pair à pair
3.4 Classification des protocoles de routage dans les systèmes

pair à pair
3.4.1 Protocole de routage dans les systèmes centralisés
Le meilleur exemple de se genre de protocoles reste sans conteste Napster,

utilisé pour le partage de fichiers mp3. Ce protocole repose sur un serveur central qui fait
office d’index, en stockant des informations propres aux nœuds et aux fichiers que ces
nœuds partagent. A chaque nouvelle arrivée de nœud, celui-ci envoie un message au
serveur central lui indiquant les fichiers qu’il veut partager, son adresse IP et un numéro
de port qui est celui de l’application utilisée pour le téléchargement.
La recherche, quand à elle, se fera par l’envoi d’un message de requête par le nœud
demandeur qui va contenir le nom du fichier recherché. Le serveur répondra par un
message contenant les adresses et les numéros de port des nœuds qui disposent de l’objet
en question. Ainsi, la récupération du fichier (objet) se fera, elle, en mode pair à pair, en
créant une connexion entre les deux nœuds (source et demandeur).
20
3.4.2 Protocoles de routage dans les systèmes hybrides par dissémination de

serveurs
Ce genre de protocoles est venu comme une amélioration des protocoles

précédents (un seul serveur), ils utilisent plusieurs serveurs d’index. En ce faisant, la
recherche est rendue plus efficace, surtout en cas d’augmentation du nombre
d’utilisateurs.
Lorsqu’un nouveau nœud arrive dans le réseau, il se connecte à un des serveurs en lui
envoyant un message contenant les fichiers qu’il veut partager. La recherche par contre
pourrait passer par plusieurs serveurs, c'est-à-dire que le nœud chercheur enverra un
message de requête au serveur auquel il est connecté, si ce dernier ne peut pas satisfaire
sa requête il la propagera aux serveurs qu’il connait, enfin la réponse sera acheminée au
nœud initiateur de la recherche.
Les applications les plus célèbres, qui utilisent ce type de protocoles sont bien eMule et
eDonkey.
3.4.3 Protocoles de routage dans les systèmes hybrides par élection de

serveurs
Dans cette classe de protocoles nous distinguons deux genres de nœuds,

premièrement les nœuds simples appelés les feuilles, ils représentent les participants
ordinaires. Deuxièmement, les super-nœuds, qui sont des nœuds auxquels sont attribuées
des responsabilités particulières en ce qui concerne le routage est la recherche des objets
sur le réseau, et qui se distinguent des autres nœuds (feuilles) par des performances plus
élevées (bande passante, fréquence CPU…). Ces nœuds sont désignés dynamiquement
par un mécanisme d’élection, qui sélectionne les pairs les plus puissants. A la différence
des protocoles des applications hybrides par dissémination de serveurs, les super-pairs
peuvent partager des fichiers alors que les serveurs d’index jouent uniquement le rôle
d’intermédiaires.
L’ajout de nouveaux participants passe par la connexion du nouvel arrivant à un des
super-nœuds, tout en lui envoyant une liste des fichiers à partager. La recherche, quand à
elle, se produit à la suite d’une requête adressée au super-nœud auquel l’initiateur de la
recherche est connecté, le super-nœud à son tour pourra interroger les super-nœuds qu’il
connait, pour enfin renvoyer la réponse à l’initiateur.
21
Les exemples d’applications, les plus populaires, qui implémentent ce genre de protocole
sont entre autre KaZaA, FastTrack et GNUTella 2.
3.4.4 Protocoles de routage dans les systèmes purs non structurés
Cette famille de protocole représente l’essence même de la notion de pair à pair,

puisqu’elle ne présente aucune infrastructure particulière du réseau, du fait que tous les
nœuds du réseau sont réellement égaux, car toutes les fonctions nécessaires au
fonctionnement du système (recherche et récupération des objets) sont réparties sur tous
les nœuds. Ce qui a pour conséquence de rendre le réseau totalement auto-géré tout en lui
procurant un niveau très élevé de scalabilité (la capacité de prendre en charge un nombre
croissant de participants dans le réseau).
Dans les applications qui utilisent cette famille de protocoles, l’entrée d’un nouveau pair
et la recherche d’un objet dans ce même réseau se fait par une inondation, le nœud n’est
pas obligé de se connecter à un pair particulier, ce qui engendre que le même pair peut
avoir plusieurs voisins.
Les exemples d’applications qu’on peut citer ici sont la première version de GNUTella
Freenet.
3.4.5 Protocoles de routage dans les systèmes purs structurés
D’origine académique cet ensemble de protocoles utilise essentiellement les

tables de hachage distribuées (DHT), et repose sur les notions de la théorie des graphes,
de ce fait leur efficacité peut être prouvée [27]. Ils reprennent la notion de
décentralisation totale de leurs prédécesseurs.
A chaque nouvelle arrivée le nœud se voit attribué un identifiant spécifique pour le
retrouver plus facilement par la suite, ce qui impose une certaine organisation du réseau.
La recherche par contre se fait de la même manière qu’une recherche dans un graphe. Les
graphes les plus utilisés sont : les hypercubes [28], les papillons [29], les tores [30], les
de Bruijn [31]. PASTRY, CAN et CHORD sont des exemples de protocoles qui utilisent
ces mécanismes.
22
3.5 Domaines d’application
Les domaines d’application du P2P sont multiples si on considère les projets de

recherche et les calculs mathématiques colossaux où il est utilisé. La figure 3.2 sur la
page suivante classifie les applications P2P en quatre grands domaines qui seront
détaillés par la suite.
Applications
P2P
Calcul Partage et Plates-formes

Collaboration
Distribution de développement
Parallèle Contenus
Calcul par
Calcul Projet
Composant
Intensif Jxta
Applications
Filtrage
Partagées Systèmes
Messages Extraction
de Fichiers
Instantanés Jeux
Echange
de
Contenu
Figure 3.2. Taxonomie des applications P2P.
3.5.1 Calcul parallèle et distribué
Les capacités de calcul additionnées des ordinateurs connectés à l’Internet

constituent une puissance inégalée par les technologies centralisées actuelles. Et du fait
que ces technologies sont très chères, le modèle P2P vient tirer profit de cette puissance
en proposant des applications utilisant la multitude de ressources présentes dans
l’Internet pour la réalisation de calculs colossaux et essayer de résoudre nombre de
problèmes de manière distribuée. En 1999, l’université de Berkeley lance le projet
Seti@Home qui a pour objectif d’analyser des données transmises par des récepteurs qui
23
écoutent l’univers afin de détecter une quelconque forme d’intelligence extraterrestre.

Etant donné le nombre colossal de données à analyser, l’équipe proposa de développer
une application qui prend la forme d’un économiseur d’écran qui, lorsque l’ordinateur
sur lequel elle est hébergée est oisif (donc à l’exécution de l’économiseur d’écran),
télécharge un morceau de données sur un serveur dédié, les analysent et lui retourne le
résultat [26]. Ils existent plusieurs autres applications et projets dont on cite Genom pour
la recherche dans la cellule humaine, Farsite de Microsoft ou encore Globe.
3.5.2 Collaboration
Le travail collaboratif, de plus en plus populaire, intéresse les entreprises et les

particuliers. Les applications de collaboration vont de la simple communication par chat
ou messages instantanés au travail commun sur un projet distribué. Au sein d’une
entreprise, elles permettent, à l’image de Groove, un échange en temps réel entre les
postes de travail de l’institution ainsi qu’avec les partenaires sociaux travaillant sur le
même projet, et cela dans un environnement distribué, sécurisé et confidentiel. On trouve
aujourd’hui une multitude d’applications de communication et de coopération, avec par
exemple Jabber, ICQ ou Skype pour la communication et Groove, Ikimbo ou Ocolus
pour le travail collaboratif [26].
A l’exemple de Doom, les jeux en réseaux, dont l'architecture est affranchie de toute
autorité centrale font également partie des applications de collaboration P2P.
3.5.3 Partage et distribution de contenu
Le succès grandissant réalisé par les systèmes P2P, est dû en partie à l’échange
grand public de fichiers de musique ou vidéo. Ce domaine rassemble plusieurs
applications dont les plus connues GNUTella, Kazaa, eDonkey, eMule, Bittorent, et
d’autres moins connues comme iMesh, Morpheus.
Comme avec l’échange, un autre type d’application relatif aux fichiers et à leur accès par
le biais du modèle P2P concerne le stockage de fichiers. On trouve plusieurs applications
telles que CFS, PAST ou OceanStore qui sont toutes construites sur base de tables de
hachage distribuées et qui proposent de construire un système de fichiers de type
distribué parmi une communauté de pairs. L’objectif est de fournir un service similaire à
NFS (Network File System) qui ne nécessite aucune architecture centralisée [26].
24
3.5.4 Plates-formes de développement
La diversité d’applications utilisées pour l’échange P2P illustre la richesse de ce

modèle, cependant cette même diversité a mis en évidence le manque d’interopérabilité
entre ces applications ne donnant pas le choix d’accéder aux ressources d’un nœud
utilisant une application différente. Pour résoudre ce problème, plusieurs plates-formes
faisant abstraction de toutes les différences sont proposées pour permettre le
développement d’applications suivant le même paradigme.
Jxta une initiative de Sun, étant une des premières propositions de plate-forme générique
et est actuellement une des plus complètes et des plus déployées [26]. Microsoft, de son
côté propose deux infrastructures pour le développement des applications P2P. La
première est une extension de la plate-forme de développement de services web .NET.
La seconde proposition s’appelle Windows Peer-to-Peer et propose un ensemble de

mécanismes utilisables par les concepteurs d’applications Windows pour développer des
services P2P [26]. Concernant les propositions faites par les instituts universitaires, on
cite Shine et Anthill.
Nous citerons aussi le middleware Corba qui offre tout un éventail de bus dont JacORB
avec lequel nous allons travailler.
3.6 Conclusion
Nous avons pu constater que le modèle P2P est adéquat à plusieurs situations
nécessitant la mise en relation de machines en vue d’échanger des contenus ou
d’effectuer des calculs répartis ou encore de la sauvegarde, autrement il offre des
fonctionnalités très intéressantes pour les applications distribuées nécessitant une
puissance de calcul importante. Il constitue une alternative aux systèmes client serveur
pour résoudre des problèmes dont ces derniers sont incapables de faire.
Nous avons vu au cours de ces trois chapitres différentes architectures des réseaux
existants et les techniques de routages utilisées dans chacune. Dans la partie suivante
nous donnerons une nouvelle approche de routage dans les réseaux P2P.
25
Partie II
Nous avons consacré cette seconde partie de notre mémoire à la présentation de

notre proposition qui porte sur une nouvelle approche pour le routage dans les réseaux
peer to peer. Par cette approche, nous visons surtout à réduire la charge du réseau en
diminuant le nombre de messages utilisés pour réaliser une communication entre deux
nœuds quelconques. Cette partie est scindée en trois chapitres en continuant la
numérotation suivant la première partie.
Dans cette deuxième partie nous utiliserons fréquemment le terme "servent" pour
signifier que les nœuds du réseau jouent tous un rôle identique.
Chapitre Quatrième
Problématique
Des observateurs d’industrie disent des systèmes peer to peer qu’ils deviennent
une technologie réseau de plus en plus importante [34]. Ce type de réseaux offre des
capacités accrues pour répondre aux besoins croissants des organisations en ressources
de traitement et de stockage.
Des plateformes récentes pour exécuter des applications réparties utilisent la technologie
du peer to peer pour interconnecter les machines qui les composent. Comme nous l’avons
expliqué dans les précédents chapitres, les nœuds du réseau dans le modèle pur se
comportent à la fois comme client et serveur. Ainsi n’importe quel nœud est susceptible
d’envoyer et de recevoir des requêtes vers et en provenance des autres nœuds. Cela exige
de concevoir une politique de routage des messages entre les pairs sans pour autant
recourir à un serveur central permanent.
Pour le routage des messages échangés sur le réseau, chaque protocole tente d’optimiser
le nombre de messages qui traversent d’un pair à un autre et garantir ainsi une stabilité du
système [33]. La recherche de chemins et surtout du plus court chemin reste un critère de
performance très important. Tout protocole de routage essaie de réduire les délais
d’attente et pallier aux problèmes de défaillance des nœuds et leur caractère dynamique.
26
Chapitre Quatrième Problématique
Si la réponse à une requête n’existe pas sur le réseau, on devrait interroger tous les nœuds
du réseau pour pouvoir le confirmer. Cela suppose un parcours exhaustif qu’il faut
réaliser sans pour autant générer des surcharges inutiles sur le réseau.
27
Chapitre Cinquième
Proposition
5.1 Introduction
Plusieurs protocoles de routage, des structurés aux non structurés, dédiés aux
systèmes peer to peer ont été conçus et chacun implante sa propre politique de routage.
Nous citons à titre de rappel CHORD ou PASTRY qui utilisent les tables de hachage
distribuées pour structurer le réseau, ou encore Gnutella qui suit le modèle non structuré
pur et qui utilise l’inondation pour propager les messages en désignant aléatoirement ses
voisins dans le réseau, ce qui est un inconvénient vue la charge induite [32]. Dans cette
section, nous présentons un nouveau protocole de routage dans un système peer to peer
qui utilise le principe des algorithmes à quorums et plus exactement le principe de
permissions d’arbitres proposé dans [35] pour optimiser le nombre de messages émis sur
le réseau. Nous allons d’abord présenter ce principe puis nous décrirons le
fonctionnement du protocole. Dans la présentation du principe, nous décrirons les
critères de construction d’ensembles d’arbitres, sans toutefois proposer de mécanisme
pour sa réalisation, ce problème sort de notre champ d’étude. Nous ne traiterons que de
l’utilisation de ces ensembles pour réaliser le routage, et nous montrerons les avantages
de l’utilisation de notre proposition.
28
Chapitre Cinquième Proposition
5.2 Principe des permissions d’arbitres [35]
Le principe des permissions d’arbitres a été introduit pour résoudre les

problèmes d’exclusion mutuelle et l’allocation de ressources critiques. En effet, le
système réparti est conçu tel qu’à chaque site i est associé un ensemble d’autres sites
qu’on nomme les arbitres du site i, l’ensemble associé au site i est noté Ri. Les
algorithmes basés sur ce principe constituent une famille qu’on appelle algorithmes
fondés sur les permissions d’arbitres. Il existe une autre famille qui est basée sur des
permissions individuelles où chaque site gère individuellement chacun des conflits qui le
mettent en compétition avec les autres sites. Ainsi, un site i peut donner son autorisation
à plusieurs autres sites simultanément.
A l’inverse dans les algorithmes à permissions d’arbitres, un site i n’accorde sa

permission à un moment donné qu’à un seul autre site parmi ceux qui l’ont sollicitée.
Toutefois un site qui a obtenu toutes les permissions qu’il a demandé doit les rendre à sa
sortie de section critique. Pour réaliser cela on considère les règles ou contraintes sur la
construction des ensembles d’arbitres. La première règle à respecter est :
Cette condition assure que 2 sites ou nœuds quelconques demandent la permission à au

moins un site commun qui décidera lequel des deux obtiendra la section critique. Celui-ci
joue le rôle d’arbitre pour leurs conflits. La figure suivante montre deux sites A et B qui
veulent accéder à la section critique. Chacun sollicite donc son ensemble d’arbitre, en
gras sur le schéma, pour obtenir leurs permissions. Si le site A est le premier à obtenir la
permission de leur arbitre commun alors il va accéder à la section critique. Le site B sera
donc empêché d’accéder à la section critique. Il va attendre son tour et n’obtiendra la
permission jusqu’à ce qu’elle soit remise à l’arbitre par le site A.
29
B veut s-c
A veut s-c
Arbitre
commun
Figure 5.1. Rôle décisif d’un arbitre
5.2.1 Contraintes sur les ensembles Ri
Le but de poser ces deux contraintes est d’obtenir un algorithme réparti

« symétrique » dans lequel chaque nœud va jouer le même rôle que les autres. Ces
contraintes s’énoncent comme suit :
(c1) :
(c2) :
La contrainte (c1) exprime que tous les sites doivent demander et obtenir le même
nombre de permissions pour pouvoir entrer en section critique ; la contrainte (c2) indique
que chaque site joue un rôle d’arbitre pour le même nombre de sites. La première garantit
la règle du même effort et la deuxième celle de la même responsabilité. Ce principe
devient très intéressant surtout pour des valeurs de K et D raisonnablement petites
permettant de construire des ensembles Ri petits.
5.2.2 Construction d’ensembles Ri optimaux
Pour construire des ensembles Ri optimaux, on cherchera à minimiser les valeurs

de K et D précédemment citées. Mais le plus important encore est de savoir construire
30
ces ensembles d’arbitres. Dans la suite de notre travail, on ne va pas donner de méthodes
de construction mais uniquement quelques unes de leurs propriétés. Par ailleurs, notre
travail va concerner le routage des messages entre les nœuds en utilisant ces ensembles
pour contrôler leur propagation à travers le réseau.
Considérons un ensemble Ri. La contrainte (c2) permet de déduire que tout

élément j de Ri appartient à (D-1) autres ensembles ; or suivant la contrainte (c1) il y a K
éléments dans Ri. On déduit que le nombre maximum d’ensembles qui peuvent être
construits et qui satisfont la propriété d’intersection est égal 1+K(D-1).
Les contraintes (c1) et (c2) lient les valeurs K et D. On obtient n=K*n/D avec n est le
nombre de nœuds dans le réseau. On a divisé le nombre total (union de tous les
ensembles) des nœuds sur le nombre de fois qu’ils sont répétés. Le cas optimal où la
répétition est réalisée exactement D fois permet de déduire que K=D. Ainsi on déduit que
le nombre maximum d’ensemble est 1+K(D-1) = 1+K(K-1) = n, on a autant d’ensembles
d’arbitres que de nœuds. Cette dernière formule est équivalente à , cela veut
dire que le cardinal des ensembles d’arbitres est proportionnel à , la racine carrée du
nombre de nœuds.
Pour réaliser la répartition des nœuds dans les ensembles d’arbitres en respectant
les contraintes su-citées on utilise les plans projectifs finis (Annexe A). Ces plans sont
très utiles pour certains nombres dont on sait construire les plans correspondants, car ils
permettent une construction rapide et optimale des ensembles. Cependant ils sont
difficiles à réaliser pour des nombres importants.
Plan projectif fini
Trouver n ensembles Ri qui satisfont la contrainte d’intersection précédente est

équivalent à trouver un plan projectif fini de n points. Un point représente un nœud et
une ligne du plan représente un ensemble Ri.
Il existe des plans projectifs finis d’ordre k lorsque k=p m tel que : m un entier positif et p
un nombre premier. Un tel plan possède k(k+1)+1 points et autant de lignes. Les
propriétés des plans projectifs finis sont telles que chaque point est sur k+1 lignes et que
chaque ligne contient k+1 points, deux points distincts ont une seule ligne en commun et
deux lignes distinctes ne se rencontrent qu’en un point. Donc deux lignes Ri et Rj n’ont
31
qu’un nœud en commun c'est-à-dire qu’on a obtenu une intersection minimale

( ). La figure suivante illustre le cas optimal de 7 nœuds, on peut
remarquer que la structure de communication définie par un plan projectif fini est
régulière.
Les ensembles d’arbitres : 1
R1 = {1,2,4} 2
R2 = {2,6,7} 3
6
R3 = {1,3,7}
R4 = {3,4,6}
R5 = {2,3,5} 4 7
R6 = {1,5,6} 4 5
R7 = {4,5,7}
Figure 5.2. Plan projectif fini d’ordre 2
5.2.3 Construction d’ensembles Ri presque optimaux
Cette approche est très intéressante du fait que même si on ne dispose pas d’un
nombre de nœuds satisfaisant la condition définie pour un plan projectif fini, on peut
quand même construire des ensembles d’arbitres, appelés des ensembles presque
optimaux. Ainsi, dans le cas où il n’existe pas de plans projectifs finis deux attitudes sont
possibles :
 Affaiblir les contraintes c1 et c2.

On cherche l’ordre k du premier plan projectif (voir Annexe A) que l’on sait
construire tel que n≤ k(k+1)+1 et l’on crée k(k+1)+1-n sites fictifs supportés de
façon la plus équitable possible, par les sites effectifs. C'est-à-dire on augmente le
nombre n de nœuds avec le nombre fictif nécessaire pour atteindre le nombre qui
permettra la construction du prochain plan projectif fini. Ensuite, on répartit
équitablement les nœuds fictifs sur les nœuds effectifs et lors de la construction
on remplace les nœuds fictifs par les nœuds effectifs qui leur correspondent. Si on
reprend l’exemple précédent avec 5 nœuds seulement, on place les sites fictifs 6
et 7 sur les sites effectifs 2 et 5 respectivement et on confond 6 avec 2 et 7 avec 5,
on obtient les ensembles d’arbitres :
32
R1 = {1,2,4}
R2 = {2,5}
R3 = {1,3,5}
R4 = {2,3,4}
R5 = {2,3,5}
 Ne plus chercher des ensembles Ri de taille minimale.

Dans ce cas il existe une solution très simple. On regroupe les n sites dans une
matrice carrée de taille et l’ensemble Ri d’un site contient les sites placés
sur la même ligne et la même colonne que lui. Toutefois la solution n’est pas
optimale car deux ensembles Ri et Rj peuvent avoir de 1 à éléments en
commun, or dans le cas optimal l’intersection est un singleton. La construction
des ensembles pour l’exemple précédent composé de 5 nœuds nous donne un
ensemble R5 de cardinalité égale à 6.
12 8 5 9
R5={12,8,5,9,13,10}
6 2 13 1
4 3 10 7
11 14 / /
Figure 5.3. Une Structure de communication matricielle
5.3 Description du protocole
Notre protocole de routage suit le modèle des systèmes peer to peer pur. Il est
fondé sur le principe des permissions d’arbitres. Suivant ce principe, le réseau est
structuré virtuellement en des ensembles d’arbitres. On suppose que les nœuds formant le
réseau sont regroupés dans des ensembles en respectant les contraintes de construction c1
et c2 énoncées ci-avant. Lors de la construction on essaie de réaliser la répartition la plus
optimale mais cela a trait au nombre de nœuds présents. Ainsi, si ce nombre vérifie la
condition d’optimalité alors un minimum de messages sera généré par notre protocole.
Nous rappelons que notre protocole de routage ne se préoccupe pas de la construction de
ces ensembles.
Structure des messages
33
On définit quatre types de messages :
Un message « requête » : il comporte les informations sur le nœud émetteur (identifiant

et adresse), des informations sur ce qu’il cherche et un numéro de séquence pour
l’identifier d’une façon unique sur le réseau et éviter de traiter un message déjà traité.
Un message « réponse » : il comporte l’adresse de l’émetteur de la requête qui permettra

de lui acheminer la réponse, le même numéro de séquence que la requête à satisfaire, et
la réponse à la requête reçue. (si on ne se limite pas à la recherche et localisation alors on
rajoute l’adresse du nœud qui renvoie la réponse)
Un message « ACK » : il comporte l’identifiant du nœud (arbitre) qui le génère,

l’adresse du nœud qui a envoyé la requête (arbitré) et le numéro de séquence de la
requête dont il connait un destinataire. Il est généré par un arbitre pour informer le nœud
arbitré qu’il connait la destination.
Un message « Abort » : ce message est généré par un servent pour ordonner à ses
arbitres (sauf celui qui a envoyé ACK) d’abandonner la dernière requête qu’il leur avait
adressé. Ce message inclut aussi le numéro de séquence pour pouvoir identifier cette
requête.
Un nœud qui cherche à communiquer avec un autre nœud du réseau doit le

solliciter en lui envoyant un message requête véhiculant l’information sur les ressources
recherchées. A la réception, le destinataire du message répond directement au nœud
émetteur via son adresse en lui envoyant le message réponse contenant les données
recherchées.
Pour faire parvenir le message à sa destination, il sera routé d’arbitre en arbitre. Un nœud
émetteur d’une requête va l’envoyer uniquement à son ensemble d’arbitres qui vont
l’acheminer vers sa destination si elle existe.
Avant d’envoyer sa requête, le nœud vérifie si le destinataire n’est pas un de ses arbitres
puis il envoie un message requête vers chacun. A la réception de la requête, un arbitre
vérifie s’il ne l’a pas déjà traité en comparant son numéro de séquence. Si ce n’est pas
déjà traité il consulte son ensemble d’arbitres ; à lui ; pour voir si le destinataire en fait
partie et cela en comparant leurs adresses. S’il trouve que le destinataire est
effectivement un de ses arbitres alors il renvoie un message d’acquittement ACK au
34
nœud qui lui a transmis la requête (nœud arbitré). Le message ACK comporte
l’identificateur de l’arbitre qui connait le destinataire et le numéro de séquence de la
requête. A partir de ce message un servent déterminera les autres arbitres auxquels il
enverra un message d’annulation (abort) et la requête concernée par cette annulation. Le
message d’annulation doit aussi véhiculer le numéro de séquence de la requête à
abandonner. Cela empêche une génération de messages inutiles. En effet, à partir du
moment où on a trouvé le nœud recherché tout message propagé est considéré superflu.
Un arbitre qui a reçu une requête dont il ne connait pas le destinataire doit soit la
propager soit la détruire. Cependant, avant de propager une requête un arbitre doit
attendre un délai « d » déterminé et puis décider de ce qu’il va faire. Ce délai peut être
estimé au maximum de la période que met un message pour aller d’un nœud arbitre vers
un nœud arbitré et revenir. Autrement dit, si le temps nécessaire à un message de passer
d’un nœud vers ses arbitres et Ti tel que alors on
obtient : .
Pendant ce délai un arbitre peut recevoir un message d’annulation lui indiquant
d’abandonner une requête en attente de propagation. Si ce n’était pas le cas alors il
propage la requête à ses arbitres. L’organigramme de la page suivante illustre le
fonctionnement du protocole sur chaque noeud.
35
Début
Non Générer Oui
Msg
Recevoir Msg Envoyer requête vers

arbitres
Msg = Requête Oui

Non Déjà Oui
Non
traitée ?
Msg=Ack Oui Destination

Non = moi Oui
Non
Envoyer Abort aux
Dans ce cas arbitres
Msg=abort
Non Destination Oui
connue ? Renvoyer réponse à
Détruire la requête en l’émetteur
attente de propagation
Attendre une période Envoyer requête vers

‘d’ l’arbitre destinataire.
Envoyer Ack à l’arbitré
Non Abort Oui
reçu ?
Propager la requête Détruire la requête
vers les arbitres
Fin
Figure 5.4. Organigramme de fonctionnement d’un servent.
36
Algorithme de la proposition
L’algorithme suivant retrace l’organigramme précédent et montre le fonctionnement du
protocole sur n’importe quel servent.
ensemble m=ensemble_des_arbitres_du_noeud ;
Si (servent en cours est l’initiateur de la requête)
alors {Envoyer_Requête vers m ;}
Si (Recevoir_Requête) alors
Si(Requête_déjà_traitée) alors {Detruire_Requête ;}
Sinon Si (destination_est_moi) alors {Renvoyer_Réponse ;}
Sinon Si (destination_connue)
alors {Envoyer_Requête à destinantion ;
Renvoyer_ACK à l’arbitré;}
Sinon (Attendre(d) ;)
Si (Recevoir_Abort) alors {Détruire_Requête ;}
Sinon { Envoyer_Requête à m ;}
Sinon Si (Recevoir_ACK) alors {Envoyer_Abort à (m-1) ;}
Sinon {Detruire_Requête ;}//cette instruction est exécutée lors de la
récetption d’un message "abort".
Algorithme 5.1. Algorithme du protocole.
37
Un protocole allégé
Nous nous sommes proposé d’implanter le protocole sous corba mais pour son
implantation nous avons choisi de l’alléger, et réaliser un premier incrément qu’on
complètera par la suite pour atteindre toutes les fonctionnalités du premier protocole.
Nous allons décrire cette deuxième version. C’est cette version qui fera l’objet de notre
première application.
Structure des messages
Le message « requête » : on ajoute, pour le besoin de notre application un champ « hop »

pour sauver le nombre de sauts effectués par un message pour arriver à destination. Ce
champ servira à l’estimation du nombre de messages générés par le protocole sur le
réseau.
Le message « réponse » : ce message véhicule l’adresse de l’émetteur de la requête et

l’information utile à sa demande.
Dans cette version, on utilise deux messages uniquement pour établir les
communications entre les servents. On ne va pas tenir compte des messages générés
après avoir trouver la destination. Cela va nous éviter de générer les messages
d’acquittement et les messages d’annulation ainsi que le temps d’attente accompagnant
leur utilisation. Le protocole se résume à envoyer des requêtes et des réponses. Un
servent intermédiaire (un arbitre) se contente de vérifier s’il connait la destination pour
n’acheminer le message que vers celle-ci ou bien il va le propager vers tous ses arbitres.
On utilise le terme propager pour expliciter que l’opération d’envoi d’un message est
réalisée par un arbitre. Une fois le message est parvenu à sa destination celle-ci renvoie
directement la réponse à l’émetteur. L’organigramme sur la page suivante montre le
fonctionnement du protocole sur chaque servent.
38
Début
Non Générer Oui

Msg
Envoyer requête vers

Recevoir requête les arbitres
Déstination
Oui = moi Non
Non Destination Oui

connue ?
Renvoyer réponse
Propager la requête Envoyer requête vers

vers les arbitres la destination
Fin
Figure 5.5. Organigramme de fonctionnement d’un servent suivant le protocole allégé.
39
Algorithme du protocole allégé
Cet organigramme nous fournit une version plus simple de l’algorithme de routage.
ensemble m=ensemble_des_arbitres_du_noeud ;
Si (servent en cours est l’initiateur de la requête)
alors {Envoyer_Requête vers m ;}
Si (Recevoir_Requête) alors
Si(Requête_déjà_traitée) alors {Detruire_Requête ;}
Sinon Si (destination_est_moi)
alors {Renvoyer_Réponse ;}
Sinon Si (destination_connue)
alors {Envoyer_Requête à destination ;}
Sinon { Envoyer_Requête à m ;}
Algorithme 5.2. Algorithme du protocole allégé.
5.4 Comparaison
Le fonctionnement de notre protocole repose sur le principe des permissions

d’arbitres qui constitue une famille particulière des algorithmes à quorums [35]. Donc
notre protocole vérifie la condition de l’intersection deux à deux non vide des ensembles
d’arbitres. Cela nous assure qu’une requête visitera tout le réseau avant qu’elle soit
abandonnée s’il n’y a pas de réponse trouvée, et si la réponse existe elle sera trouvée.
Cependant un nœud ne propage sa requête que vers son ensemble d’arbitres.
Les arbitres dans notre protocole peuvent être comparés aux serveurs ou super-nœuds
dans les systèmes pair à pair hybrides qui sont les premiers nœuds contactés lors de la
recherche d’information sur le réseau. Ces super-nœuds ont la responsabilité de propager
les requêtes vers leurs destinataires ou vers d’autres super-nœuds afin de trouver
l’information recherchée. Dans les systèmes pair à pair hybrides, cette tâche est assurée
40
par un nombre de nœuds (super-nœuds) déterminé et relativement petit, par exemple

dans Gnutella 2, il y a 10 super-nœuds pour 100 nœuds ordinaires [27]. Or dans notre cas
cette tâche est assurée par chaque nœud vis-à-vis des nœuds dont il est arbitre.
Chaque fois qu’un nœud propage une requête, il le fait vers le même nombre d’arbitres
donc il génère le même nombre de messages. Les ensembles d’arbitres sont construits de
façon à avoir le même nombre de nœuds dans chacun. Un nœud quelconque qui ne
connait pas la destination recherchée, contactera uniquement ses nœuds ‘arbitres’ pour
leur envoyer la requête. On trouve un principe similaire dans les réseaux P2P structurés à
contenu adressable (CAN), où un nœud maintient une table de routage qui contient les
identificateurs des nœuds adjacents et leurs adresses IP [33]. Dans les réseaux ad hoc, le
protocole FSR (Annexe A) utilise l’approche à plusieurs niveaux dans le but de réduire le
nombre de messages dans le réseau. Plus on s’éloigne du premier niveau (nœuds voisins)
moins de messages sont générés sur le réseau, c'est-à-dire un nœud génère plus de
messages vers ses voisins.
Dans le but de réduire encore le nombre de messages, nous avons intégré dans le
fonctionnement du protocole un temps d’attente « d ». Un nœud qui ne possède pas
d’informations sur la destination doit attendre ce délai avant de propager la requête à ses
arbitres. Cela permet d’éviter la génération de messages superflus après avoir trouver la
destination. Un mécanisme semblable est utilisé dans le protocole FSR pour minimiser le
nombre de message d’information générés suite aux fréquentes déconnexions entre les
nœuds du réseau. Ainsi, au lieu d’envoyer un message d’information au voisin à chaque
déconnexion, un nœud maintient une entrée pour chacun de ses voisins dans sa liste de
voisins. Si un nœud ne reçoit pas de son voisin un message de mise à jour dans un délai
déterminé il supprime de ses tables toutes les informations le concernant et considère que
le lien qui les relie est corrompu.
Nous utilisons dans les messages échangés entre les nœuds un champ numéro de
séquence pour identifier de manière unique un message dans le réseau et éviter de le
traiter plus d’une fois. Ce champ est utilisé aussi dans le protocole Gnutella pour
identifier ses descripteurs.
Notre protocole présente les avantages suivant :
 Son fonctionnement n’est pas compliqué à mettre en œuvre.
41
 Il ne nécessite pas l’utilisation de plusieurs tables de routages pour implanter ses

fonctionnalités, il suffit de gérer convenablement les ensembles d’arbitres.
 Il offre plusieurs chemins pour atteindre une destination précise à partir de
n’importe quel nœud de départ. Donc il s’adapte bien à la mobilité des nœuds,
plusieurs alternatives existent dans le cas où le chemin emprunté contient un
nœud défaillant.
 L’interconnexion des ensembles d’arbitres n’est pas vide. Cela nous assure que si
une réponse à une requête existe elle sera trouvée sinon on peut confirmer que
cette réponse n’existe pas et la requête sera abandonnée. Donc le protocole est
exhaustif.
 Il utilise un nombre de messages relativement petit (selon la distance) pour établir
une communication entre les nœuds, et diminue considérablement la charge du
réseau si on le compare à l’inondation utilisée dans Gnutella.
Néanmoins, notre proposition est simpliste et reste encore à un stade de conception

primitif. Ainsi le protocole reste encore non adapté au cas des réseaux scalables car
aucun mécanisme n’est défini pour la prise en charge et l’intégration dynamique d’un
nœud dans le réseau.
5.5 Conclusion
Nous avons présenté, dans cette partie, notre proposition pour améliorer la
fonction de routage dans les systèmes et réseaux peer to peer. Cette proposition s’inscrit
dans le modèle pur de ces systèmes. Elle présente l’avantage d’être légère, elle utilise un
algorithme simple pour ses échanges. Elle minimise la charge du réseau en termes de
nombre de messages. Elle utilise le principe des arbitres et par conséquent chaque nœud
a la même responsabilité et fournit le même effort.
42
Chapitre Sixième
Conception et Réalisation
Nous avons choisi le langage de modélisation UML pour modéliser notre

application pour deux raisons. Premièrement, UML est un langage de modélisation basé
sur le concept de l’objet permettant de décrire formellement le fonctionnement d’une
application décrite suivant ce concept. Deuxièmement, sa réalisation sera faite suivant la
norme Corba qui est aussi basée sur le concept de l’objet.
Dans cette section, nous allons concevoir notre application suivant le langage UML.
Nous utiliserons pour cela les diagrammes du langage pour décrire son fonctionnement.
Les diagrammes de classes, d’objets, de communication, d’états-transition et le
diagramme de séquence seront utilisés.
6.1 Modélisation
Les nœuds du système constituent les objets de notre application. Comme nous
traitons le cas d’un système peer to peer pur où tous les nœuds jouent le même rôle, les
objets qu’on va utiliser seront tous du même type. En effet, ils effectuent les mêmes
opérations sur le même type et même structure de données. Ces opérations sont l’envoi
et la réception de messages. Pour modéliser cela, on n’a besoin que d’une seule classe
43
Chapitre Sixième Conception et Réalisation
qu’on va identifier par le nom « Servent ». Dans la suite, on désignera indifféremment

par nœud ou servent les objets du système.
Cette classe aura pour attributs :
Un identifiant de type chaine de caractères, une adresse de type entier et une variable qui
contiendra l’ensemble des identifiants de ses arbitres.
Les opérations de la classe qui utilisent les données précédentes sont :
Envoyer (msg) : cette méthode réalise l’envoi d’un message d’un nœud servent vers un
autre.
Recevoir (msg) : une fois un message est reçu par un servent, cette opération détermine
les traitements à réaliser.
La représentation de la classe « servent » suivant le formalisme UML est la suivante :
servent
Id : char
Adr :long
Figure 6.1. Représentation de la classe « servent » Arb : {id1,…}
Envoyer(msg)
Recevoir(msg)
6.1.1 Diagramme de classes
Ce diagramme va nous permettre d’expliciter les associations entre les objets au niveau
des classes. On va désigner cette association par le nom « communiquer » qui englobe
dans son sens l’envoi et la réception de messages. Cette association peut exister entre
tous couple d’objets de l’application. Sur un diagramme de classes, cette association sera
représentée par un lien entre les deux classes dont les objets sont des instances. Or dans
notre cas, tous les objets instancient la même classe Servent, donc cette association sera
44
réflexive sur la classe Servent. Toutefois, au niveau concret des objets, les liens associent
des instances différentes de la classe. On obtient le diagramme de classe suivant :
Communiquer
1..*
Servent
Figure 6.2. Diagramme de classes
1..*
Le degré de multiplicité sur le diagramme exprime les nombres minimum et maximum

de fois qu’un objet participe à la relation communiquer avec les autres objets du système.
Dans notre cas un nœud peut communiquer avec n autres nœuds, cela est représenté par
une étoile sur le diagramme. Cela est interprété comme suit : pour une instance de la
classe servent, est associée une ou plusieurs autres instances de la même classe.
6.1.2 Diagramme d’objets
Le diagramme d’objets suivant illustre les associations au niveau des objets ou des
nœuds du système. Le degré de multiplicité est clairement montré du fait que toutes les
relations sont explicitées par des liens d’association. On utilise le même nom que la
classe pour désigner un objet et on le précède de deux points ainsi qu’un soulignement
pour signifier que c’est un objet quelconque. Le diagramme suivant montre des relations
d’un degré de multiplicité égal à 1, 2 et 3. En général, si notre système serait composé de
n nœuds alors un nœud est susceptible d’avoir (n-1) relations avec le reste des nœuds.
: Servent
Communiquer
Communiquer : Servent
Communiquer
: Servent
: Servent
Communiquer
Figure 6.3. Diagramme d’objets
45
6.1.3 Diagramme d’états
Un état est une situation dans laquelle peuvent se trouver les objets d’une classe pendant
une période de temps. Durant sa participation au réseau, un nœud se trouve parfois dans
un état client et d’autres fois dans celui de serveur selon qu’il demande ou bien satisfait
les demandes des autres nœuds en ressources. Un nœud initiateur d’une requête est
considéré client vis-à-vis des destinataires qui la recevront et donc ceux-ci sont des
serveurs. A son tour, il est considéré serveur vis-à-vis des autres nœuds lui adressant
leurs requêtes.
Le diagramme d’états associé à la classe servent gère les deux états client et serveur qui
sont explicites sur la figure. Les deux rectangles représentent chacun des deux états. Les
deux flèches expriment les événements qui font transiter un nœud de l’état client vers
celui de serveur et vice versa. Comme illustré sur la figure, la réception d’un message
requête met le servent dans l’état serveur. L’événement d’envoi d’une requête le met
dans l’état client.
Recevoir requête ()
Client Serveur
Envoyer requête ()
Figure 6.4. Diagramme d’état.
6.1.4 Diagramme de communication
Ce diagramme montre les interactions entre des objets et les messages qu’ils s’échangent.
Un objet servent émet un message requête vers un autre servent le sollicitant pour des
informations que ce dernier enverra dans un message réponse. Ces interactions seront
montrées plus clairement sur le diagramme de séquence.
46
Requête
: Servent : Servent
Réponse
Figure 6.5. Diagramme de communication
6.1.5 Diagramme de séquence
Ce diagramme visualise mieux la séquence des messages échangés, présentée sur le

diagramme de communication précédent. Le diagramme de séquence nous donne la
possibilité de représenter ces échanges dans le temps, de montrer la synchronisation des
envois ainsi que les conditions d’envoi.
Dans notre système, un servent réalise trois types d’opérations de communications. La

première est l’opération d’envoi d’une requête, cette opération peut être interprétée de
deux façons selon que le servent est son initiateur ou qu’il n’est qu’un nœud
intermédiaire qui la fait propager vers d’autres nœuds (ses arbitres). La deuxième
opération est la réponse à une requête reçue. Nous donnons deux diagrammes de
séquence, le premier traitera du cas général des opérations subies par une requête
circulant sur le réseau et le deuxième indique clairement l’initiateur de la requête et le
nœud qui lui renvoie la réponse. Ce deuxième diagramme nous sert uniquement pour
indiquer qu’un servent capable de satisfaire une requête renvoie directement sa réponse à
son initiateur. Dans ce qui suit nous expliquons le diagramme du cas général où un
servent transmet une requête dont il n’est pas nécessairement son initiateur et montre le
comportement du servent récepteur.
Le diagramme montre un servent envoyant une requête vers un autre servent, le servent
récepteur de la requête n’est pas nécessairement son destinataire. Si le nœud qui a reçu le
message peut le satisfaire alors il renvoie directement la réponse à son initiateur sinon il
le propage à son ensemble d’arbitres. Cela est indiqué sur le diagramme par un cadre
scindé latéralement en deux sous-cadres, par une ligne discontinue. Chaque sous-cadre
contient une alternative à exécuter par le servent à sa réception d’une requête. Cette
alternative est indiquée par l’opérateur « Alt » placé en haut du cadre. La condition sur le
choix d’une alternative est indiquée entre crochet.
47
L’opération de propagation est répétée par chaque servent qui ne peut pas satisfaire une
requête. Pour montrer cela sur le diagramme, nous avons utilisé un cadre qui englobe
l’opération de propagation de la requête. Cette répétition est indiquée par l’opérateur
« Loop » exprimant l’itération et il est placé en haut du cadre. Cette opération de
propagation sera répétée par chaque servent récepteur jusqu’à l’obtention de la réponse
ou que le message soit détruit.
: Servent : Servent : Servent
Requête
alt loop
Réponse [succès]
[échec] Requête propagée
Figure 6.6. Diagramme de séquence (cas général).
Il reste à expliciter le cas où un servent initie une requête sur le réseau et un servent
destinataire capable de satisfaire cette requête va répondre en lui envoyant directement la
réponse sans passer par d’autres servents. Le diagramme de séquence suivant illustre ce
cas.
48
: Servent initiateur : Servent : Servent destinataire
Requête
alt loop
[succès] Réponse
[échec]
Requête propagée
Réponse
Figure 6.7. Cas Succès (réponse retournée).
6.2 Réalisation
Dans cette section, nous allons présenter les concepts du bus utilisées pour
réaliser notre application et nous décrirons son fonctionnement.
6.2.1 Interface et service nommage dans jacorb [38]
Jacorb est l’une des implantations du bus corba écrite dans le langage de
programmation Java. Ce bus comme les autres fonctionne selon le modèle client/serveur
et utilise la notion d’objet : les applications clientes accèdent aux objets instanciés par les
applications serveurs via leurs méthodes. Les concepts de ce modèle objet sont données
dans l’annexe B de ce rapport sous le titre "les notions utilisées par le bus", et nous y
avons donné aussi des indications sur la configuration du bus et son installation.
49
 Interface IDL
Parmi les concepts de corba, les interfaces constituent l’élément clé de son
modèle objet. Ces interfaces définissent un type abstrait d’objets CORBA, c'est-à-
dire l’ensemble des opérations et des attributs de ses instances. Elles précisent la
signature de chaque opération : la liste de paramètres, les types de données
autorisés pour ceux-ci et leur mode de passage entre l’application cliente et
l’objet. Les opérations peuvent avoir des paramètres en entrée et/ou en sortie. De
plus, une signature peut contenir la liste des exceptions que l’opération
déclenchera en cas de problème. Les attributs permettant d’exprimer des
fonctions d’accès à une propriété d’objet.
Pour décrire ces interfaces, l’OMG fournit un langage standard de définition
appelé « Interface Definition Language » ou IDL. Ce langage est indépendant de
tout langage de programmation et les objets corba peuvent être implantés dans
n’importe quel langage. Pour pouvoir exploiter les définitions IDL,
l’environnement CORBA fournit des précompilateurs IDL qui transforment ces
définitions en constructions utilisables depuis des langages de programmation.
 Le service nommage
Le service de nommage est le service le plus généralement utilisé dans CORBA.

Il fournit un système de désignation pour retrouver les objets à partir d’un nom
symbolique. Ce système est organisé en graphe de répertoire contenant les
références sur les objets.
Le service de nommage de ressource permet aux utilisateurs et à leurs
programmes de retrouver dynamiquement à l’exécution, les objets qui leur sont
nécessaires. Ce service est constitué d’un graphe de contexte de nommage
interconnecté, chaque contexte gère une liste d’association nom-référence. A
l’intérieur d’un contexte, chaque nom doit être unique mais un objet peut être
désigné par plusieurs noms dans un ou plusieurs contextes.
6.2.2 Description de l’application
L’application consiste en un ensemble de nœuds qui communiquent chacun avec

les autres et forment un système pair à pair. Le système est composé de 7 nœuds n1,…,
n7. A chaque nœud est associé un ensemble d’arbitres Ri. Chacun des ensembles contient
50
2 nœuds et . Dans ce cas l’intersection est minimale car il

vérifie les conditions de construction des ensembles optimaux.
6.2.2.1 Les interfaces IDL
Nous avons défini deux interfaces, une interface «Servent » et une interface
« Superviseur ».
La première déclare trois méthodes :

void receive(in long numdes, in long numsg,in long numserv, in string nomdes, in long
hops);
Rep send();
void answer(in long numdes, in long numsg,in long numserv, in string nomdes, in long
hops);
Les méthodes receive et answer prennent en entrée quatre entiers et une chaine
de caractère. Les entiers représentent respectivement le numéro du servent à atteindre, le
numéro de la requête (numéro de séquence), le numéro de l’expéditeur de la requête et
enfin le dernier représente le nombre de sauts effectués par la requête. La chaine de
caractères contient le descripteur du servent destination. Ces deux méthodes ne renvoient
pas de résultats.
La méthode send n’accepte aucun paramètre en entrée, par contre elle renvoie comme
résultat la structure Rep qui contient les même informations utilisées par les méthodes
send et receive.
La seconde interface déclare deux méthodes :

void info (in long numdes,in long numsg,in long numcli, in long numserv, in string
nomdes, in long hops);
void info1 (in long numdes,in long numsg,in long numcli, in long numserv, in string
nomdes, in long hops);
Ces deux méthodes utilisent les mêmes paramètres que les méthodes receive et answer,
tout en ajoutant le champ numcli qui indique le numéro du prochain destinataire de la
requête (arbitres).
La signification des paramètres utilisés par les méthodes :
numdest : ce champ véhicule l’identificateur du nœud ciblé par la recherche.
numsg : il contient le numéro de séquence de la requête.
51
numserv : il véhicule l’identificateur du nœud arbitre auquel sera envoyé la requête.
hops : ce champ sert de compteur pour le nombre de sauts effectués par une requête.
6.2.2.2 Description du fonctionnement de l’application
Comme décrit en haut, notre système se compose de sept servents que nous
nommons "Server", ils sont numérotés de 1 à 7. Ils jouent le rôle de nœuds du système.
Le schéma de la figure 6.8 illustre la communication entre les sept servents.
Début
S2 S7
S1 S6 S5
S4 S3
Superviseur
Message Requête
Si Servent i
Message Info
Message Info1
Figure 6.8. Schéma explicatif du fonctionnement de l’application
52
Le programme "Debut" ne fait que déclencher la recherche en invoquant la méthode

receive au niveau du "Server 1".
Figure 6.9. Le programme Debut
Les servents "Server" de 1 à 7 instancient tous l’objet Servent qui implante l’interface
servent et qui dispose des trois méthodes receive, send et answer. L’invocation de la
méthode receive est équivalent à l’envoi d’une requête, ceci provoque aussi l’invocation
de la méthode info du Superviseur et l’invocation de receive et send au niveau des
arbitres du nœud concerné, dans le cas où ce dernier n’est pas la cible de la recherche, ce
cas est illustré dans la figure 6.10. Dans le cas contraire, c'est-à-dire que c’est le nœud
cible, il se contentera d’invoquer la méthode answer au niveau du Server1 (initiateur de
la recherche), figure 6.11. Remarquons qu’à chaque invocation de la méthode receive au
niveau d’un nœud, ce dernier vérifie si elle n’a pas déjà été invoquée avec les mêmes
paramètres en entrée (même numéro de séquence). Les "Server" affichent, chacun, les
requêtes qu’ils reçoivent et qu’ils émettent. A l’exception du "Server1" qui en plus de ça
affiche la réponse qu’il reçoit du Server visé par la recherche, voir figure 6.12.
53
Figure 6.10. Un servent intermédiaire.
Figure 6.11. Le servent cible de la recherche.
Figure 6.12. Le servent initiateur de la recherche.
54
Le "Server 0" instancie l’objet Superviseur qui implante l’interface du même nom et qui
implémente les deux méthodes info et info1déjà définies dans l’interface. La méthode
info est invoquée à chaque fois que la méthode receive est invoquée. Cela permet au
superviseur d’avoir une vue globale sur le trafic du réseau. La méthode info1est invoquée
seulement par le Server ciblé par la recherche. Son rôle est d’afficher les messages qui
transitent dans le réseau. La figure suivante montre les messages affichés par le
superviseur.
Figure 6.13. Le superviseur.
55
6.3 Conclusion
Dans ce chapitre, nous avons présenté la conception d’une application fonctionnant

suivant le protocole allégé. Nous avons modélisé l’ensemble de ses règles d’échange et
de communication dans le langage UML.
Nous avons implémenté notre application sous jacorb pour le cas particulier de sept
nœuds. Ce dernier ayant la particularité d’avoir un plan projectif fini, ce qui nous a
permis de construire des ensembles d’arbitre optimaux pour mettre en évidence le
fonctionnement du protocole dans des conditions idéales, par conséquent avoir un aperçu
des possibilités qu’offre ce protocole pour minimiser le trafic du réseau sans altérer le
rendement (fonctionnement) initial.
Nous remarquons que notre proposition reprend les points forts du modèle pair à pair pur
(Gnutella), qui sont une auto-organisation du réseau donc pas besoin d’une
administration centralisé, une grande tolérance aux pannes et une grande mobilité des
nœuds, en y ajoutant un parcours exhaustif du réseau et un allégement du trafic du réseau
engendrant une meilleure exploitation des ressources du réseau sous-jacent.
56
Conclusion Générale
Nous arrivons donc au terme de notre travail et pour conclure nous allons
d’abord rappeler le contexte de notre étude. La première partie de ce mémoire présente
l’état de l’art sur les protocoles dans les réseaux ordinaires, ad hoc et les réseaux pair à
pair. Les protocoles de routage sont d’une importance capitale du fait qu’ils regroupent
l’ensemble des règles nécessaires à la communication dans les applications réparties ou
les systèmes en réseau. Dans les deux premiers types de réseaux on parle de routage au
niveau physique du réseau et dans le troisième d’un routage logique. Ce dernier utilise
des mécanismes de nommage et d’identification dédiés, ces mécanismes sont spécifiés
dans les protocoles de routage pair à pair.
Dans ce mémoire, nous avons proposé une nouvelle approche de routage dans
un système P2P. L’idée de notre étude est d’appliquer le principe des algorithmes fondés
sur les permissions d’arbitres pour essayer d’améliorer le routage dans les réseaux pair à
pair. Le but est de diminuer le nombre de messages nécessaires pour réaliser les
communications sur le réseau tout en gardant un principe de fonctionnement simple à
mettre en œuvre. Pour router une requête, notre protocole offre la possibilité de limiter le
nombre des pairs contactés aux seuls nœuds "arbitres" et évite ainsi l’inondation. La
manière dont sont construits les ensembles d’arbitres nous assure un parcours exhaustif
57
Conclusion Générale
du réseau. Ainsi si la réponse à une recherche existe alors elle sera trouvée. Toutefois
notre proposition reste à ce stade simpliste. Nous avons modélisé une application
fonctionnant selon les règles du protocole (nous avons commencé par le protocole allégé)
et nous l’avons implanté sous le bus jacorb de corba. Cette application est composée de
sept nœuds communicants. Nous voulions implanter l’application sous jacorb dans
l’objectif de construire un module de routage qu’on pourrait intégrer au bus pour étendre
ses possibilités et permettre le développement d’applications pair à pair.
En perspective, la poursuite du travail pourra porter sur ce qui suit:
Simuler tout le protocole pour confirmer son bon fonctionnement et l’implémenter

sous jacorb ou éventuellement une autre plateforme répartie.
Effectuer des simulations pour déterminer la meilleure valeur pour le délai "d" de
telle sorte à minimiser et éventuellement de réduire la lenteur du trafic du réseau
induit par une trop grande valeur de "d".
Construire un algorithme de désignation ou d’élection des ensembles d’arbitre
dynamiquement ce qui aura comme conséquence logique l’augmentation de la
scalabilité de l’algorithme.
Trouver un moyen de construire les ensembles d’arbitre optimaux quelque soit le
nombre de nœud dans le réseau sans recourir à la méthode des plans projectifs
finis.
58
Bibliographie
[1] J.L Archimbaud, Introduction à TCP/IP, CNRS/UREC, 2005.

www.urec.cnrs.fr/IMG/pdf/93.04.cours.TCP_IP.1.pdf
[2] Eric Fleury. Protocoles de routage RIP, OSPF et BGP. INRIA/INSA Lyon.2005.
http://tc-net2.insa-lyon.fr/lutece/download/LMW_02_ROUTAGE.pdf
[3] Jean Saquet, Réseaux et protocoles, routage, Université de Caen, 2006.

http://users.info.unicaen.fr/~jean/UE9/cours8.pdf
[4] C. E. Perkins and P. Bhagwat, Highly dynamic destination-sequenceddistance-vector

routing (DSDV) for mobile computer, ACM SIGCOMM'94 Conference on
Communications Architectures, Protocols ans Applications, pp. 234- 244, 1994.
http://citeseer.ist.psu.edu/perkins94highly.html
[5] Shree Murthy and J. J. G.L. Aceves, A routing protocol for packet radio networks,
Proceeding of the IEEE Mobicom, pp 86-95, Berkeley, California, United States,
1995.
[6] S. Murthy and J.J. G.L. Aceves, An efficient routing protocol for wireless networks,
ACM Mobile Networks and Application Journal, Special issue on routing in mobile
communication networks, pp 183-97, 1996.
[7] Tsu-Wei Chen and M. Gerla, Global State Routing: A new routing scheme for sd-hoc
wireless networks, Proceeding IEEE ICC'98, 1998.
59
Bibliographie
[8] Iwata, C. C. Chiang, G. Pei, M. Gerla, and T.-W. Chen, Scalable routing strategies
for ad hoc wireless networks, IEEE Journal on Selected Areas in Communications,
Special Issue on Ad-Hoc Networks, pp.1369-79, 1999.
[9] M. Gerla and J. Tsai, Multicluster, mobile, multimedia radio network, ACM-Baltaz
Journal of Wireless Networks, pp 255-265, 1995.
[10] C. C. Chiang, H-K Wu, Winston Liu, and M. Gerla, Routing in clustered multihop,
mobile wireless networks, The IEEE Singapore International Conference on
Networks, pp 197-211, 1997.
[11] M. Joa-Ng and I.-T. Lu, A Peer-to-Peer zone-based two-level link state routing for
mobile ad hoc networks, IEEE Journal on Selected Areas in Communications,
Special Issue on Ad-Hoc Networks, pp 1415-1425, 1999.
[12] S. Basagni, I. Chlamtac, V. R. Syrotiuk, and B. A. Woodward, A distance routing

effect algorithm for mobility (DREAM), In Proceeding of ACM/IEEE
MOBICOM'98, Dallas, Texas, pp 76-84, 1998.
[13] Mingliang Jiang, Jinyang Li, Y.C. Tay, Cluster Based Routing Protocol.
http://www.ietf.org/internetdrafts/draft-ietf-manet-cbrp-spec-01.txt. August 1999.
[14] J. Broch, D. Johnson and D. Maltz, The dynamic source routing protocol for mobile
ad hoc network. http://citeseer.ist.psu.edu/johnson96dynamic.html
[15] J. Broch, D. Johnson and D. Maltz, The dynamic source routing protocol for
mobile ad hoc network, 1998. http://citeseer.ist.psu.edu/johnson96dynamic.html
[16] C. E. Perkins and Elizabeth M. Royer, Ad hoc on demand distance vector (AODV)
algorithm, In Proceeding of the 2nd IEEE Workshop on Mobile Computing
Systems and Applications (WMCSA'99), New Orleans, Louisiana, USA, 1999.
[17] C. E. Perkins and Elizabeth M. Royer and S.R. Das, Ad hoc on demand distance
Vector (AODV) routing, 2000. http://www.ietf.org/internetdrafts /draft-ietf-manet-
aodv-05.txt
[18] V. D. Park and M. S. Corson, A highly adaptive distributed routing algorithm for
mobile wireless networks, Proceeding INFOCOM ’97, pp 1405-1413, 1997.
[19] V. D. Park and M. S. Corson, Temporally-ordered routing algorithme (TORA)

Version 1, functionnal specification,1999. http://www.ietf.org/internetdrafts /draft-
ietf-manet-tora-spec-02.txt.
[20] Chai-Keong Toh, A novel distributed routing protocol to support ad hoc mobile
computing, Proceeding 1996 IEEE 15th Annual Int'l. Phoenix Conf. Comp. and
Commun. pp 480-86, 1996.
60
Bibliographie
[21] K. Toh, Long-lived ad-hoc routing based on the concept of associativity, IETF
Draft, 1999. http://tools.ietf.org/id/draft-ietf-manet-longlived-adhoc-routing-00.txt
[22] R. Dube et al. Signal stability based adaptive routing for ad hoc mobile networks, pp
36-45, 1997, http://pdos.csail.mit.edu/decouto/papers/dube97.pdf.
[23] Y.-B. Ko and N.H. Vaidya, Location-aided routing (LAR) in mobile ad hoc
networks, In Proceedings of ACM/IEEE MOBICOM'98, Dallas, Texas, pp 66-75,
1998.
[24] G. Aggelou and R. Tafazolli, RDMAR: A Bandwidth-Efficient Routing Protocol for

Mobile Ad Hoc Networks, Proceedings of the ACM International Workshop on
Wireless Mobile Multimedia (WoWMoM), Seattle, WA. 1999.
[25] G. Aggelou and R. Tafazolli, Relative distance micro-discovery ad hoc routing

(RDMAR) protocol.1999. http://tools.ietf.org/id/draft-ietf-manet-rdmar-00.txt.
[26] Guillaume Doyen, Supervision des réseaux Pair à Pair, Laboratoire Lorrain de
Recherche en Informatique et ses Applications, Thèse Doctorat, université Nancy1
2005.
[27] Philippe Gauron, Interconnexion et routage efficaces pour des procédures de

recherche décentralisées dans les systèmes pair-à-pair, Thèse Doctorat, université
Paris Sud 2006.
[28] Antony Rowstron and Peter Druschel, Pastry: scalable, distributed object location
and routing for large-scale peer-to-peer systems, In proceedings of the 18th
IFIP/ACM International Conference on Distributed Systems Platforms (Middel-
ware), 2001. http://www.cs.cornell.edu/People/egs/615/pastry.pdf
[29] Dahlia Malkhi, Moni Naor, and David Ratajezak, Viceroy : a scalable and dynamic
lookup network, In proceeding of the 21st ACM symp. On Principles of Distributed
Computing (PODC), pages 183-192, 2002. California, USA.
[30] M. Kahani and H. W. Peter Beadle, Decentralized approaches for network

management, SIGCOMM Computer communication review, Volume 27, Issue 3
New York, NY, USA.
[31] M. Datar, Butterflies and peer-to-peer networks, In R. Möhring and R. Raman,

editors, Proceeding of the 10th Annual European Symposium on algorithms –
ESA’02, number 2461 in LNCS, pages 310-322. 2002, Rome, ITALY.
[32] Elizabeth Daly, Alan Gray et Mads Haahr, On Using Peer Profiles to Create Self-
Organizing P2P Networks, In Proceedings of the First International IEEE
WoWMoM Workshop on Trust, Security and Privacy for Ubiquitous Computing -
Volume 03, Washington, DC, USA. 2005
61
Bibliographie
[33] Mourad Amad, Découverte et localisation de services en mode p2p, Thèse

Magistère, Université A.Mira de Béjaia, 2005.
[34] David Clark, Face-to-Face with Peer-to-Peer Networking, IEEE internet computing,
vol. 34, no. 1, pp. 18-21, 2001.
[35] Michel Raynal, Synchronisation et état global dans les systèmes répartis, Eyrolls,
Paris, 1992.
[36] P.A. Muller et N.Gaertner, Modélisation objet avec UML, Eyrolls, Deuxième
édition. Paris, 2000.
[37] C. Morley, J.Hugues et B. Leblanc, UML 2 pour l’analyse d’un système

d’information, 3eme édition, Dunod , Paris, 2006.
[38] J.M. Geib, C. Gransart et P. Merle, Corba : des concepts à la pratique, deuxième
édition, Dunod , Paris, 1999.
62
Annexe A
Cette annexe contient des éléments complémentaires aux chapitres présentés dans
notre rapport. L’algorithme de Dijkstra et celui de Bellman Ford Distribué sont donnés.
Ces deux algorithmes sont utilisés par plusieurs protocoles de routage dans les réseaux
ordinaires et ad hoc, présentés dans la première partie de ce mémoire. Nous avons repris
les protocoles SFR et Gnutella, dans le détail utile, pour comprendre les mécanismes et
les critères de conception de chacun. Cela nous a permis de mieux appréhender la
fonction de routage.
1 Algorithmes de recherche de chemins

Algorithme de Bellman Ford Distribué
L’algorithme de Bellman Ford Distribué s’itère de la façon suivante :
1. Soit XN = (C1,C2,…..,CN) où : CI le coût de RI à RDES.\ où RI la source et RDES la

destination.
2. Mettre X0 = (∞,∞,…..,∞).
3. A chaque T secondes (période de temps), le routeur I envoi CI à ces voisins.
4. Si le routeur I reçoit un coût moins élevé que celui qu’il garde dans sa table de
routage pour une destination donnée il met à jour cette valeur avec la nouvelle. D’où
XN+1 = ƒ(XN).
63
Annexe Annexe A
5. Tant que XN+1 ≠ (XN) aller à (3).
6. Fin.
Algorithme de Dijkstra
Soits : N l’ensemble des nœuds du réseau (graphe).
L(i,j) le coût du lien entre les nœuds i et j, s’il n y a aucun lien entre i et j alors l(i,l) = ∞.
C(n) le coût d’un certain nœud source s à une destination n.
M un ensemble de nœuds initialement vide.
1. Mettre M = {s}.
2. Pour tout n dans N-{s} : C(n) = L(s,n).
3. Tant que (N≠M) :
M = M U {w} tel que C(w) est le minimum pour tout w dans (N-M).
Pour tout n dans (N-M) : C(n) = MIN (C(n), C(w)+L(w,n)).
2 Les protocoles FSR et Gnutella

Dans cette section nous décrivons le fonctionnement des deux protocoles, leurs
mécanismes ainsi que leurs avantages et inconvénients.
2.1 Le protocole FSR pour le routage dans les réseaux ad hoc
2.1.1 Principe de fonctionnement
Le protocole FSR pour les réseaux ad hoc utilise l’approche à plusieurs niveaux
du réseau pour minimiser le coût des mises à jour et réduire la quantité d’information
échangée entre les nœuds, ie la charge du réseau. Pour ce faire, il utilise la
technique « fisheye » proposée par Kleinrok et Stevens. Cette technique est inspirée de la
nature de l’œil du poisson qui capture avec précision les points proches de son point
focal et plus on s’éloigne plus cette précision diminue. La projection de cette technique
dans le contexte des réseaux ad hoc concerne la précision sur les données de routage
échangées entre les nœuds du réseau et particulièrement entre un nœud et ses voisins.
Ces derniers bénéficieront d’informations plus précises sur la distance et la qualité du
64
Annexe Annexe A
chemin les reliant. Il va de même pour la fréquence de mise à jour des informations des
tables de routage, ainsi les entrées qui correspondent aux nœuds les plus proches sont
envoyées à des fréquences plus élevées.
Cependant, un nœud enregistre l’état de lien vers chaque destination dans le réseau.
La technique du « fisheye »
Cette technique partage le réseau en un ensemble de niveaux. On définit un

niveau suivant le nombre de sauts nécessaires pour atteindre son ensemble de nœuds. Sur
la figure suivante les nœuds en noir constituent le premier niveau, ceux en gris le
deuxième niveau et le reste un troisième niveau. Toutefois, on peut définir plusieurs
rayons (exprimés en termes de sauts) et on obtiendra plusieurs niveaux sur tout le réseau.
Suivant la figure, dès que la longueur du chemin séparant le nœud ‘11’ d’un autre nœud
est inférieure ou égale à deux, on dit que ce dernier est dans l’œil du poisson du nœud
‘11’, l’ensemble de ses nœuds est délimité par les zones noire et grise.
Figure a. Domaines considérés par « FishEye » .
En outre, pour réaliser ses opérations le protocole se sert d’une liste de voisins,
d’une table de topologie et d’une table de routage. Un nœud enregistre l’ensemble de ses
voisins dans sa liste de voisins où il maintient pour chacun son identificateur et une
information sur la dernière fois qu’il a reçu un paquet de sa part.
65
Annexe Annexe A
La table de topologie est maintenue pour chaque destination du réseau et chacune

possède son entrée dans la table, on s’en sert chaque fois pour calculer la table de
routage.
La table de routage fournit l’adresse de la destination, la distance les séparant, et le

prochain nœud intermédiaire. Cette table est calculée en utilisant l’algorithme de Dijkstra
modifié de sorte à calculer en parallèle une table des prochains nœuds « next hop » et une
table des distances. A chaque itération de l’algorithme, un nœud i cherche une nouvelle
destination j qui minimise la valeur « Di (k) +W(k,j) », tel que Di est la distance séparant
le nœud i du nœud k et W(k,j) est la fonction qui cherche le plus court chemin de k vers j,
sachant que le nœud k est présent dans la table de topologie du nœud i.
Le routage des paquets vers la destination s’effectue saut par saut. Le nœud source ou le
nœud intermédiaire retrouve l’adresse de la destination à partir du paquet et consultent
leurs tables pour vérifier si une entrée vers cette destination existe déjà. Si la route est
connue alors le paquet est envoyé au prochain nœud. Cette procédure est répétée jusqu’à
ce que le paquet atteigne sa destination.
2.1.2 Avantages du protocole
La technique implantée par le protocole FSR et ses caractéristiques a permis de

souligner plusieurs avantages à son utilisation.
Principe de fonctionnement simple à appréhender.
Utilisation des routes les plus courtes et les routes sont le plus souvent
récentes.
Le protocole est robuste et gère très bien la mobilité des nœuds. En

effet, chaque nœud considère qu’un lien est corrompu s’il ne reçoit pas
de mise à jour de son voisin au bout d’un temps déterminé et supprime
toutes les informations le concernant dans ses tables. Le protocole ne
nécessite pas d’utiliser des paquets de mise à jour dans ce type de cas.
Il échange des mises à jour plus précises avec ses voisins uniquement.
Il réduit le trafic des mises à jour sur le réseau.
66
Annexe Annexe A
Très adapté au réseaux étendus et scalables grâce à sa capacité de

réduction du trafic.
2.1.3 Inconvénients du protocole
Le reproche qu’on peut faire à ce protocole réside dans le fait qu’il ne propage
pas de paquets contenant des informations précises vers les nœuds distants du réseau,
mais néanmoins plus le paquet s’approche de la destination il transite via des nœuds
possédants l’information précise sur cette destination. Aussi, l’utilisation de plusieurs
tables engendre une consommation importante en terme de ressources de mémoire et de
calcul.
2.2 Le protocole Gnutella pour le routage dans les réseaux pair à pair purs
2.2.1 Principe de fonctionnement

Gnutella est un système pair à pair décentralisé pur. Il est formé par un
ensemble de machines exécutant, chacune, une application implantant le protocole
Gnutella ; elles sont interconnectées en utilisant TCP/IP (6346 est le port par défaut de
l’application). Toutes ces machines s’échangent des messages propres au protocole
Gnutella, notamment des requêtes, des réponses à ces requêtes et d’autres messages de
contrôle. Ce système permet aux nœuds participants de partager leurs différentes
ressources. Dans ce système chaque client est un serveur et inversement, c'est-à-dire
chaque nœud du réseau exécute des tâches clientes et serveurs à la fois. Dans Gnutella,
un nœud est désigné par le mot « servent ».
Le protocole Gnutella définit la manière suivant laquelle communiquent les servents sur
le réseau. Il définit cinq types de messages ou descripteurs pour échanger des
informations entre les servents et un ensemble de règles pour l’échange de ses
descripteurs. Le tableau suivant décrit l’utilité de chaque descripteur.
Descripteur Description
Il sert à découvrir dynamiquement les nœuds du réseau. Un nœud qui

Ping reçoit un ping est censé répondre par un ou plusieurs pongs.
67
Annexe Annexe A
La réponse au ping. Il contient l’adresse du servent et des

Pong informations sur ses données partagées.
Le mécanisme fondamental pour la recherche sur le réseau. Un

servent qui reçoit un Query répondra par un QueryHit s’il trouve des
Query
données correspondantes à la recherche dans son ensemble de
données local.
La réponse à Query. Elle fournit assez d’informations au destinataire

QueryHit pour récupérer les données correspondantes à la Query.
Un mécanisme permettant au servent se trouvant derrière un pare-feu

Push de participer à l’échange sur le réseau.
Le protocole Gnutella ne fournit aucun mécanisme de haut niveau pour permettre

l’accès des nouveaux nœuds au réseau, et ces derniers utilisent pour cela l’inondation.
Une fois le nœud a réussi à accéder au réseau, il communique avec les autres servents
avec les différents descripteurs. Chaque descripteur est précédé par l’entête de
descripteur qui a la forme suivante :
Descripteur Longueur
ID descripteur TTL Hops
payload payload
ID descripteur : c’est une chaîne de caractère sur 16 bits qui identifie de façon
unique le descripteur dans le réseau.
Descripteur payload : ce champ indique le type du descripteur tel que,
0x00 = Ping
0x01 = Pong
0x40 = Push
0x80 = Query
0x81 = QueryHit
68
Annexe Annexe A
TTL : Time To Live, il indique le nombre de fois que le descripteur sera transmis
entre les servents du réseau. Chaque servent décrémente le TTL avant de le
renvoyer jusqu’à ce qu’il s’annule et donc sera détruit.
Hops : le nombre de fois que le descripteur a été transmis entre les servents. Les
champs TTL et Hops de l’entête doivent vérifier, durant la vie du descripteur, la
condition : TTL (0) = TTL(i) + Hops(i) pour i>=0 (au ieme saut).
Longueur payload : il indique la longueur du descripteur qui suit immédiatement

cet entête.
Le mécanisme TTL est le seul moyen de contrôler la propagation des messages dans le
réseau. Ainsi les servents doivent décrémenter ce champ à chaque réception d’un
descripteur, et détruire le descripteur à son expiration, c'est-à-dire une fois son compteur
atteint zéro. Une trop grande valeur de ce champ augmente inutilement la charge du
réseau et dégrade ses performances. La figure suivante illustre l’utilisation de ce
mécanisme. Dans ce scénario le champ TTL est mis à 3, il est décrémenté à chaque saut
et sera détruit au bout du troisième saut.
Figure b. Utilisation du mécanisme TTL
69
Annexe Annexe A
Routage des messages
Le protocole Gnutella définit un ensemble de règles pour le routage des

descripteurs qu’on vient de présenter. La nature décentralisée du protocole oblige les
servents à router convenablement leurs messages. Un servent fonctionnant correctement
va appliquer les règles suivantes pour transmettre ses messages.
1) Un descripteur pong peut être renvoyé seulement suivant le même chemin qu’a
parcouru le ping correspondant. Cela assure qu’il n’y a que les servents qui ont
routé le ping qui vont voir le pong en réponse. Un servent qui reçoit un pong avec
un identificateur n doit le supprimer s’il n’a pas reçu au préalable le ping de
même identificateur.
2) La règle précédente s’applique de la même façon aux descripteurs : Query et

QueryHit.
3) La même règle est appliquée concernant la paire Push et QueryHit, sauf que dans
ce cas on considère le champ Servent Identifier et non pas le descripteur ID.
4) Un servent transmet tous les Query et les Ping qu’il reçoit à tous ses voisins
directs sauf à celui qui les a envoyés. La figure suivante explicite
5) Un servent décrémente le champ TTL et incrémente le champ Hops de chaque

descripteur avant de le transmettre à ses voisins. Une fois le TTL a atteint zéro le
descripteur n’est plus transmis.
6) Un servent qui reçoit un descripteur payload ou un ID descripteur similaire à un

autre descripteur déjà reçu ne va pas le retransmettre une autre fois.
70
Annexe Annexe A
2.2.2 Avantages du protocole

La nature décentralisée de ce protocole lui confère plusieurs avantages.
o Une administration simple et mutualisée assurée par chaque servent
o Une topologie évolutive du réseau. Théoriquement, sa taille est illimitée.
o Une très bonne disponibilité du réseau car il est presque impossible de causer des
disfonctionnement par déni de service.
o Il est très adapté à la mobilité des nœuds du réseau.
2.2.3 Inconvénients du protocole

Malgré sa simplicité ce protocole présente des inconvénients très importants et
pèse lourdement sur son fonctionnement.
o Le recours à l’inondation comme mécanisme d’échange engendre un trafic

important sur le réseau.
o Il consomme trop de bande passante à cause des broadcasts générés pour chaque
envoi.
o Il n’est pas exhaustif c'est-à-dire qu’il ne garantit pas de succès.
Bibliographie
- Mario GERLA, Xiaoyan HONG and Guangyu PEI, Fisheye State Routing Protocol
(FSR) for Ad Hoc Networks, <draft-ietf-manet-fsr-03.txt>, Rockwell Scientific Company
June 17, 2002.
- http://www.clip2.com. The Gnutella Protocol Specification v0.41, Document Revision

1.2 Clip2
71
Annexe B
Cette annexe est dédiée à la présentation de l’environnement corba et ses

fonctionnalités. Nous commencerons par la description du bus corba, son architecture et
ses caractéristiques ainsi que ses composantes et services. Les types de bus existants. En
deuxième lieu, nous expliquerons la procédure de configuration et d’utilisation du bus
jacorb dont on s’est servi pour implanter notre application.
1 PRESENTATION DE CORBA
1.1 Présentation de l’OMG
L’Object Management Group (OMG) est un consortium international créé en

1989 et regroupant actuellement plus de 850 acteurs du monde informatique : des
constructeurs (IBM, Sun), des producteurs de logiciel (Netscape, Inprise ou ex-
Borland/Visigenic, IONA Tech.), des utilisateurs (Boeing, Alcatel) et des institutions et
universités (NASA, INRIA, LIFL). L’objectif de ce groupe est de faire émerger des
standards pour l’intégration d’applications distribuées hétérogènes à partir des
technologies orientées objet. Ainsi les concepts-clés mis en avant sont la réutilisabilité,
l’interopérabilité et la portabilité de composants logiciels. L’élément-clé de la vision de
l’OMG est CORBA (Common Object Request Broker Architecture) : un « middleware »
orienté objet.
Le concept d’objets répartis offre un support d’exécution masquant les couches
techniques d’un système réparti (système d’exploitation, processeur et réseau) et il prend
72
Annexe Annexe B
en charge les communications entre les composants logiciels formant les applications
réparties hétérogènes.
1.2 Présentation du bus CORBA
Le bus CORBA propose un modèle orienté objet client/serveur d’abstraction et de

coopération entre les applications réparties. Chaque application peut exporter certaines
de ses fonctionnalités (services) sous la forme d’objets CORBA : c’est la composante
d’abstraction (structuration) de ce modèle. Les interactions entre les applications sont
alors matérialisées par des invocations à distance des méthodes des objets : c’est la partie
coopération. La notion client/serveur intervient uniquement lors de l’utilisation d’un
objet : l’application implantant l’objet est le serveur, l’application utilisant l’objet est le
client. Bien entendu, une application peut tout à fait être à la fois cliente et serveur.
Client Object Implementation
Static Dynamic
IDL Skeleton
Dynamic IDL Stubs ORB Skeleton
Invocation Interface
ORB Core
Figure a. Structure des interfaces d’un bus Corba.
1.2.1 Les notions utilisées par le bus
L’application cliente est un programme qui invoque les méthodes des objets à
travers le bus CORBA.
La référence d’objet est une structure désignant l’objet CORBA et contenant
l’information nécessaire pour le localiser sur le bus.
73
Annexe Annexe B
L’interface de l’objet est le type abstrait de l’objet CORBA définissant ses

opérations et attributs. Celle-ci se définit par l’intermédiaire du langage OMG-
IDL.
La requête est le mécanisme d’invocation d’une opération ou d’accès à un attribut
de l’objet.
Le bus CORBA achemine les requêtes de l’application cliente vers l’objet en
masquant tous les problèmes d’hétérogénéité (langages, systèmes d’exploitation,
matériels, réseaux).
L’objet CORBA est le composant logiciel cible. C’est une entité virtuelle gérée
par le bus CORBA.
L’activation est le processus d’association d’un objet d’implantation à un objet
CORBA.
L’implantation de l’objet est l’entité codant l’objet CORBA à un instant donné et
gérant un état de l’objet temporaire. Au cours du temps, un même objet CORBA
peut se voir associer des implantations différentes.
Le code d’implantation regroupe les traitements associés à l’implantation des
opérations de l’objet CORBA. Cela peut être par exemple une classe Java aussi
bien qu’un ensemble de fonctions C.
L’application serveur est la structure d’accueil des objets d’implantation et des
exécutions des opérations. Cela peut être par exemple un processus Unix.
1.2.2 Les caractéristiques du bus
La liaison avec plusieurs langages de programmation : actuellement l’OMG a

défini officiellement cette liaison seulement pour les langages C, C++, SmallTalk,
Ada, COBOL et Java.
La transparence des invocations : les requêtes aux objets semblent toujours être
locales, le bus CORBA se chargeant de les acheminer en utilisant le canal de
communication le plus approprié.
L’invocation statique et dynamique : ces deux mécanismes complémentaires
permettent de soumettre les requêtes aux objets. En statique, les invocations sont
contrôlées à la compilation. En dynamique, les invocations doivent être
contrôlées à l’exécution.
74
Annexe Annexe B
Un système auto-descriptif : les interfaces des objets sont connues du bus et sont
aussi accessibles par les programmes par l’intermédiaire du référentiel des
interfaces.
L’activation automatique et transparente des objets : les objets sont en mémoire
uniquement s’ils sont utilisés par des applications clientes.
L’interopérabilité entre bus : à partir de la norme CORBA 2.0, un protocole
générique de transport des requêtes (GIOP pour General Inter-ORB Protocol) a
été défini permettant l’interconnexion de bus CORBA provenant de fournisseurs
distincts, une de ses instanciations est l’Internet Inter-ORB Protocol (IIOP)
fonctionnant au dessus de TCP/IP.
1.2.3 L’architecture du bus
 ORB (Object Request Broker) est le noyau de transport des requêtes aux objets. Il
intègre au minimum les protocoles GIOP et IIOP. L’interface au bus fournit les
primitives de base comme l’initialisation de l’ORB.
 SII (Static Invocation Interface) est l’interface d’invocations statiques permettant
de soumettre des requêtes contrôlées à la compilation des programmes. Cette
interface est générée à partir de définitions OMG-IDL.
 DII (Dynamic Invocation Interface) est l’interface d’invocations dynamiques
permettant de construire dynamiquement des requêtes vers n’importe quel objet
CORBA sans générer et ou utiliser une interface SII.
 IFR (Interface Repository) est le référentiel des interfaces contenant une
représentation des interfaces OMGIDL.
75
Annexe Annexe B
 SSI (Skeleton Static Interface) est l’interface de squelettes statiques qui permet à
l’implantation des objets de recevoir les requêtes leur étant destinées. Cette
interface est générée comme l’interface SII.
 DSI (Dynamic Skeleton Interface) est l’interface de squelettes dynamiques qui
permet d’intercepter dynamiquement toute requête sans générer une interface SSI.
C’est le pendant de DII pour un serveur.
 OA (Object Adapter) est l’adaptateur d’objets qui s’occupe de créer les objets
CORBA, de maintenir les associations entre objets CORBA et implantations et de
réaliser l’activation automatique si nécessaire.
 ImplR (Implementation Repository) est le référentiel des implantations qui
contient l’information nécessaire à l’activation. Ce référentiel est spécifique à
chaque produit CORBA.
1.2.4 Les services du bus
Les services objet communs ont pour objectif de standardiser les interfaces des
fonctions système indispensables à la construction et l’exécution de la plupart des
applications réparties. Cette section décrit sommairement ces services selon leur rôle
dans une application répartie. Elle se base sur l’actuelle spécification CORBA services et
les travaux en cours à l’OMG.
 La recherche d’objets
Cette catégorie de services offre les mécanismes pour rechercher/retrouver
dynamiquement sur le bus les objets nécessaires aux applications. Ce sont les
équivalents des annuaires téléphoniques.
Le service Nommage (Naming Service) est l’équivalent des « pages blanches »
: les objets sont désignés par des noms symboliques. Cet annuaire est
matérialisé par un graphe de répertoires de désignation.
Le service Vendeur (Trader Service) est l’équivalent des « pages jaunes » : les
objets peuvent être recherchés en fonction de leurs caractéristiques.
 La vie des objets

Cette catégorie regroupe les services prenant en charge les différentes étapes de la
vie des objets CORBA.
76
Annexe Annexe B
Le service Cycle de Vie (Life Cycle Service) décrit des interfaces pour la
création, la copie, le déplacement et la destruction des objets sur le bus. Il
définit pour cela la notion de fabriques d’objets («Object Factory»).
Le service Propriétés (Property Service) permet aux utilisateurs d’associer
dynamiquement des valeurs nommées à des objets. Ces propriétés ne modifient
pas l’interface IDL, mais représentent des besoins spécifiques du client.
Le service Relations (Relationship Service) sert à gérer des associations
dynamiques (appartenance, inclusion, référence, auteur, emploi,...) reliant des
objets sur le bus. Il permet aussi de manipuler des graphes d’objets.
Le service Externalisation (Externalization Service) apporte un mécanisme
standard pour fixer ou extraire des objets du bus. La migration, le passage par
valeur, et la sauvegarde des objets doivent reposer sur ce service.
Le service Persistance (Persistent Object Service) offre des interfaces
communes à un mécanisme permettant de stocker des objets sur un support
persistant. Quel que soit le support utilisé, ce service s’utilise de la même
manière via un «Persistent Object Manager». Un objet persistant doit hériter de
l’interface «Persistent Object» et d’un mécanisme d’externalisation.
Le service Interrogations (Query Service) permet d’interroger les attributs des
objets. Il repose sur les langages standards d’interrogation comme SQL3 ou
OQL. L’interface Query permet de manipuler les requêtes comme des objets
CORBA. Les objets résultats sont mis dans une collection. Le service peut
fédérer des espaces d’objets hétérogènes.
Le service Collections (Collection Service) permet de manipuler d’une
manière uniforme des objets sous la forme de collections et d’itérateurs. Les
structures de données classiques (listes, piles, tas,..) sont construites par sous-
classement. Ce service est aussi conçu pour être utilisé avec le service
d’interrogations pour stocker les résultats de requêtes.
Le service Changements (Versionning Service) permet de gérer et de suivre
l’évolution des différentes versions des objets. Ce service maintient des
informations sur les évolutions des interfaces et des implantations. Cependant,
il n’est pas encore spécifié officiellement.
 La sûreté de fonctionnement
77
Annexe Annexe B
Cette catégorie de services fournit les fonctions système assurant la sûreté de

fonctionnement nécessaire à des applications réparties.
Le service Sécurité (Security Service) permet d’identifier et d’authentifier les
clients, de chiffrer et de certifier les communications et de contrôler les
autorisations d’accès. Ce service utilise les notions de serveurs
d’authentification, de clients/rôles/droits (et délégation de droits), d’IIOP
sécurisé (utilisant Kerberos ou SSL).
Le service Transactions (Object Transaction Service) assure l’exécution de
traitements transactionnels impliquant des objets distribués et des bases de
données en fournissant les propriétés ACID.
Le service Concurrence (Concurrency Service) fournit les mécanismes pour
contrôler et ordonnancer les invocations concurrentes sur les objets. Le
mécanisme proposé est le verrou. Ce service est conçu pour être utilisé
conjointement avec le service Transactions.
 Les communications asynchrones

Par défaut, la coopération des objets CORBA est réalisée selon un mode de
communication client/serveur synchrone. Toutefois, il existe un ensemble de
services assurant des communications asynchrones.
Le service Evénements (Event Service) permet aux objets de produire des
événements asynchrones à destination d’objets consommateurs à travers des
canaux d’événements. Les canaux fournissent deux modes de fonctionnement.
Dans le mode « push », le producteur a l’initiative de la production, le
consommateur est notifié des événements. Dans le mode « pull », le
consommateur demande explicitement les événements, le producteur est alors
sollicité.
Le service Notification (Notification Service) est une extension du service
précédent. Les consommateurs sont uniquement notifiés des événements les
intéressant. Pour cela, ils posent des filtres sur le canal réduisant ainsi le trafic
réseau engendré par la propagation des événements inintéressants.
Le service Messagerie (CORBA Messaging [OMG-CM]) définit un nouveau
modèle de communication asynchrone permettant de gérer des requêtes
persistantes lorsque l’objet appelant et l’objet appelé ne sont pas présents
78
Annexe Annexe B
simultanément sur le bus. Cela permet d’avoir des fonctionnalités proches des
MOMs (Message Oriented Middleware).
1.3 Les types d’ORB-CORBA
Il existe plusieurs types de bus CORBA, nous citerons seulement quelques uns
qui sont les plus commercialisés.
ORBacus : bus CORBA implémenté en C++ et en Java sur les deux systèmes
Windows et Unix. Il est conçu par OOC (Object Oriented Concepts), il a
l’avantage d’être rapide et léger.
VisiBroker : bus CORBA utilisable en C++, en Java et en Delphi sur les deux
systèmes Windows et Unix. Il est conçu par Inprise. Il a l’avantage d’être facile a
utiliser et performant.
Orbix : bus CORBA implémenté en C++ et en Java sur les deux systèmes
Windows et Unix. Il est conçu par Iona.
Mico : bus CORBA implémenté en C++ sur les deux systèmes Windows et Unix.
Il est conçu par Gnu.
Java ORB : bus CORBA implémenté en Java sur les deux systèmes Windows et
Unix. Il est conçu par Sun. Il a l’avantage d’être Complet.
JacORB : bus CORBA implémenté en Java sur les deux systèmes Windows et
Unix et compatible avec le JDK1.1. Il est conçu par Gnu.
2 INSTALLATION ET CONFIGURATION DE JACORB

Dans cette deuxième annexe, nous allons expliquer la procédure à suivre pour
configurer l’environnement de développement que nous avons utilisé. Pour pouvoir
compiler et exécuter les programmes, il est de première importance de bien positionner
les valeurs de variables d’environnement nécessaires pour le fonctionnement du bus
coraba utilisé. Nous allons décrire dans ce qui suit les outils à utiliser et leur rôle dans
l’environnement.
2.1 Installation de l’environnement
Les outils nécessaires pour la configuration de l’environnement de

développement :
 JDK, version 1.3 ou suivantes.
79
Annexe Annexe B
 L’outil de compilation « Ant », version 1.5 ou suivantes disponible sur le site :

http://jakarta.apache.org/ant.
 Le bus JacORB. Nous avons utilisé la version 2.2.3.
JacORB est un bus CORBA écrit dans le langage de programmation Java. C’est un bus
‘open source’, il est distribué sous deux versions : une version source et une version
binaire. Il suffit d’installer la version binaire pour pouvoir l’utiliser. En revanche il est
nécessaire de compiler d’abord la version source pour en faire usage. Pour compiler cette
version source, on utilise l’outil de compilation « Ant » écrit lui aussi en Java.
L’outil « Ant » génère les classes exécutables utilisées par le bus, à partir des classes
sources. Les étapes de la compilation du bus:
1. Installer l’outil « Ant » : il suffit de le décompresser dans un répertoire
destination sur le disque dur.
2. Décompresser le bus JacORB dans un autre répertoire cible. Pour simplifier les
explications qui vont suivre, on va supposer que le bus est installé dans le
répertoire : C:/JacORB-2.2.3.
3. Lancer l’invite de commande et aller dans le répertoire qui contient le bus
JacORB.
4. Exécuter la commande "ant" : il suffit de taper ant sans arguments. Cette
commande va compiler le bus et générer les fichiers binaires de ses classes, cette
opération prend quelques minutes pour terminer. Si la compilation s’est
parfaitement déroulé le message "Build successful" s’affichera à sa terminaison.
A la fin de son exécution, l’opération de compilation supprime les fichiers sources
utilisés. Il ne reste plus qu’à faire quelques changements dans certains fichiers du bus et
configurer les variables d’environnement pour pouvoir l’utiliser. La section suivante
explique ce qu’il faut faire.
2.2 Configuration des variables d’environnement
Pour que le bus puisse fonctionner correctement sans générer d’erreurs il faut
apporter dans certains fichiers les changements suivants. Ces fichiers sont des fichiers de
propriétés utilisés par le bus pour gérer parmi d’autres les références aux objets
manipulés.
Aller dans le répertoire d’installation de JacORB, dans le répertoire
" C:\JacORB-2.2.3/etc" apporter les modifications suivantes :
Renommer le fichier "jacorb_properties.template" par "jacorb.properties".
80
Annexe Annexe B
A l’intérieur du fichier "jacorb.properties", il faut faire la modification suivante :

ORBInitRef.NameService = file:/ C:/JacORB-2.2.3/NS_Ref
Ouvrir le fichier "orb.properties" et apporter les modifications suivantes :
jacorb.config.dir = C:/JacORB
ORBInitRef.NameService = file:/ C:/JacORB-2.2.3/NS_Ref
Copier le fichier "orb.properties" dans le répertoire utilisateur (User home
directory ) et aussi dans le répertoire "lib" du JDK.
Les variables d’environnement doivent être préalablement positionnées avant de
procéder à l’utilisation du bus. Elles doivent être correctement positionnées, sans quoi le
bus générera des erreurs à la compilation même si le programme compilé ne comporte
aucune erreur.
Aller dans les propriétés système et dans la fenêtre des variables d’environnements, créer
et initialiser les variables comme indiqué dans le tableau qui va suivre. Toutefois, il n’est
pas nécessaire d’utiliser les mêmes versions des outils que celles données dans le tableau.
Nom de la variable Valeur de la variable

JAVA_HOME Répertoire d’installation de la JDK.
JACORB_HOME Répertoire d’installation du bus JacORB (C:\JacORB-2.2.3).
ANT_HOME Répertoire d’installation de l’outil de compilation « Ant ».
Path C:\apache-ant-1.7.0\bin;C:\JacORB-2.2.3\bin;C:\Program
Files\Java\jdk1.5.0_05\bin
Classpath C:\JacORB-2.2.3\classes;C:\apache-ant-1.7.0\lib;C:\Program
Files\Java\jdk1.5.0_05\lib\tools.jar;C:\corba\java\classes;C:\JacO
RB-2.2.3\lib\logkit-1.2.jar
La variable d’environnement "path" est utilisée pour stocker les chemins vers les
répertoires « bin » des logiciels et outils utilisés. Dans l’environnement Java, la variable
"classpath" stocke les chemins vers les dossiers contenant des fichiers ".class" ou ".jar".
Bibliographie
Common Object Request Broker Architecture - for embedded, May 2006 Draft
Adopted Specification ptc/06-05-01.CORBA, OMG.
J.M. GEIB, C. GRANSART et P. MERLE, Corba : des concepts à la
pratique, deuxième édition, Dunod 1999.
JacORB 2.2.3 Programming Guide, The JacORB Team, December 10, 2005.
81

Memoire Routage

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

Memoire Routage

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

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

Université Abderrahman Mira de Béjaia

Mémoire de fin d’études

Routage dans les réseaux pair à pair

Devant le jury composé de :

Président Mr. H. Moumen Maître assistant, U.Béjaia.

Promoteur Mlle. M. Yaici Maître assistant, U.Béjaia.

Co –promoteur Mme. S. Boutrid Maître assistant, U.Béjaia.

Examinateur 1 Mlle. S. Yessaad Maître assistant, U.Béjaia.

Examinateur 2 Mlle. Boulefkhar Maître assistant, U.Béjaia.

Nous tenons à exprimer nos remerciements et notre gratitude à notre enseignante

Pour nos parents d’avoir su être à l’écoute et à la disposition de leurs enfants,

Mots clés : P2P, Protocoles de routage, Algorithmes à quorums, Corba.

Keywords : P2P, Routing protocols, Quorum algorithms, Corba.

Remerciements ............................................................................................................... III

Table des matières ............................................................................................................V

Table des figures ............................................................................................................. IX

Table des algorithmes ..................................................................................................... XI

Liste des abréviations ................................................................................................... XII

Introduction Générale ....................................................................................................... 1

1 Routage dans les réseaux ordinaires ............................................................................ 4

1.1.3 Le vecteur distance .................................................................................. 5

2 Routage dans les réseaux ad hoc ................................................................................ 10

3 Routage dans les réseaux pair à pair .......................................................................... 17

3.1 Définition des systèmes pair à pair ................................................................... 17

3.2 Caractéristiques des systèmes pair à pair ......................................................... 17

5.1 Introduction ........................................................................................................ 28

5.2.3 Construction d’ensembles Ri presque optimaux .......................................... 32

Conclusion Générale .................................................................................................. 57

3.1. Classification des systèmes pair à pair .................................................................... 20

6.12. Le servent initiateur de la recherche ...................................................................... 54

Algorithme 5.1. Algorithme du protocole ..................................................................... 37

Algorithme 5.2. Algorithme du protocole allégé ........................................................... 40

ARP = Address Resolution Protocol.

DHT = Distributed Hash Table.

ICMP = Internet Control Message Protocol.

LSP =Link State Packet.

PFA = Path Finding Algorithm.

SRP = Static Routing Protocol.

a simplicité d’utilisation et la maitrise acquise du modèle Client / Server

Cependant pour réaliser les échanges et les communications entre les

On essayera tout le long de cette partie de présenter d’une façon brève le

Routage dans les Réseaux ordinaires

Le routage consiste en la fonction d’aiguillage, qui permet aux messages

1.1.2 Table de routage

1.1.3 Le vecteur distance [1,3]

L’information de routage est constituée de l’adresse du prochain nœud et du coût

Si l’entrée n’existe pas dans sa table, il la rajoute.

Si non, il n y a pas de changement.

1.1.4 Etat de liens [1,3]

Algorithme de mise à jour des tables de routage: un routeur envoie un message

Si l’entrée est présente, on compare le numéro de séquence du paquet reçu

1.1.5 Système Autonome ou Autonomous System (AS) [2]

1.2 Routage direct

Ce type de routage se produit lorsque les deux machines, émettrice et

1.3 Routage indirect

Ce type de routage, contrairement au précédant se produit lorsque la machine

1.3.1 Routage statique

L’ajout de nouvelles routes ou la mise à jour des tables de routage se fait

1.3.2 Routage dynamique

Dans ce type de routage, la modification des tables de routage se fait de façon

1.3.2.1 Routage dynamique interne (intra domaine)

de routage le protocole calcule le coût de chaque route puis sélectionne les