gnutella web cache

UNIVERSITE LIBANAISE
UNIVERSITE SAINT-JOSEPH
(Faculté de Génie)
(Faculté d'Ingénierie)
Sous l'égide de l'Agence Universitaire de la Francophonie
AUF
Diplôme d'Etudes Approfondies
Réseaux de télécommunications
Proposition d’architecture de réseau actif pour le
déploiement d’un réseau Peer to Peer
Par
Maher Souheil Nasreddine
Encadré par : Mme. Rima Kilany
Soutenance, le 22 décembre 2004 devant le jury composé de
MM.
Samir Tohmé
Mohamad Zoaeter
Wajdi Najem
Imad Mougharbel
Nicolas Rouhana
Mahmoud Doughan
Maroun Chamoun
Président
Membre
Membre
Membre
Membre
Membre
Membre
Mes remerciements !
Au président du jury M. Samir Tohme et à tous les autres membres du jury.
Aux responsables de l’agence universitaire de la francophonie pour l’année
universitaire 2003-2004 pour leurs supports et aides, représentés par M. Nicolas
Rouhana (USJ) et M. Imad Mougharbel (UL).
A mon assistante de projet Mme Rima Kilany, dont j’apprécie son aide et ses
conseils indispensables pour la bonne réalisation de ce projet.
A tous ceux qui m’ont fourni l’aide et accordé leur temps et leur attention pour
orienter mon travail.
Veuillez agréer l’expression de mes sentiments, les meilleurs
Maher
2
Table des matières
Sujet ………………………………………………………………………………
6
Sommaire …………………………………………………………………………
7
1 Les réseaux P2P ……………………………………………………………...
1.1 Introduction……………………………………………………………
1.2 Etat de l’art …………………………………………………………..
1.2.1 Généralités………………………………………………………
1.3 Applications P2P……………………………………………………...
1.3.1 Napster ou le modèle hybride …………………………………..
1.3.2 Gnutella ou le modèle pur……………………………………….
1.3.3 Skype (VOIP) ………………………………………………….
1.4 La gestion du réseaux peer to peer …………………………………...
1.4.1 Gestion des performances ………………………………………
1.4.2 Contrôle du trafic peer to peer ………………………………….
1.4.3 La gestion des fichiers et contenus……………………………...
1.4.4 Gestion de présence JIM ………………………………………
1.4.4.1 Jxta Instant Messaging……………………………………
a Les états en JIM ……………………………………….
a-1 JIM et JXTA …………………………………….
a-2 Instrumentation …………………………………...
1.4.4.2 RRS….……………………………………………………
a- Le Service de Rendez-vous a distance (RRS)……….....
b- Garder un Non Rendez-vous Pair bien Connecté…….
c- L'administration à distance de Rendez-vous Pairs…….
8
9
9
9
12
13
14
16
18
18
19
19
19
19
20
20
21
21
21
21
22
2 Les Réseaux Actifs …………………………………………………….............
2.1 Introduction …………………………………………………………..
2.2 Etat de l’art..........................................................................................
2.2.1 Définitions et généralités............................................................
2.2.2 Applications................................................................................
2.2.2.1 Network Management........................................................
2.2.2.2 Contrôle de gestion............................................................
2.2.2.3 Multicasting.......................................................................
2.2.3 Sécurité des réseaux actifs...........................................................
2.2.3.1 Du point de vue système...................................................
2.2.3.2 Du point de vue langage de programmation.....................
2.2.4 Architecture des réseaux actifs..................................................
2.2.4.1 Approches « Actives Paquets » .......................................
2.2.4.2 Approche « Active Nodes » ..............................................
2.2.4.3 Approche mixte « Active Packets and Nodes »…………...
2.2.5 Comparaison...............................................................................
2.2.6 Réseaux actifs et Ants...................................................................
2.2.6.1 NodeOS des réseaux actifs..................................................
1. Architecture du NodeOS .............................................
2.2.6.2 Protocole ANEP..................................................................
2.2.6.3 ANTS "Active Network Transfer System"……………….
2.3 Gestion des Réseaux Actifs...................................................................
2.3.1 MIB basée XML : Architecture de gestion de réseau actif.... ....
2.3.1.1 Introduction........................................................................
2.3.1.2 Translation MIB à XML......................................................
24
24
25
25
26
26
27
27
28
28
29
29
29
30
31
31
31
32
32
34
34
35
35
35
35
3
2.3.1.3 La méthode de transmission de la MIB basée sur XML en
utilisant ANEP..................................................................
2.3.1.4 Le MIB 'manager' dans un Noeud Actif..............................
2.3.2 AVNMP: Active Virtual Network Management Prédiction....
2.3.3 Application Level Active Network...........................................
2.3.3.1 Introduction.......................................................................
2.3.3.2 Motivation.........................................................................
2.3.3.3 Les Buts.............................................................................
2.3.3.4 ALAN (Fry et Al)..............................................................
3 Proposition d’architecture de réseau actif pour le déploiement et la gestion
d’un réseau Peer to Peer………………………………………………………...
3.1 Introduction…………………………………………………………....
3.2 Super Peer……………………………………………………………..
3.2.1 Les Réseaux Superpeers.…………………………………….…..
3.2.2 Rendez-vous superpeer (RDV)……………………………….....
3.3 ALAN (Architecture)………………………………………….............
3.4 VAP Virtual Active Peer………………………………………………
3.4.1 Introduction………………………………………………………
3.4.2 Architecture de AVP (Super Peer)……………………………….
3.4.3 Gestion de AVP………………………………………………….
3.4.3.1 Le contrôle d’accès…………………………………………
3.4.3.2 Routage…………………………………………………….
3.4.3.3 Topologie Contrôle …………………………………………
3.4.3.4 Gestion des ressources ……………………………………...
3.4.4 Contribution……………………………………………………….
37
37
38
40
40
40
40
41
44
44
44
45
46
47
48
48
50
51
51
51
51
52
52
4 L’implémentation………………………………………………………………. 54
4.1 Création d’un service Web…………………………………………….... 54
4.1.1 Environnement……………………………..……………………… 54
4.1.2 Langage de programmation……………………………………….. 54
4.1.3 Les Fonctions Web………………………………………………… 54
4.1.4 Page d’aide du service Web……………………………………... 54
4.2 Fonctionnement globale du réseau p2p centralisé…………………….. 55
4.2.1 Enregistrement d’un fichier sur le serveur………………………. 55
4.2.2 Page d’aide du service Web……………………………………... 56
4.2.3 Recherche d’un fichier…………………………………………... 57
4.2.4 Télécharger un fichier…………………………………………… 57
4.3 Développement de l’application………………………………………. 57
4.3.1 Création de référence Web……………………………………… 57
4.3.2 Déroulement de l’application…………………………………… 57
57
4.3.2.1 L’enregistrement de fichier………………………………
4.3.2.2 Recherche et téléchargement……………………………... 58
4.4 Monitoring ……………………………………………………………. 59
4.4.1 Qu’est ce que WMI……………………………………………… 59
4.4.2 Architecture WMI ………………………………………………. 60
4.4.2.1 Ressources gerees ………………………………………... 60
4.4.2.2 Infrastructure de WMI …………………………………… 60
4.4.2.3 Consommateurs WMI ……………………………………. 60
61
4.4.3 L’application de gestion ……………………………………….
5 Conclusion …………..…………………………………………………………
Bibliographie ……………………………………………………………………..
4
62
63
Table des Figures
Figure 1. Classification des systèmes informatiques.
Figure 2. Exemple de Topologie virtuelle.
Figure 3. Les Modèles p2p
Figure 4. P2P vs Client/Serveur
Figure 5. La taxonomie des applications p2p
Figure 6. Les échanges dans Napster
Figure 7. En-tête message Gnutella
Figure 8. Connexion d’un Peer Gnutella
Figure 9. Routage des messages
Figure 10. Mécanisme de TTL
Figure 11. Recherche de données (Query-Query Hit)
Figure 12. Skype : Messagerie Instantanée
Figure 13. Architecture de JIM / Jxta
Figure 14. Les peers et les pipes
Figure 15. Le format de paquet d’ANEP
Figure 16. XML basée MIB
Figure 17. Prédiction de charge
Figure 18. Architecture ALAN
Figure 19. Illustration d’un réseau Superpeer
Figure 20. Paramètres de configuration et valeurs par défaut
Figure 21. Rendez-vous Superpeer
Figure 22. ALAN
Figure 23. Exemple de topologie à Virtual Peer Actif.
Figure 24. Pile protocolaire
Figure 25. Architecture AVP 1
Figure 26. Déploiement de AVP
Figure 27. Architecture AVP 2
Figure 28. Gnutella vs réseau AVP
Figure 29. Contrôle de Topologie
Figure 30. Gestion de ressources
Figure 31. Test 1
Figure 32. Test 2
Figure 33. Test 3
Figure 34. Test 4
Figure 35. Test 5
5
9
10
11
12
12
13
15
15
15
16
16
17
20
21
37
38
39
41
45
46
46
47
48
50
50
50
51
51
52
52
55
55
56
58
61
Sujet.
Le développement d’Internet en raison de son succès auprès du grand public est à
l’origine de l’apparition de nouvelles applications de réseau. Particulièrement spectaculaire
est l’émergence des systèmes de partage de fichiers en réseau paritaire (Peer-to-Peer) qui
génèrent à ce jour 40% du volume des données échangées.
L’objectif de se projet consiste à étudier les réseaux peer-to-peer, le fonctionnement
des différentes approches et surtout les limites concernant leur déploiement à grande échelle.
Nous étudierons en particulier le déploiement d’une architecture de découverte et de
monitoring de ressources vu que c’est un exemple qui montre bien l’utilité des architectures
peer-to-peer. Ceci a été prouvé par le succès d’applications basées sur Gnutella ou Freenet.
D’une part, le paradigme P2P s’accorde bien avec notre proposition. Les peers
distribués vont coopérer en vue :
-De générer des alarmes précises
-De réduire la consommation de ressources puisque les modules peuvent partager de
l’information.
-D’éliminer le besoin d’un module d’analyse centralise et complexe.
D’autre part, les avantages des réseaux actifs étant bien identifiés vu qu’ils
fournissent un déploiement rapide de services, une distribution de charge sur le réseau, une
connectivite entre les équipements et une personnalisation de réseau suivant les applications
utilisées, il faudra proposer une architecture basée sur les réseaux actifs pouvant répondre a
tous les besoins de déploiement de réseaux et d’applications peer-to-peer.
6
Sommaire.
Le terme Peer-to-Peer (P2P) désigne une classe d’applications distribuées qui repose
sur un modèle décentralisé. Contrairement au modèle client/serveur où chaque élément ne
peut être que client ou serveur d’un service, les éléments participants à une application P2P
peuvent être potentiellement client et serveur à la fois.
De plus en plus d’application sont construites sur ce modèle qui présente de nombreux
avantages parmi lesquels on compte un très bon passage à l'échelle, le partage des coûts de
mise en œuvre et maintenance, et l’utilisation du fort potentiel de machines inexploitées
situées en bordure de l’Internet.
En effet, le modèle P2P est mis en œuvre dans de nombreux domaines d’application
couvrant notamment le calcul distribué comme Global GRID Project, la collaboration
comme Groove et le partage de fichiers comme Gnutella.
Les administrateurs ont constamment besoin d’avoir une vision claire de
l’infrastructure entière de leur réseau d’ordinateurs. Plus on ajoute de stations de travail et de
serveurs au réseau, plus obtenir et manipuler des données concrètes devient difficile.
Depuis quelques années, la programmation des réseaux commence à apparaître dans les
équipements. Les routeurs, les switchs et autres éléments des réseaux IP commencent a
acquérir une certaine intelligence qui permet de faciliter la manipulation des réseaux, et
l’introduction rapide de nouveaux services. L’exemple du réseau intelligent donne un avantgoût de ce que pourrait apporter l’introduction des réseaux actifs. Ils fournissent un
déploiement de services rapides, et une distribution de charge sur le réseau. D’une part ils
permettent d’ouvrir les équipements et permettent la personnalisation du réseau suivant les
applications utilisées ; d’autre part ils sont évidement plus complexes que les réseaux
classiques et introduisent plus de problèmes de sécurité.
Dans cette mémoire, je vais faire l’étude des réseaux Peer-to-Peer avec les différentes
approches, applications, protocoles ainsi que la gestion des réseaux P2P, ensuite une étude
des réseaux actifs, leurs approches et plateformes ainsi que la gestion des réseaux à l’aide des
réseaux actifs ; pour clôturer enfin avec une proposition de conception d’une infrastructure
de supervision pour les services et réseaux P2P qui étudie comment les peers vont
communiquer les informations de gestion de façon active tout en s’inspirant des solutions de
gestion de réseaux a l’aide de l’approche de réseau actif pour l’appliquer à notre réseau P2P.
Une dernière partie aussi se présentera pour mettre en œuvre ma proposition, c’est la partie
pratique dont on aura une implémentation de la plateforme .NET avec le langage de
programmation C# en se referant a la plateforme P2P développée a l’ESIB.
Plus précisément, les réseaux p2p présentent des défis au niveau du passage à
l’échelle. Principalement, le modèle hybride p2p ne passe pas à l’échelle à cause du goulot
d’étranglement au niveau du serveur central malgré la présence de l’application Napster qui
est toujours connu.
Aussi le modèle pure présente un difficile passage à l’échelle à cause du Flooding ou
inondations des messages de configuration Ping et Pong. La limite réside encore dans la
recherche des fichiers qui est limitée en profondeur à cause du champ TTL qui peut avoir
une valeur maximale de sept.
Pour cela on a recourt à un modèle qui est le routage par document. Ce modèle va appliquer
une fonction de hache sur l’intitulé d’un document et lui donner un identificateur puis quand
on va chercher un document on va faire le routage vers le peerID qui est le plus proche du
docID, l’intérêt sera dans la fiabilité et la pertinence de la réponse d’une part et le nombre de
sauts d’une autre part.
7
Les réseaux actifs fournissent un déploiement de services rapide et une distribution de charge
sur le réseau. Mais leur implémentation pose plusieurs défis. Leurs performances doivent être
comparable à celle des réseaux existants ainsi qu’ils doivent offrir au moins la même sécurité
et la même robustesse, ce qui est un grand défi quand le code peut migrer et s’exécuter dans
un grand réseau hétérogène. Vu cette hétérogénéité, ils doivent avoir un certain degré
d’interopérabilité leur permettant de fonctionner comme les réseaux classiques.
Les architectures des réseaux actifs sont groupées selon leurs différentes approches.
L’approche paquets actifs, qui se caractérise par le transport du code actif au niveau des
paquets. Les Smart packets, le projet active IP, et l’architecture MO en sont des exemples.
Dans l’approche nœud actif, les paquets ne transportent pas le code, mais une référence à des
fonctions prédéfinies qui résident dans les nœuds actifs. L’architecture DAN ainsi que ANTS
en sont des exemples.
L’approche paquet actif introduit plus de problèmes de performances, vu que les exigences
de sécurité sont énormes. Ce qui n’est pas le cas de l’approche noeud actif qui offre de
meilleures performances. Mais la flexibilité d’une telle approche est limitée. Dans un effort
pour améliorer cette flexibilité, DAN et ANTS ont adopté un schéma de déploiement de
code à la demande, avec la possibilité de faire un cacheur de ce code, pour des utilisations
ultérieures.
Dans ma proposition de gestion de réseau p2p je vais utiliser l’approche ALAN qui
est Application Level Active Network comme son nom indique un réseau actif au niveau
applicatif. Pour ce, il faudra aborder quelques nouvelles notions aussi qui sont les SuperPeers
et les Pairs Actifs Virtuels (AVP) dont trois thèmes importants qui sont AOL : Application
Optimisation Layer, VCC : Virtuel Contrôle Cash et NOL : Network Optimisation Layer ;
pour arriver à ma contribution qui est de rester sur l’idéologie des réseaux p2p qui dit que
chaque utilisateur est un client et serveur en même temps. Donc la question que je pose est :
« Pourquoi ne pas continuer cette idéologie et au lieu d’avoir un superpeer fixé qui
sera responsable d’un groupe de peers, ne pas avoir un réseau dont chaque peer peut être a
son tour (suivant les conditions du réseau : bande passante, utilité, latence, …) un
superpeer? »
Pour la partie implémentation, il faudra beaucoup plus d’études, de recherches et de temps
pour appliquer cette idée pratiquement, pour cela on va traiter un cas de réseau p2p simple et
étudier sa gestion et plus précisément je vais utiliser la plateforme déjà développée par les
étudiants de l’ESIB, l’implémenter et gérer quelques paramètres qui nous intéressent.
8
PARTIE 1. LES RESEAUX PEER TO PEER
1.1 Introduction
Le sujet de peer-to-peer attire plus d’intérêt dans la communauté de réseau, malgré les
différentes définitions associées à ce terme. Cette technologie qui existe depuis quelques
années, promet de changer radicalement le future des réseaux.
Le peer-to-peer modélise l’échange directe des ressources et services entre ordinateurs,
chaque élément étant client et serveur à la fois, d’où la notion de SERVENT. Un des
principaux avantages étant l’utilisation maximale de la puissance de réseau, en éliminant les
coûts d’infrastructure et en faisant communiquer directement les clients entre eux. Du fait du
déploiement massif des ordinateurs représentant un fort potentiel inactif en bordure de
l’Internet, le P2P retient de plus en plus l’attention de la recherche, des développeurs et des
investisseurs.
Systèmes
informatique
Systèmes
centralisé
Systèmes
distribués
Client Serveur
Peer-to-Peer
Hiérarchiques
Plats
Pures
Hybride
Figure 1.Classification des systèmes informatiques
1.2 Etat de l’art
1.2.1 Généralités
1-Définition :
Le terme peer to peer concerne une classe de systèmes et d’applications qui utilisent des
ressources distribués pour effectuer une tache donnée d’une manière décentralisée.
2- Peer-to-Peer traditionnel :
Définit par Webopidia comme « un type de réseau dans lequel chaque station possède des
capacités et responsabilités équivalentes. Ceci diffère de l’architecture client/serveur dans
laquelle quelques ordinateurs sont dédies pour servir les autres ».
Les ordinateurs dans un Workgroup sont configurés pour partager les ressources comme les
fichiers et imprimantes. Aussi, un ordinateur peut jouer le rôle d’un serveur de fichier ou de
Fax à n’importe quel moment, tous les ordinateurs sur le même réseau peuvent généralement
9
héberger ces services. En particulier, les ordinateurs seront typiquement situés à coté des
autres physiquement tout en possédant les mêmes protocoles de réseaux.
3- Architecture P2P d’aujourd’hui :
Une bonne définition technique des systèmes P2P inclue les sept clefs caractéristiques
suivants :
*Interface usager génère à l’extérieur du navigateur Web.
*Les ordinateurs des usagers peuvent jouer le rôle client/serveur à la fois.
*Tout un système facile à utiliser et intégré.
*Le système incluse des éléments pour supporter les usagers voulant créer quelque chose ou
ajouter des fonctionnalités.
*Le système assure des connections avec les autres usagers.
*Le système fait des choses nouvelles et excitantes.
*Le système supporte les réseaux croises.
Dans cette vue mise à jour des P2P, les éléments maintenant peuvent joindre le réseau de
n’importe ou avec un minimum d’effort. Au lieu des LAN dédiés, Internet devient lui-même
le réseau de choix. La facilité de configuration et de contrôle sur l’application permet à
n’importe qui de se joindre à la communauté.
Trois points importants sont à rajouter :
1- Les éléments constituants d’un réseau paritaire peuvent être de nature différentes
(PC, PDA, téléphone portable, …)
2- Ce réseau présente une topologie virtuelle (Fig.2).
3- Ce réseau est de nature ad hoc, c'est-à-dire que les éléments constituants peuvent aller
et venir et la topologie du réseau est instable.
Réseau pair
à pair virtuel
Computer
Computer
Router
Router
Laptop
Réseau physique
Hand held computer
Workstation
Figure 2. Exemple de Topologie virtuelle.
4- Objectifs P2P :
C’est un modèle très général dont des applications de nature différentes l’utilise d’où les
objectifs sont variés, principalement :
• Partage et réduction des coûts entre les différents peers.
• Fiabilité et passage a l’échelle (pas de centralisation).
• Agrégation de ressources et interopérabilité.
10
• Anonymat assuré par certaines applications.
• Communication ad hoc et collaborative.
5- Classification de réseau P2P :
Modèle pure :
-Parité effective des éléments
-Gnutella, Freenet, …
Modèle hybride :
-Centralisation d’informations
-Différents niveaux : SuperPeers, serveurs d’infos, Centralisés.
IBM Compatible
IBM Compatible
Server
IBM Compatible
IBM Compatible
IBM Compatible
IBM Compatible
IBM Compatible
Modèle décentralisé
Modèle centralisé
Figure 3. Les Modèles p2p
6- Caractéristiques des systèmes P2P :
Les principales caractéristiques des différents protocoles [1]:
• La localisation des fichiers dans un environnement distribué
• Des méta données ou index du réseau P2P
• La libre circulation des fichiers entre systèmes
• Un mode de communication standard (TCP et http)
• Des capacités de connexion variables suivant les modèles
• Des échanges d’informations non sécurisées
• Nature ad hoc
• Aucun peer n’a une vue globale du système.
• Transparence
o Technologie sous-jacente
ƒ Machine
ƒ Connexion réseau
o Adresse et localisation
ƒ Firewall & NAT
ƒ Adressage de niveau applicatif
ƒ Mobilité
• Résistance aux fautes
o Pas de point central
o Utilisation de relais
o Duplication des ressources
• Interopérabilité
o Pas supportée actuellement
o Quelques initiatives
ƒ IETF : BEEP, APEX
ƒ JXTA
• Décentralisation
11
IBM Compatible
o Equilibre la charge du réseau
o Répartit les coûts entre les usagers
o Difficulté à localiser les ressources
o Différents degrés de centralisation
o
7- P2P contre client serveur :
Conceptuellement, le P2P est une alternative au modèle client/serveur, qui est constitué d’un
serveur ou d’un cluster de serveurs et de beaucoup de clients. Dans le modèle pur du P2P, il
n’y a plus de serveur, tous les participants sont des peers. Cependant il n’y a pas de bordures
nettes entre les deux modèles.
Figure 4. P2P vs Client/Serveur
Peer-to-Peer
Client/Serveur
• Auto organisé
• Evolution dynamique, Ad hoc
• Découverte des peers
• Flux distribué (mesh)
• Symétrie du réseau
• Communication par Messages
• Adressage dynamique au niveau application
• Entités Autonomes
• Attaques difficiles (mobilité, anonymat)
• Management centralisé
• Configuré
• Consultation de tables
• Flux centralisé
• Asymétrie du réseau
• Orienté RPC
• Adressage statique @IP
• Entités dépendantes
• Attaques plus simples
1.3 Applications P2P
Application Pair à Pair
Parallèle
Calcul
intensif
Calcul
composental
Gestion des fichiers
et contenus
Echange
de contenu
Systèmes
de fichiers
Filtrage
extraction
Collaboration
Messages
instantannés
Figure 5. La taxonomie des applications p2p
12
Applications
partagées
Jeux
1.3.1 NAPSTER ou le modèle hybride
Napster est une application de partage de fichiers musicaux mp3. Le service est fondé en mai
1999 par Shawn Fanning et Sean Parker. Après différentes poursuites judiciaires pour droits
d’auteur, il est arrêté en septembre 2001.
Aujourd’hui Napster est considéré comme une application phare du modèle P2P, par son
architecture qui utilise le modèle centralisé et décentralisé et par le nombre de
téléchargements effectué (40 millions de téléchargements de fichiers, en moyenne 160 000
utilisateurs).
P2P centralisé ou hybride
Napster utilise un modèle P2P à répertoire centralisé pour les données administratives et les
index des fichiers mp3 téléchargeables par les peers.
Un peer se connecte directement sur le serveur. Le protocole basique est simple, avec des
primitives de service : login request, login OK, login failed, user unknown, user not accepted,
…
Le peer communique au serveur central la liste des fichiers qu’il partage, ainsi qu’un numéro
de port TCP où il pourra être contacté pour un téléchargement.
Les peers sont donc les fournisseurs de fichiers, et les échanges vont se faire directement
entre les peers suivant un modèle pur. La recherche et le téléchargement vont se passer de la
manière représentée sur la figure 6:
Un peer recherchant un fichier va envoyer sa requête au serveur central (1), lequel va lui
répondre par une liste triée de peers qui hébergent le fichier recherché (2). Le peer va alors
choisir parmi les réponses celle qui lui convient le mieux (pertinence de la réponse, bande
passante, taille du fichier, …) et contacte directement le peer choisi. Le téléchargement
s’effectue alors directement entre les deux peers (3).
Figure 6. Les échanges dans Napster
Les limites
• Pas d’anonymat partout
o Vous êtes connus du serveur …
o … et des peers sur lesquels vous téléchargez
• Limites habituelles d’un serveur central
o Disponibilité
o Problème du passage à l’échelle :
Saturation de la bande passante
Saturation du nombreux processus
13
o Légal : très facile de fermer le service car localisé
• Mauvaises informations du débit des peers pour ne pas être sollicités
Les avantages
• Avantages habituels d’un serveur central
o Facile à administrer
o Facile à contrôler, à fermer
• Evite les recherches coûteuses sur le réseau
o Pas de routage
o Planification de la gestion des utilisateurs
• Tolérance aux fautes
o Par un sondage régulier des peers connectés, état cohérent
• Service novateur
o Généralise le P2P
o généralise les procès contre le non-respect des droits d’auteur
Un serveur Napster est toujours connu et son passage à l’échelle parait impossible, vu le
goulot d’étranglement du serveur central.
1.3.2 GNUTELLA ou le modèle pur
Gnutella est un protocole de fichiers partagés. La première version (version 0.4) date de mars
2000, il fut développé en une quinzaine de jours par Justin Frankel et Tom Pepper. Les
applications qui implémentent le protocole Gnutella autorisent les utilisateurs à rechercher et
charger des fichiers sur tous les autres utilisateurs connectés à la communauté Gnutella, avec
plusieurs dizaines de milliers d’utilisateurs simultanés. Il existe beaucoup d’implémentations
compatibles apportant des extensions : Limewire, ToadNode, BearShare.
Terminologie
Comme Gnutella repose sur une architecture réseau complètement décentralisée, chaque
élément joue le rôle à la fois de client et de serveur, d’où la notion de servent qui est la
contraction des mots serveur et client.
Les messages sont les informations émises par les servents à travers le réseau Gnutella.
Le protocole
Gnutella repose sur un modèle pur. C’est un protocole qui fonctionne au-dessus de TCP/IP.
Un servent dispose de 6 types de messages principaux :
• Ping : Utilisé pour découvrir les autres servents sur le réseau. Un servent qui reçoit
un Ping doit répondre avec un ou plusieurs Pong ;
• Pong : C’est la réponse à un Ping; ce message contient l’adresse IP et le port du
servent qui répond, ainsi qu’une information sur les fichiers et leur tailles partagés par
celui-ci ;
• Query : Message pour la recherché de fichier sur le réseau. Un servent qui reçoit un
Query répondra par un Query Hit s’il trouve une correspondance avec un ou plusieurs
de ses fichiers partagés et les critères de recherche ;
• Query Hit : C’est la réponse à un Query (Figure 11) ;
• Get : téléchargement des données (Figure 11) ;
• Push : Permet de télécharger des données depuis un servent qui se trouve derrière un
Firewall.
14
Remarque : Si les deux servents sont derrière un firewall, le téléchargement est impossible.
Les messages ont un en-tête commun (figure 7) :
• Payload Type : type du message (Ping, Pong, …) ;
• Hops : nombre de servents traversés ;
• Payload lenght : longueur du message.
Figure 7. En-tête message Gnutella
Routage des messages
La première opération réalisée par un servent est la connexion à un autre servent connu du
réseau Gnutella (figure 8), chaque servent possédant une liste de servents à utiliser au
démarrage.
Figure 8. Connexion d’un Peer Gnutella
Un nouveau peer s’annonce lui-même sur le réseau en envoyant un ping Gnutella (figure 9).
Afin de diffuser les messages de requête, Gnutella utilise un mécanisme de flooding. Le ping
est propagé à ces voisins, qui envoient eux-mêmes des pings.
Tous les voisins répondent par un pong.
Figure 9. Routage des messages
1
Des champs de TTL et d’identification des messages évitent la diffusion de messages
zombies ainsi que l’apparition de boucles. Chaque requête ping contient un TTL, qui est
décrémenté par chaque voisin. Il est souvent positionné à 7 au départ.
Quand le TTL passe à zéro, la propagation du ping s’arrête, le message est droppé (figure
10).
15
Figure 10. Mécanisme de TTL
Figure 11. Recherche de données (Query-Query Hit)
Bien que le réseau supporte 8000 à 10000 usagers, son mécanisme de flooding amène des
limites, et ne semble pas supporter le passage à l’échelle :
• Réseau rapidement inondé par des Ping et des Pong ;
• Supporte mal une forte montée en charge du nombre d’utilisateurs ;
• Message Push continuellement envoyé si pas de réponse.
Son mécanisme de recherche présente une limite, fixée par la valeur initiale du TTL. Ainsi
une requête peut être stoppée par une expiration de TTL sans avoir parcouru l’intégralité du
réseau et retourner une réponse négative. Seulement 25% des requêtes aboutiraient.
Les avantages
• Administration simple mutualisée
• Topologie évolutive
• Disponibilité du réseau, on ne peut l’arrêter.
Gnutella semble ne pas supporter un passage à l’échelle, et manque de fiabilité dans ses
requêtes.
Une orientation possible est les super peers ou arbre de peers comme dans le protocole en
cours de définition Gnutella Version 0.6 ou comme pour Kazaa.
1.3.3 SKYPE (VOIP)
« Skype est un outil VoIP très efficace, bien conçu et professionnel et c’est sure que si vous
l'essayez pour vous, vous ne serez pas déçu ». Comme ça est défini Skype qui permet VoIP
sous les très pires conditions défavorables, y compris les utilisateurs derrière les pare-feu et
16
derrière NAT qui toujours ont des difficultés dans les communications avec les autres et les
outils de visioconférence.
Bien que la disponibilité de grands outils de visioconférence de Toile qui abordent les
solutions de VoIP fiables et exécutant dès 2002, Skype entre solidement pour remplir une
partie de la niche, trop longue dominée par les majeurs IM (YM, AOLIM, MSN, ICQ), qui
n'ont jamais pu fournir une solution de VoIP véritablement efficace, et par les challengers
téléphoniques tels que Mediaring, Net2Phone et Dialpad.
Skype est basé sur FastTrack, réseau P2P pareil que celui utilisé par Kazaa et les autres
systèmes de partage de fichiers. Contrairement à Yahoo Messenger, Skype compte sur un
réseau P2P (peer-to-peer), signifiant que les paquets de voix n'étant pas envoyés par-dessus
un serveur centralisé qui les redistribue, mais sont directement envoyé entre les utilisateurs.
Figure 12. Skype : Messagerie Instantanée
L'avantage est que Skype ne compte pas sur une infrastructure centralisée pour maintenir la
directoire des utilisateurs router chaque appel. Ceci signifie que les services basés sur une
infrastructure centralisée, le coût d'échelle est proportionnel avec la base d'utilisateurs, alors
que fournissant la qualité et la fiabilité devient toujours plus difficile à atteindre.
Skype est un simple "instant messager" avec des fortes fonctionnalités "Voice Over Ip".
L'installation et le setup sont très faciles.
Si vous avez utilisé un messager immédiat avant, il n'y a rien de nouveau a apprendre; Faire
un appel c'est comme choisir un « ami ».
La qualité, la latence (le retard) de la voix sont véritablement impressionnantes. Les résultats
des tests ont toujours démontre un retard de transmission au dessous de 500ms.
Les caractéristiques d'annulation d'écho sont intégrées de façon continue et il n'y a pas de
problème dans la conversation même si vous avez mis vos haut-parleurs (un problème
typique et très exigeant des premières générations des systèmes VoIP).
Il n’y a rien à appuyer pour parler et le microphone est toujours ouvert sur les deux côtés.
17
La version disponible permet maintenant seulement les appels un à un et elle supporte très
bien les utilisateurs sur les "dial-up lines" même à 33,6 Kbps.
Une fenêtre intégrée de conversation fournit le soutien pour les échanges de texte dans un
mode simple et discret. Si vous parler à quelqu'un, vous pouvez aussi parler avec quelqu'un
d'autre en même temps. Après avoir téléchargé Skype vous pouvez commencer à parler en
moins de 5 minutes.
Dans juste sa première semaine de disponibilité, 60.000 personnes ont téléchargé le logiciel
de Skype gratuit. Les autres services VoIP, tels que Vonage ou Free World Dialup (FWD)
ont besoin de plusieurs mois pour attirer le même niveau d'intérêt.
Skype a fait un travail efficace pour résoudre une fois pour toutes beaucoup de problèmes et
de limitations typiques inhérentes dans les systèmes de VoIP. Le retard, la latence, la qualité
de voix, la largeur de bande, l'annulation d'écho, l'activation de voix automatique et plus.
Quelque chose par exemple qui peut être évité à peine dans les communications de voix sur
IP est le fait que quand votre ordinateur commencent à faire quelque chose d'autre
(télécharge l'email, charger un page Web dans le fond), ce n’est plus aussi fiable et vous
pouvez avoir quelques long moments silencieux ou des mots brisés.
1.4 La gestion des réseaux P2P
A ce jour, il n’est pas d’application P2P qui présente une interface de supervision explicite.
Bien souvent, le minimum de gestion nécessaire au bon fonctionnement d’une application est
effectué de manière autonome. Citons par exemple, Kazaa qui auto configure les peers
participant au service de manière à organiser sa topologie autour de super peers, CAN qui
effectue des mesures de RTT entre peers adjacents virtuellement pour garantir une
performance optimale ou PAST qui propose l’utilisation de cartes à puce pour contrôler
l’accès des usagers à des données distribuées.
1.4.1 Gestion des performances
De plus, les quelques travaux de recherche qui sont menés dans le but d’ajouter un aspect
gestion à des applications P2P ne consistent pas à offrir une interface de supervision à un
éventuel administrateur de domaine, afin que cette catégorie d’application souvent déployée
de manière sauvage puisse être contrôlée, mais plutôt à accroître le niveau intrinsèque de
qualité d’une application P2P, sans se soucier du contexte dans lequel elle est exécutée. C’est
par exemple le cas de The active virtual peer technology [16], une infrastructure P2P qui
permet d’effectuer de la gestion de performance sur une application de type Gnutella. Celleci propose d’utiliser un coeur de réseau P2P actif qui permette de restreindre les messages de
signalisation à des domaines clos, de paramétrer le routage en fonction de l’état des liens, de
rediriger des requêtes de téléchargement, et enfin de contrôler et adapter la topologie
virtuelle.
Dans le même ordre d’idée, on peut citer le projet MMAPPS (Market Management of Peerto-Peer Services) [17] qui a pour objectif de gérer les communautés P2P en utilisant des
techniques issues de la gestion de marché. Ainsi, les applications P2P pourraient être plus
couramment déployées dans un environnement où la coopération entre les peers serait
constructive et ne mettrait pas en danger le potentiel de la communauté. Pour inciter les peers
à contribuer plutôt que de simplement consommer, MMAPPS utilise un mécanisme
18
d’évaluation de la contribution et n’autorise l’accès aux ressources fournies qu’en fonction
de celle-ci.
1.4.2 Contrôle du trafic P2P
Considérons maintenant le coté administration système. De ce point de vue, la supervision
d’un service de partage de fichiers P2P s’apparente plus à un contrôle du trafic plutôt qu’à la
garantie d’une qualité de service aux usagers. Néanmoins, contrôler ce type de trafic s’avère
assez compliqué. En effet, le contrôle du trafic P2P passe tout d’abord par son identification ;
et les applications P2P n’utilisant pas un port bien défini, il est ainsi nécessaire d’inspecter
les paquets jusqu’au niveau des couches 3 à 7 pour identifier un paquet appartenant à un flux
P2P. Ensuite, une fois l’identification d’un paquet P2P effectuée, le contrôle du trafic doit
être en mesure de traiter l’ensemble du flux auquel appartient le paquet, quel que soit le sens
du trafic. Enfin, d’une manière plus générale, les applications P2P changeant constamment, il
est nécessaire de pouvoir répondre à ces changements rapidement et efficacement en
s’adaptant aux nouveaux protocoles et en fournissant de nouveaux mécanismes
d’identification.
Identifier le trafic P2P permet de lui appliquer un traitement particulier en accord avec une
politique de supervision propre. Celle-ci peut consister à contrôler la bande passante P2P
parmi l’ensemble d’un trafic, à différentier le traitement effectué en fonction des sources,
destinations, la date ou le profil d’un usager ou mettre en place un système de quotas par
personne. Néanmoins, ce type de comportement ne peut être déployé que sur des éléments de
réseaux capables d’assurer une bonne identification du trafic et un niveau de ressources
suffisamment conséquent.
1.4.3 La gestion des fichiers et contenus
Ce type d’applications, comme nous l’avons vu au chapitre 2, consiste à stocker et retrouver
des informations sur différents éléments du réseau.
L’application principale concerne l’échange de contenu ; elle est fortement connue par
Napster, Gnutella, Morpheus, Freenet (anonymat des sources et intégrité des documents),
Kazaa et BitTorent, (transfert parallèle de plusieurs sources, possibilité d’arrêt et de reprise
d’un transfert).
D’autres projets consistent à établir un système de fichiers distribué dans une communauté,
comme PAST, OceanStore (plus de 6 millions d’utilisateurs), CAN ou Chord. Les bases de
données distribuées et les tables de hachage distribuées commencent aussi à utiliser les
protocoles P2P (Mariposa).
1.4.4 Gestion de présence JIM
1.4.4.1 Jxta Instant Messaging
JIM est utilisé pour faire une instrumentation de service de présence d'une application IM.
C'est conforme au modèle de présence de IETF qui utilise les peers WATCHER/POLLER.
Cette conception construite sur JXTA nous permet de comparer différentes implémentions
sur cet environnement et de préparer une instrumentation de JXTA soi-même.
Contrairement a d'autre applications IM, JXTA utilise un modèle P2P. En effet, AOL Instant
Messaging ou ICQ, utilisent un modèle client/serveur avec des fonctionnalités très similaire
au "mail", c'est-à-dire un client dans un domaine envoie et reçoit des données messages
instantanées a travers des serveurs bien connu et le routage entre les différents domaines est
fait a travers des communications serveur serveur.
19
a- Les états dans JIM.
Un peer sur JIM peut présenter plusieurs états :
-En ligne: prêt a recevoir et répondre aux messages.
-Occupe: peut recevoir mais peut ne pas répondre immédiatement.
-Loin: peut recevoir mais lente réponse.
-Hors ligne: c'est-à-dire que le peer n'est pas capable de recevoir des messages et les
tentatives d'envoyer des messages sont aussi refusées.
a-1 JIM et JXTA
Dans la figure 13 on peut localiser l'application JIM en relation avec JXTA, qui fournit
plusieurs niveaux et des API pour construire les applications P2P. On peut citer les "pipes"
qui sont des canaux logiques à travers lesquels un peer peut envoyer des données vers u ou
plusieurs peers.
La communication entre les peers peut être achevée autant que les peers appartiennent au
même Peer Group (qui représente un set de peers dans JXTA). Les services de sécurité et de
monitoring du cœur de JXTA ne sont pas directement utilises dans JIM, mais sont utilises
par d'autre éléments de JXTA d'une façon implicite.
Figure 13. Architecture de JIM / Jxta
JIM utilise JXTA pour créer des utilisateurs PeersGroup pour l'application IM et les "pipes"
pour implémenter les messages et les services de présence. La figure suivante illustre le
mécanisme de présence; on peut remarquer qu'un peer contient tout le set d'éléments de
gestion de présence. Peer p1 a une liste des peers appelées "Buddylist" reliée au PeerGroup
de JXTA crée pour JIM et qui utilise un pipe vers chacun.
De cette façon, le modèle opérationnel est le suivant: dans des intervals réguliers un peer
envoie un message Ping a chaque peer appartenant a BuddyList. Chaque peer répond a ce
message en envoyant un Pong contenant son état.
Selon le modèle de l'IETF, un peer envoyant tel requête joue un rôle vers le service de
présence qui est représente par une réponse de chaque peer appelé par le pipe.
L'instanciation du modèle est représentée dans la figure 14. Les entités "Status Updater",
"Controler" et "User" sont des parties logiciel de JIM qui jouent les rôles respectif
observateur, service de présence et présence. Le Status Controler joue un double rôle car il
traite avec les deux messages Pong (Observateur) et Ping (Service de présence).
20
Figure 14. Les peers et les pipes
a-2 Instrumentation:
Pour mesurer les performances du service de présence on choisit d'instrumenter le RTT
(Round Trip Time) d'un échange Ping/Pong.
Le résultat reçu représente le temps qu'un peer doit attendre pour être notifié de l'état d'un
utilisateur. Pour instrumenter ces échanges on utilise comme transaction l'ARM (Application
Response Mesurement), Java Api et implémentation. Chaque record de transaction sera
enregistré dans une plateforme de gestion normée JMX Java Api (Java Management
Extension). ARM est désigne pour évaluer les niveaux de services des systèmes uniques et
des applications distribuées en mesurant la disponibilité et la performance des transactions.
1.4.4.2 RRS
a- Le Service de Rendez-vous a distance (RRS)
RRS (Remote Rendez-vous Service) complète les services fondamentaux de JXTA en
rendant capable la connectivité de pair au réseaux JXTA et en fournissant l'entretien avancés
et les fonctionnalités d'administration pour les pairs de rendez-vous.
Les fonctionnalités de RRS ont été ajoutées à l'application "Shell" de JXTA.
Les autres programmeurs d'application de JXTA peuvent contenir les fonctionnalités de RRS
dans leur code. Pour illustrer le besoin pour et l'usage de RRS, considérer les cas suivants
utilisant le "Shell" de JXTA.
b- Garder un Non Rendez-vous Pair bien Connecté
JXTA pairs ont besoin pour établir des connexions à un ou plusieurs rendez-vous pairs afin
de découvrir des pairs, les groupes de pairs et les autres éléments de réseau au delà du
21
"subnet" local. La configuration par défaut de la plate-forme contient une liste de pairs de
rendez-vous accessibles en public où un pair essaie de se connecter au début d'une session.
Cependant, au cours d'une séance, les connexions aux pairs de rendez-vous peuvent être
perdues, ou aucune connexion ne peut être établie à cause du chargement de pair de rendezvous ou parce qu'il y a des problèmes de routage dans le réseau JXTA.
RRS permet de déterminer si l'arrivée à un pair de rendez-vous particulier est capable, et si la
connexion à lui est établie sans interruption de la séance de pair ou sans la reconfiguration de
la plate-forme.
Un exemple d'une séance "Shell" de JXTA dans lequel l'utilisateur d'un non rendez-vous
pair utilise RRS :
Si l'utilisateur est sur une machine "Windows", il fonctionne le programme "runrrs.bat" dans
le fichier RRS afin de commencer une "Shell" de JXTA RRS-enable.
Supposons que l'utilisateur sait d'un pair de rendez-vous avec l'adresse du point final
"http://jxta.clip2.com:6002". Au début, il vérifie que ce rendez-vous pair peut être atteint par
son pair :
JXTA>endpointping http://jxta.clip2.com:6002
endpoint ping passed
(Cette commande marche fonctionne aussi pour tous les pairs connus et non seulement pour
les rendez-vous pairs.) Si le nœud est atteint, l'utilisateur peut alors connecter son pair au pair
de rendez-vous :
JXTA>rdvadd -e http://jxta.clip2.com:6002
L'utilisateur confirme que la connexion a été ajoutée en tapant la commande rdvstatus (une
partie standard de non-RRS du "Shell"de JXTA).
JXTA>rdvstatus
[rdvstatus output follows]
La commande rdvstatus permet d'imprimer les ID des rendez-vous pairs connectés.
JXTA>rmtrdvstatus -c -p [peerID]
[rmtrdvstatus output follows]
Et reçoit une liste de pairs connectés au pair de rendez-vous. Trouver une longue liste est
bien dans le sens que le pair de rendez-vous est bien connecté, mais c'est mauvais dans le
sens que la réceptivité de ce pair de rendez-vous peut être plus basse que celle d'un paire
moins populaire.
Pour se déconnecter du pair de rendez-vous, il faut simplement écrire la commande suivante:
JXTA> rdvremove -p [peerID]
c- L'administration à distance de Rendez-vous Pairs
Considérons un scénario dans lequel un rendez-vous pair déclenche un processus démon sur
une machine à distance. Dans ce cas, l'opérateur a besoin de pouvoir vérifier le statut du pair
de rendez-vous chaque fois pour déterminer s'il marche bien, combien de connexions il y en
a, et ainsi de suite. RRS implémente les fonctionnalités
pour faire ceci.
L'opérateur fait fonctionner simplement une "Shell" JXTA RRS-enable sur une machine
22
locale (comme dans le premier cas) et après il distribue les commandes RRS au pair de
rendez-vous. Par exemple, s'il y a un besoin pour le pair de rendez-vous de se connecter à des
pairs de rendez-vous supplémentaires, l'opérateur peut taper rdvadd. D'autre part, rdvremove
peut être utilisé pour enlever des connexions aux autres pairs de rendez-vous.
23
PARTIE 2. LES RESEAUX ACTIFS
2.1 Introduction
Plusieurs nouveaux services nécessitent la manipulation des données à l’intérieur des
paquets (web-cache, vidéo multicast, …), le déploiement de ces nouveaux services nécessite
un délai de 6 à 8 ans à partir de l’instant de définition de ses spécifications.
Ces principaux besoins poussent les chercheurs à changer l’architecture passive des réseaux
actuels qui sont de simples réseaux de transfert de données à une architecture plus dynamique
aux exigences des services du future.
C’est entre l’estimation des capacités potentielles du future et l’inertie du passé que
plusieurs approches visent à apporter le dynamisme aux réseaux.
On trouve ainsi des approches plus réalistes dans le sens de la possibilité du déploiement à
court terme comme “opensig” par exemple. Ces approches apportent un changement linéaire à
l’architecture passive des réseaux actuels par le fait de l’adoption d’un nouveau plan de
signalisation pour le déploiement du code à l’intérieur des noeuds et le conservation du plan
normal de transfert de données.
D’autres approches visent des architectures plus puissantes, apportant beaucoup plus
d’abstraction et par la suite plus de malléabilité à l’espace software. On cite les agents mobiles
en premier lieu et les réseaux actifs en second lieu. Ces approches adoptent la définition d’un
être software et les services accomplis par ces types de réseaux sont le fruit de l’interaction
entre ces êtres formant ainsi une société d’êtres software.
Les systèmes multi agents visent des sociétés plus complexes que celles des réseaux actifs, son
être software sont plus puissantes, c’est en être autonome, proactive, social,…
La capacité potentielle de cet être va amplifier son interaction avec son environnement selon
laquelle il va décider quelle action entreprendre. De même l’état de l’environnement de l’agent
est le résultat des actions prisent par chaque agent.
Cette boucle crée une complexité qui est souvent intraçable mathématiquement.
Les réseaux actifs (approche intégrée) de leur coté ne spécifient pas certaines
caractéristiques de leurs être software sauf qu’il doit être de taille réduite, c’est ainsi que la
plupart des applications sur les plates-formes des réseaux actifs définissent des êtres (capsules)
dont la structure est moins complexe que celle de l’agent mobile, cette structure réduite de la
capsule ne va pas trop encombrer l’espace software, ce qui les rend plus réalisables à court
terme que les agents mobiles.
Mais leur implémentation pose plusieurs défis. Leurs performances doivent être comparable à
celle des réseaux existants. Ainsi qu’ils doivent offrir au moins la même sécurité et la même
robustesse, ce qui est un grand défi quand le code peut migrer et s’exécuter dans un grand
réseau hétérogène. Finalement vu cette hétérogénéité, ils doivent avoir un certain degré
d’interopérabilité leur permettant de fonctionner comme les réseaux classiques.
Les architectures des réseaux actifs sont groupées selon leurs différentes approches.
L’approche paquets actifs, qui se caractérise par le transport du code actif au niveau
des paquets. Les Smart packets, le projet active IP, et l’architecture MO en sont des exemples.
24
Dans l’approche nœud actif, les paquets ne transportent pas le code, mais une référence
à des fonctions prédéfinies qui résident dans les nœuds actifs. L’architecture DAN ainsi que
ANTS en sont des exemples.
L’approche packet actif introduit plus de problèmes de performances, vu que les
exigences de sécurité sont énormes. Ce qui n’est pas le cas de l’approche noeud actif qui
offre de meilleures performances. Mais la flexibilité d’une telle approche est limitée. Dans un
effort pour améliorer cette flexibilité, DAN et ANTS ont adopté un schéma de déploiement
de code à la demande, avec la possibilité de faire un caching de ce code, pour des utilisations
ultérieures.
2.2 Etat de l’art
2.2.1 Définition et généralités
Les réseaux traditionnels avaient pour fonction primaire de délivrer les paquets d'un
noeud source vers un nœud destination. Le traitement du réseau était un traitement simple,
indépendant de celui des utilisateurs: Il s'agissait seulement du routage, du contrôle de
congestion et de qualité de service. Ce type de réseau peut être considère comme "passif",
puisque son traitement est le même quelque soit le type de paquet a traiter. Les routeurs, par
exemple, ne comprennent pas plus que le niveau 3, et se basent donc sur l'information du
header pour trouver le chemin vers la destination.
Plus tard, l'évolution des applications et l'avènement des multimédia introduisent un
nouveau type de paquets dans les réseaux, des paquets qui exigent de nouveaux services de la
part du réseau, notamment de la qualité de service , de la limitation des délais de transit et de
leurs variations. On s'est alors rendu compte que donner aux équipements une certaine
intelligence leur permettant de comprendre les informations des niveaux supérieurs, pourrait
optimiser les services offerts par les réseaux, les rendre plus performants. C'est pour cela que
les fournisseurs d'équipements, et dans le but d'améliorer les rendements de leurs produits,
leur donnent une 'intelligence' propriétaire. Les équipements deviennent des systèmes de plus
en plus clos et l'interopérabilité est difficile à réaliser.
Dans une tentative de casser ces barrières, et de passer des réseaux jusque-la clos vers
des réseaux ouverts, une aspiration mondiale vers les réseaux actifs s'est développée.
Un réseau actif est un réseau qui permet aux routeurs intermédiaires d'exécuter des
traitements jusqu'à la couche application. Des codes écrits dans des langages varies peuvent
être charges dans les routeurs. L'exécution dans le réseau de ces codes assure ainsi des
services varies. De plus, les utilisateurs peuvent programmer le réseau en injectant leurs
programmes qui seront exécutes au niveau des nœuds intermédiaires. On dit que les routeurs
font des traitements sur les données mêmes de l'utilisateur. Cette approche de réseaux offre
une infrastructure beaucoup plus flexible avec des capacités croissantes. Cependant elle est
clairement plus complexe que les réseaux traditionnels et demande un niveau de sécurité plus
important.
Grâce aux réseaux actifs, les fournisseurs d'équipements n'auront pas seuls mots à dire
dans la conception des réseaux. Les équipements se transforment en plateformes ouvertes.
Différentes parties peuvent se concentrer chacun sur l'une des fonctionnalistes de
l'équipement. La concurrence entre les différents fournisseurs de 'services' permet à
l'utilisateur de choisir lui-même le service qu'il veut utiliser pour ses données et ceci
indépendamment du type d'équipement par lequel passent ses données.
25
L'implémentation de nouvelles technologies supportant l'encapsulation, le transfert et
l'exécution des programmes et des fragments de programmes a contribue a la création de ces
nouveaux réseaux.
Les réseaux actifs peuvent améliorer la performance du réseau puisque la configuration
des services sous forme d'objets individuels dans des langages de programmation de haut
niveau, facilite leur implémentation et leur manipulation. En conséquent, les réseaux actifs
assurent l'interopérabilité de ces derniers sur des plateformes ouvertes.
Quelques services peuvent être mieux implémentés s'ils utilisent des informations qui
existent exclusivement dans le réseau. De plus, l'avantage des réseaux actifs apparaît dans
l'argument "end-to-end" qui consiste à ne placer une fonction ou un service dans le réseau
que si le rapport efficacité/prix l'impose.
L'argument contre les réseaux actifs est que l'Internet connaît du succès grâce a sa
simplicité, pourquoi donc se compliquer la vie avec les réseaux actifs?
L'implémentation des réseaux actifs montre jusqu'à présent que ces derniers restent,
malgré tout, moins performants que les réseaux passifs. Les codes, étant non propriétaires,
écrits dans des langages de haut niveau, accentuent les délais de traitement dans les nœuds
actifs.
De plus, avoir une plateforme ouverte dans laquelle quiconque peut charger son propre code
et l’exécuter sur le nœud, introduit des problèmes de sécurité. Il faudra s’assurer de la source
du code avant de l’exécution si elle met le nœud en risque…
Tout ceci rend l’architecture du nœud actif du loin plus complexe que l’architecture du nœud
passif sans que cette complexité puisse améliorer de façon concrète les performances.
2.2.2 Applications :
Le grand trait des réseaux actifs est leur capacité à programmer le réseau ; les nouveaux
protocoles et technologies peuvent être facilement implémentés dans les nœuds du réseau,
puisqu ‘il s’agira uniquement du déploiement d’une composante indépendante de la
plateforme
Une des applications la plus utilisée dans les réseaux actifs est l’utilisation de l’agent
« mobile software » qui joue un rôle à côté d’un utilisateur ou d’un autre programme et qui
est capable de se déplacer dans le réseau sous son propre contrôle .L’agent choisit quand et
où il va « migrer », et peut interrompre sa propre exécution et la continuer dans une autre
partie du réseau. L’agent retourne des résultats et des messages d’une façon asynchrone.
Les applications des réseaux actifs présentent des solutions aux problèmes rencontrés dans les
réseaux passifs actuels. Parmi ces applications, nous citons les suivants :
2.2.2.1 Network Management :
Le network management est une application qui consiste à gérer les équipements à distance.
Ceci est réalisé grâce à des stations de Management qui récupèrent les données des
équipements à gérés. Mais vu l’augmentation du nombre de nœuds dans le réseau, plusieurs
problèmes émergent. Le trafic se concentre aux centres de management qui deviennent des
points d’implosions, noyés par un large volume d’informations. De plus, en cas de
problèmes, le délai que l’information subit pour alerter le centre de management et revenir
26
vers le nœud concerné avec des indications sur l’action à prendre, peut être considérable,
rendant cette action inutile puisque le dommage se serait déjà produit.
Les réseaux actifs constituent une solution idéale aux problèmes déjà cités : les nœuds
intermédiaires du réseaux étant actifs. les centre de gestion peuvent être déplacés dans le
cœur du réseau de cette façon on réduit les délais des réponses et l’utilisation de la bande
passante réservée au management.
D’autre part. on peut injecter un code spécial de secours dans les paquets en cas de problème
sur un nœud .Ce code sera exécuté dans le nœud affecté et changera automatiquement son
état sans avoir à attendre la réponse d’un centre de management. D’autres paquets peuvent
jouer le rôle de surveillance (patrol) en cherchant les anomalies au sein du réseau.
Trois projets ont appliqué le concept du réseau actif au Network Management : le projet
« Smart Packets » tenu par BBN Technologies .le projet »Network Mangement » par
« Delegation Pradigm of Colombia University » et le projet « Darwin Project of Carnegie
Mellon University ».
2.2.2.2 Contrôle de gestion :
La congestion est l’un des grands problèmes des réseaux passifs. Les algorithmes de contrôle
de congestion plus ou moins efficaces permettent de résoudre le problème en partie. Les
choses commencent à se compliquer quand les données, de type différents (données,
multimédia…) se multiplexent, et que les mécanismes de contrôle de congestion diffèrent
d’un type de donnée à l’autre.
Les réseaux intelligents peuvent résoudre le problèmes : les nœuds actifs peuvent contenir
une composante pour le contrôle de congestion. Cette dernière pourra, par exemple :
1- prendre des mesures différentes lors de la congestion suivant le type de trafic
2- superviser la bande passante et le débit sortant
3- assurer une qualité de service là cela est nécessaire
4- prendre des décisions plus correctes lorsqu’il s’agit de prendre des paquets à la
congestion
2.2.2.3 Multicasting :
Dans les applications Internet, on rencontre une grande variété de trafic comme l’audio, la vidéo, la
téléconférence, etc…Ces nouvelles techniques se basent la plupart du temps sur le multicast. Les réseaux
actifs peuvent, d’une façon élégante, résoudre beaucoup de problèmes courants comme l’implosion de
Negative ACKnowledge (NACK).la concentration des demandes de retransmission dans une seule
machine, les retransmissions inutiles, la duplication des paquets. A MIT, l’Active Reliable Multicast,
ARM permet de faire du « loss recovery ». Les inventeurs de ARM ont déclaré qu’il peut résoudre tous les
problèmes cités ci-dessus. ARM utilise des routeurs intermédiaires pour protéger l’utilisateur. Ces
routeurs jouent un rôle actif dans le loss recovery.
La solution apportée par les réseaux actifs permet de réduire le nombre de NACK retournant
vers la source du trafic, puisque les routeurs intermédiaires, étant actifs peuvent stocker les
paquets pour une retransmission ultérieure. Les paquets multicast contiennent des informations
sur les nœuds demandant une retransmission. De plus, les paquets NACKs transmis aux nœuds
parents dans l’arbre du multicast, contiennent des informations sur les liens sortants du nœud
d’où sont provenus les NASKs, ainsi que les liens vers lesquels l’équipement est capable de
renvoyer une retransmission. Ceci permet de ne pas retransmettre inutilement les paquets vers
tous les membres du groupe.
27
2.2.3 Sécurité des réseaux actifs :
Dans les réseaux passifs, les paquets arrivant dans les nœuds intermédiaires du réseau ne
consomment que la mémoire et du temps processeur dans le calcul du chemin optimal de
routage du paquet. La situation change pour les réseaux actifs : les paquets actifs peuvent
comporter du code qui s’exécute à l’intérieur même du réseau. Ce code actif est capable, s’il
n’est pas contrôle, de changer nuisiblement l’état d’un nœud actif.
Les attaques qu’ont peut imaginer sur les réseaux ouverts sont beaucoup plus nombreuses et
dangereuses que celles des réseaux passifs .D’ou des mesures de sécurité p lus développées
sont utilisées dans ces derniers.
2.2.3.1 Du point de vue système
Les paquets actifs s’exécutant dans les noeuds actifs consomment du temps processeur. D’ou
la nécessité de réaliser l’équité entre les différents paquets actifs d’une part ,et d’empêcher un
paquet actif de monopolises le processeur ,réalisant ainsi une attaque de ‘Denial of service’
d’autre part .Il faudra donc limiter le temps d’exécution d’un paquet actif et empêcher sa
duplication dans le noeud .De plus une certaine fonction de contrôle dans le noeud actif devra
donner les permissions d’accès aux différentes ressources du noeud après authentification du
paquet ainsi que sa source .Ceci peut être fait grâce a des algorithmes de signature
électronique (mécanismes d’authentification en cryptographie) et de Proof Carrying Code .La
fonction de contrôle suit pour cela une politique de sécurité qui varie suivant les situations .
Le Proof Carrying Code est un mécanisme par lequel la source du paquet actif introduit une
sorte de preuve sur son exactitude .Puisqu’il devient plus facile au actif de vérifier cette
preuve plutôt que de la retrouver, l’authentification devient plus rapide.
D’autres types d’attaques possibles dans les noeuds actifs consistent a envoyer des paquets
qui peuvent accédera des données privées sur le noeud actif, les effacer, les rapporter a un
parti malfaiteur, ou pire encore, détériorer les ressources du noeud.
Les nœuds actifs doivent aussi être capable d’assurer la protection des paquets en les cryptant
d’une part pour empêcher leur interprétation par quiconque, et en utilisant des techniques de
tolérance de fautes d’autre part. De ces techniques de tolérance, on cite la réplication la
redirection, et la persistance.
•
La persistance est le mécanisme de conservation en mémoire statique du
paquet actif dans le noeud , de sorte que la panne du noeud n’entraîne pas
la perte du paquet.
• La réplication, quant à elle, consiste à dupliquer le paquet dans chaque nœud
parcouru par le paquet.
• Alors que la redirection permet au paquet actif de rechercher lui-même un
chemin alternatif en cas de panne de la route principale.
C’est ainsi qu’un nœud actif devra exécuter les étapes suivantes à l’arrivée de chaque paquet
actif:
1.
2.
3.
4.
authentifier le contenu du paquet,
identifier la source du paquet,
identifier la personne envoyant le paquet,
autoriser l’accès aux ressources appropriées basées sur ces identifications
suivant la politique de sécurité,
28
5. permettre l’exécution mais en tenant compte des autorisations suivant la
politique de sécurité,
6. supervise et contrôle les accès aux ressource du système durant toute
l’exécution,
7. si nécessaire, crypter le paquet pour protéger son code et ses données qui
transitent.
Pour garantir un réseau bien sécurise, on doit tenir compte de deux points importants:
l’intégrité et la confiance.
L’intégrité signifie qu’une certaine couche protocolaire délivre un service fiable à la source
supérieur. La confiance veut dire qu’une couche considère comme sécurise et fiables les
services et informations délivrées par la couche inférieure.
2.2.3.2 Du point de vue langage de programmation:
Il est possible de sécuriser le réseau grâce au langage de programmation utilise. Ainsi, on n’a
plus besoin de contrôler l’exécution. L’usage de langages non adaptes peut introduire
certains problèmes dont on cite :
1. L’usage de références vers des secteurs arbitraires de mémoire: le langage Java et la
solution la plus adapter à ce problème puisqu’il est considérer comme un langage
orienter objet qui n’utilise pas la notion des pointeurs comme le langage C.
2. Allocation d’une grande partie de la mémoire ou augmentation du nombre de sous
processus: ceci peut être résolue en limitant le nombre de processus fils que peut
créer n’importe quel processus.
3. Faible performance due a la supervision du processus périodiquement lors de son
exécution par les modules de sécurité. Il est donc préférable d’utilise un langage qui
remplace les contrôles d’exécution dynamiques par les contrôles statiques.
Faible performance due a l’exécution de code: puisque le transport des paquets doit être
rapide, l’exécution du code assurant le transport de ces paquets actifs devrait l’être aussi. Pour
avoir une meilleure performance, il faudra donc séparer les processus responsables du transport
des paquets des autres tels que celui de l’attribution du tas.
2.2.4 Architecture des réseaux actifs:
Les architectures des réseaux actifs sont groupées selon leurs différentes approches:
2.2.4.1 Approches « Actives Paquets » :
La majorité des architectures des réseaux actifs suivent cette approche qui transporte le code
actif dans des paquets. Les nœuds sont actifs car ils permettent les traitements jusqu'à la
couche application, mais ils ne contiennent pas des codes actifs. Le code est tenue par le
paquet puisqu’il sera exécuté pour ce même paquet.
Des exemples de ces architectures sont: le projet « Smart Paquets » propose par BBN
Technologies, le « Actif IP Option » propose par MIT, et le « M0 architecture » propose par
le « University of California at Berkeley » et par l’« Unisversity of Zurich ».Quelques unes
de ces architectures seront décrite plus tard.
29
2.2.4.2 Approche « Active Nodes » :
Dans cette approche, les paquets ne transportent pas le code actuel, mais des références à des
fonctions prédéfinies déjà présentes dans les nœuds. Les paquets décident quelles fonctions
vont être exécuté sur leurs données.
Les architectures utilisant des nœud actifs sont: l’architecture proposée par « Georgia
Institute of Technology », l’architecture DAN proposée par « Washington University » et
« ETH Zurich » et l’architecture ANTS proposée par MIT.
Dans ces architectures, les utilisateurs jouent un rôle très important:
- Ils contrôles l’invocation des fonctions prédéfinies à travers l’information de contrôle
qui se trouve dans l’entête du paquet.
- Ils peuvent sélectionner la fonction à traiter et peuvent ajouter des paramètres a ces
traitement. Le « Network Service Provider » implémente les fonctions a utilisé.
- Ils ont une influence sur le traitement d’une fonction sélectionnée mais ne peuvent
pas définir des fonctions arbitraires à traiter.
Architecture d’un nœud actif:
L’architecture d’un nœud actif définit trois couches de code:
•
La couche de NodeOS représente le système d’exploitation du nœud. Elle a été
conçue pour supporter plusieurs environnements d’exécution (EE), pour offrir une
sécurité entre différents EEs et pour garantir des fonctionnalités communes à chaque
nœud actif. Cette couche est responsable de l’allocation des ressources et des
connexions. Elle gère les memory pools les threadpools et les fichiers.
Les canaux : ils servent a recevoir les paquets entrant (ils sont alors appelles
inCHam- « incoming channel »), a envoyer les paquets (outCham-« outgoing
channel »), et a transiter des paquets a l’intérieur même du nœud (cutChan-« cutthrough channels »).
o Les threadpools : C’est l’abstraction de la capacité de traitement ou d’exécution
délivrée par le nœud actif a un domaine donne. Plusieurs paramètres sont
spécifies lors de la création d’un threadpool comme le nombre maximal de
threads, le synchroniseur, le taux de cycle CPU alloué a ce threadpool.
o Les Memorypools : c’est l’abstraction de la zone mémoire associée au nœud,
utilisée pour implémenter des files d’attente pour les paquets et des piles de
mémoire pour les processus de l’Environnement d’Exécution.
o Les fichiers : C’est l’abstraction des zones de stockage permanentes des données
associées a un environnement d’exécution.
o
•
•
L’Environnement d’Exécution représente l’environnement dans une interférence de
programmation pour les différentes applications développées par les utilisateurs.
L’Active Application (AA) représente l’application développée sur la plateforme du
niveau EE.
30
2.2.4.3 Approche mixte « Active Packets and Nodes »
Il s’agit d’une combinaison des deux approches déjà citées. On utilise donc les paquets
actifs pour transporter les codes simples et restreints, bénéficiant de l’aspect dynamique et
mobile qu’ils apportent au réseau. Quant aux nœuds actifs, ils contiennent les codes les plus
complexes. Suivant la nature de leurs applications, les utilisateurs peuvent bénéficier de la
sécurité apportée par les codes statiques des nœud actifs ou de la mobilité des paquets actifs.
Un exemple typique de cette approche est l’architecture de SwitchWare proposée a
l’université de la Pennsylvanie.
2.2.5 Comparaison
L'approche paquets actifs permet une grande flexibilité du réseau, puisque le code nécessaire
pour traiter le paquet est contenu dans le paquet lui- même. Beaucoup de risques surgissent
pour cette approche, ce qui fait que des mesures de sécurités très strictes sont mises en place
pour protéger le réseau.
L'approche nœuds actifs, quant a elle, offre sécurité et performance :
Les fonctions à exécuter étant déjà présentes dans le nœud, on ne risque pas les dommages
des codes mobiles nuisibles. Les procédures de sécurité sont donc minimisées, ce qui assure
une meilleure performance. Cette approche a cependant un point faible: tout le code d'une
application doit être installe dans chacun des nœuds du réseau pour que cette application
fonctionne. Les codes ne peuvent pas être télécharges dynamiquement, comme c'est le cas
pour les paquets actifs.
C'est pour combler cette lacune que ANTS et DAN a pensé à des techniques de déploiement
dynamique de code en utilisant des méthodes de catching dans les nœuds actifs du réseau.
2.2.6 Réseaux Actifs et Ants
La technique des réseaux actifs et l’idée des capsules a été décrite premièrement par
(Tennehouse & Wetherall 1996).la caractéristique importantes des capsules est leur taille
minime, qui est tolérable par la dimension actuelle de l’espace software, ce qui les rend plus
effectives actuellement à la réalisation des services que d’autres techniques. On trouve deux
approches dans les réseaux actifs (l’approche intégrée et l’approche discrète).
- Approche discret :
Par cette approche on distingue 2 plans, un plan pour le déploiement du code et un autre
plan de donnée pour le transfert normal des données des utilisateurs. Cette différenciation
des 2 plans apporte dans un premier temps un taux de sécurité élevé par rapport à d’autres
approches puisque les techniques du déploiement du code par l’utilisateur dans le même
espace d’exécution demeure non mure et nécessite des efforts supplémentaires du point de
vue de contrôle de ressources et de sécurité qu’on va décrire quelques uns dans les
chapitres qui suivent.
31
- Approche intégrée:
L’approche intégrée combine les 2 plans code et données et unifie l’espace software par la
définition élémentaire de son être software. Cette approche présente évidement des défis
de contrôle de ressources et de sécurité mais présente plus de malléabilité et d’abstraction
au niveau programmation.
Plusieurs plates-formes existent actuellement pour les réseaux actifs:
- Smart packet and sprocket
- Switchwar and plan
- Active IP
- Ants
- …
Les besoins de contrôle de ressources, sécurité et multiplication des environnements
exécution actuels ont conduits à la proposition d’une architecture commune pour les réseaux
actifs pour un groupe de travail sur les réseaux actif financé par DARPA.
Cette architecture basée sur 3 couches sera détaillée dans le paragraphe suivant.
2.2.6.1 NodeOS des réseaux actifs
L’Active Network Working Group de DARPA a établit une nouvelles architecture pour
le noeud d’un réseau actif dans laquelle on définit un système d’exploitation pour le noeud.
Active application
Exécution Environnement
NodeOS
Cette architecture définit 3 couches de codes (AN working group)
Le plus bas niveau représente le système d’exploitation du noeud, il est responsable du
multiplexage des ressources pour les différents types de capsules traversant le noeud.
Le second niveau l’environnement exécution dans lequel les capsules vont être exécutés
Il présente ainsi une interface de programmation pour les différentes applications développées
par les utilisateurs.
Le dernier niveau représente l’application développée sur la plate-forme du deuxième niveau.
Cette structure va permettre le support de plusieurs environnements exécution sur un
même NodeOS et par suite sur un même noeud et assure en même temps le contrôle des
ressources dans le Coeur commun de NodeOS.
1. Architecture du NodeOS:
L’interface NodeOS définit 5 abstractions principales:
-
domaine
channels
threadpools
memorypools
Files
32
Les 4 dernières abstractions révèlent les ressources du noeud : bande passante, cycle
Cpu, mémoire volatile et mémoire permanente. La première abstraction ou notion, qui est le
domaine en capsule les ressources du noeud suivant les 4 dernières abstractions et les
attribues à un type donné de paquets. Un domaine peut contenir ainsi une collection de
channels, une memorypool et un threadpool.
A- Domaine
Les domaines sont organisés en hiérarchies. Le domaine principal sera alors le
NodeOS, les domaines secondaires (fils) seront les environnements exécution et les domaines
tertiaires seront les applications actives.
Cette structure en hiérarchie est indépendante de l’allocation des ressources, c’est à dire les
ressources attribuées au domaine fils ne sont pas comptés des ressources attribuées aux
domaines pères.
Il faut noter aussi qu’à chaque domaine, il est attribué une identité de sécurité
(credential) qu’il lui associe certains privilèges ou permission à l’accès à certaines méthodes de
NodeOS.
B- Channels
Les channels représentent l’abstraction de contrôle de ressources présent par le passage
d’un type donné de paquet .Ainsi un Channel consomme de threadpool et memorypool
attribué au domaine auquel il appartient , on distingue 3 types de channels:
-
inchannels: pour recevoir les paquets entrant au noeud et délivrer à l’environnement
exécution
Outchannels : pour lancer les paquets sortant du noeud
Cut-through channels : pour transmettre les paquets (transit) passant par le noeud et non
délivré à aucun environnement exécution
C- Threadpools
C’est l’abstraction de la capacité de traitement ou exécution délivré par un noeud actif
à un domaine donné. Plusieurs paramètres sont spécifiés lors de la création d’un threadpool:
-
nombre maximal de thread
le synchroniseur
taux de cycle Cpu alloue au pool
…
D- Memorypool
C’est l’abstraction de la zone mémoire associée au noeud. Il faut noter qu’une pile de
mémoire peut être associé à plusieurs domaines cela pour donner à l’environnement exécution
la possibilité de gestion des ressources mémoires allouées à ses domaines.
E- Files
C’est l’abstraction des zones de stockage permanent des données associées à un
environnement exécution.
33
2.2.6.2. Protocole ANEP
ANEP, Active Network Encapsulation Protocole, représente un protocole
d’encapsulation des paquets des réseaux actifs pour la transmission dans différents réseaux, ce
protocole propose un format qui permet l’utilisation de l’infrastructure actuelle des réseaux
comme IP ou Ipv6, il permet en même temps la coexistence de plusieurs environnement
d’exécution dans un réseau ou dans un même noeud et assure le démultiplexage des paquets
suivant leur environnement exécution.
Le champ option de ce protocole assure son extensibilité, on peut ainsi intégrer des
mécanismes d’authentification, confidentialité ou intégrité.
2.2.6.3. ANTS “Active Network Transfer System”
Je ne sais pas si c’est voulu ou c’est une coïncidence,mais que l’abréviation de cette
plate-forme signifie “fourmis” et que le déploiement du code adopté par cette dernière
ressemble au déploiement de phéromones par les fourmis lors de leurs parcours est amusant à
constater.
Architecture
L’Ants est l’une des premières plates-formes de réseaux actifs, sa première version
n’implante pas la notion de NodeOS de DARPA, alors que dans sa deuxième version Ants2.0 il
y a une séparation des fonctions attribuées à un environnement exécution et celle au NodeOS
(projet Janos).
L’architecture de la nouvelle version sera décrite dans le chapitre suivant mais dans
cette partie on va décrire les considérations architecturales invariantes qui caractérise cette
plate-forme comme le chargement de code, les capsules en groupe et le modèle de référence de
capsules.
A-Chargement de code
Le chargement se fait par propagation du noeud extrémité lançant une capsule donnée,
passant par les noeuds intermédiaire dont chacun commence à recevoir le protocole (traitant la
capsule ) du noeud qui le précède arrivant au noeud destinataire de le capsule en question . Les
protocoles ainsi chargés sont sauvegardés dans le cache de ce dernier.
Avec ce mécanisme le chargement de code est sensiblement séparé du transfert normal
des capsules lancées par les applications pour accomplir le service voulu.
Cette séparation a pour but suivant Wetherall d’apporter de la performance par la réduction
du trafic de transfert de code dans les lignes de communication et par le fait que le chargement
de code n’est effectué que seulement dans l’ensemble des noeuds du réseau suivant lesquels les
capsules y passent.
B-Capsules en groupe
Le modèle de déploiement de code adopté par Ants et expliqué dans le paragraphe
précèdent impose donc un transfert de code d’un noeud à un autre.
Le principe d’optimisation impose le changement du code nécessaire et suffisant pour
accomplir un but donné dans un noeud donné.
34
David Watherall a fais un compromise entre un déploiement entier et de tout le code
d’un protocole et le déploiement spécifique de juste du code qui va être exécuter dans un
noeud donné et décomposant le protocole en Codes Group. Ces codes groups représentent un
ensemble de capsules qui seront déployées ensemble dans un noeud donné. Le choix des
capsules qui appartiennent au même groupe sera affecter par la relation entre elle et plus
précisément si l’une nécessite la génération d’une autre.
De cette manière si une capsule X va générer une capsule Y (par exemple) dans un noeud N, la
code group contenant la capsule X va être chargé du noeud précèdent, et la capsule Y va être
génère directement (sans chargement supplémentaire) puisque cette dernière appartient aussi
Code Group contenant la capsule X et qui est déjà chargée.
Si les capsules sont les unités élémentaires de transfert du code exécutables dans le réseaux, les
“codes Group” dans Ants seront les unités élémentaires de déploiement du code exécutable
dans le réseaux.
Ce modèle de capsule en group présente un désavantage de redondance ,on peut avoir
le cas ou on a besoin d’une capsules dans plusieurs code group et le code de celle ci sera alors
chargé plusieurs fois dans le même noeud. Un changement convenable non compliqué dans le
code d’Ants peut permettre de résoudre ce problème en permettant à différentes capsules de
différent code groups d’avoir différents noms mais ferons référence au même code dans le
cache.
C-Capsule par référence
Comme c’est déjà décrit dans le paragraphe précédent, chaque environnement
exécution essaya de créer des locaux exécution indépendants pour ses différent services afin
d’organiser et sécuriser leur travail. Wetherall adopte dans son rapport de thèse un mécanisme
qu’il appel “fingerprint-based protection”
Pour faire la séparation des services, ce modèle intègre dans l’entente de chaque capsule une
référence à son code qui se trouve dans le cache du noeud. Cette référence est calcule par une
suite de hachageMD5 de son code, de son code group et de son protocole.
Ce mécanisme lie alors la capsule a son code, a la structure de son code group et a celle
de son protocole et une vérification de cette référence est exécute par la plate forme Ants
2.0seulement lors du déploiement du code dans le noeud.
Wetherall déclare alors que son nouveau modèle de protection adopte la séparation de
services au lieu d’utilisateur (mécanisme lourd d’authentification) et il est exécute durant le
déploiement du code au lieu du “run time” ce qui le rend acceptable de point de vue sécurité et
optimal de point de vue consommation de ressource. Mais ce modèle de protection de service
lie la référence d’une capsule a la structure du protocole tout entier et je pense qu’elle fige le
service et l’empêche de la rénovation ou l’amélioration linéaire puisque le changement d’un
bit de code de n’importe quelle capsule va affecter toutes références de toutes les capsules du
protocole.
35
2.3 Gestion des Réseaux Actifs
2.3.1 MIB basée XML : Architecture de gestion de réseau actif
2.3.1.1 Introduction
Le réseau actif est un paradigme notable de NGI (Next Generation Network). Ce concept va
résoudre le problème des réseaux contemporains. Plusieurs problèmes avec les réseaux
d'aujourd'hui sont identifies: la difficulté d'intégrer des nouvelles technologies et standard a
l'infrastructure des réseaux commun, faible performance a cause des opérations redondantes a
plusieurs couches de protocoles et des difficultés dans l'accommodation de nouveau services
dans le model architectural présent.
Dans le réseau actif, les paquets portent des codes de programmes en plus que les données.
Ces paquets sont appelés paquets actifs ou capsules.
Le code peut être un programme (service) ou peut instancier une nouvelle application
(extension) dans les nœuds.
Aussi les nœuds actifs peuvent créer des nœuds actifs virtuels en utilisant leur propre
environnement d'exécution. Le nœud actif virtuel capte les fonctionnalités et les ressources
que le fournisseur offre au consommateur et il peut être utilise par le consommateur pour
lancer les services du réseau. Aussi le nœud actif virtuel est similaire dans quelques
caractéristiques au VPN (Virtual Private Network), le réseau actif virtuel assure un degré de
flexibilité et de contrôle plus grand que le VPN.
On va étudier une architecture de gestion MIB basée sur xml pour le nœud actif virtuel dans
un réseau actif.
2.3.1.2 Translation MIB à XML
Généralement MIB signifie que l'information de gestion est une agrégation de systèmes ou
applications spécifiques.
Cette information est décrite par ASN1 et aussi définie par SMI (Structure of Management
Information). XML est propose par W3C en 1998 et 'est un type de texte standard qui assure
le transfert des documents structures a travers le web. XML peut surmonter la présentation
limitée de HTML et résoudre la complexité de SGML. L'utilisateur de XML peut définir un
nouveau tag user-define.
La raison de translation de MIB à XML résulte de la variété et des forts avantages de XML
vue que XML a une extensibilité pour faire des structures nouvellement définies en lumière,
aussi si on utilise XML pour la présentation des informations, pour la gestion des systèmes
ou des réseaux, il amène beaucoup d'avantages au système au niveau de la gestion des
données intégrées et le gestion des données gérées.
De plus, MIB basé sur XML assure une montée dynamiquement de la MIB, des versions,
partager les informations de gestion entre les applications de gestion et observer les
informations de gestion à travers le navigateur WEB.
36
2.3.1.3 La méthode de transmission de la MIB basée sur XML en utilisant
ANEP
ANEP (Active Network Encapsulation Protocol) spécifie un mécanisme d'encapsulation des
trames du réseau actif pour la transmission sur les medias différents. Le format suggère
permet d'utiliser l'infrastructure du réseau existant ou la transmission sur la couche de lien.
Le mécanisme propose doit être le plus générique et extensible possible. Ce mécanisme
permet la co-existence de différents environnements d'exécutions et un décodage propre des
paquets reçus.
La figure suivante montre le format de paquet d'ANEP. Chaque champ est rempli par la
valeur correspondante.
Version
Flags
Type ID
ANEP Header Length ANEP Packet Length
Options
Payload
Figure 15. Le format de paquet d’ANEP
Dans notre cas, on prend les champs TYPEID et PayLoad pour la transmission des données
de la MIB basée sur XML. Le TYPEID indique l'environnement d'évaluation du message. Le
nœud actif doit évaluer le paquet dans le propre environnement. La longueur de ce champ est
de 16 bits.
ANANA (Active Network Assigned Number Authority) est la bonne autorité pour assigner
les valeurs du TYPEID. On définie dans notre cas deux TYPEID pour les opérations
d'insertion et d'enlèvement de la MIB.
Le champ payload est rempli par des données String qui sont décrit par XML pour
représenter une MIB. Le nœud actif virtuel est l'endroit où les opérations de créations et de
terminaisons de service sont fréquemment déclenchées par l'utilisateur du nœud. Ces derniers
qui allouent les ressources du nœud, veulent contrôler leurs services pour assurer un QoS
(Quality of Service). Quand le paquet arrive au nœud actif, le paquet sera contrôlé par démon
ANEP et ensuite les opérations d'insertions ou effacement peuvent être décidé par le
TYPEID. Si une opération est sélectionnée, la MIB sera insérée ou effacée à travers le
processus d'analyse utilisant JDOM API qui analyse les données XML des PayLoads.
2.3.1.4 Le MIB 'manager' dans un Noeud Actif
Virtual Active Node est un type de service qui est assure par le nœud actif. Le client qui loue
un nœud actif virtuel pour faire ses services, veut contrôler son état. Pour cela, dans un
système de réseau actif virtuel, la nouvelle definition de la MIB est demandée quand les
nouveaux services sont crées. Alors, le client doit définir la MIB qui répond aux types de
services qu'il veut. Quand la definition de la MIB est finie, le client envoie un paquet pour
ajouter une MIB appropriée dans son système. La figure suivante montre l'architecture d'un
MIB 'manager' pour un nœud virtuel actif et son processus.
37
3, 4
MIB Manager
XML based MIB
2
1
ANEP Parser
5
1- Prendre les paquets
actifs reçus du buffer
2- Voir le TypeID du
paquet header
3- Si TypeID est 200
ou 201 envoyer vers
le module
4- Ajouter ou détruire
la MIB en utilisant API
5- Autre processus
Autre processeur
Buffer
Architecture d’un MIB manager pour un nœud actif
Figure 16. XML basée MIB
2.3.2 AVNMP: Active Virtual Network Management Prediction
AVNMP fournit un service de prédiction de réseau désigne pour faciliter la gestion des
réseaux actifs larges et complexes d'une manière proactive.
La gestion de réseau incluse une vaste variété de responsabilité dont la gestion de la
configuration, des fautes, des calculs et de la sécurité. Un système de gestion de réseau doit
être capable de contrôler, gérer et rapporter sur l'état de tous ces secteurs.
En plus, le système de gestion de réseau doit être plus qu'un équipement pour génère des
rapports et aider à fixer les problèmes, il doit avoir la capacité d'anticiper et fixer les
problèmes avant qu'ils influent la performance du réseau. AVNMP complète la prédiction et
l'anticipation de faute en utilisant un complément de concepts de simulations distribues et de
réseau actif.
Un simple exemple montre les résultats d'AVNMP sur un seul nœud pour la prédiction de la
charge qui est montrée dans la figure suivante:
38
Figure 17. Prédiction de charge
Dans les systèmes de gestion de nos jours une MIB (Management Information Base)
maintient seulement les valeurs de l'état courant. Dans AVNMP, la charge est prédite dans le
future comme dans l'avancement du temps réel, appelé Wallclock. Alors les valeurs futures
estimées sont valables sur le nœud ainsi que les valeurs courantes.
Dans la figure précédente, le Local Virtual Time (LVT), qui est le temps future, s'écoule en
avant du Wallclock Time (temps courant). Les valeurs des charges prédîtes sont raffinées
jusqu'au moment où le Wallclock atteint le LVT d'une valeur particulière. Cette capacité est
assurée par une nouvelle plateforme de gestion de réseau proactive qui combine trois clefs
qui rendent cette topologie capable:
Simulation distribuée, synchronisation optimisée et réseaux actifs.
La capacité de prédiction fournie par AVNMP facilite le développement d’une variété
d’application prédictive de la gestion des endroits des modèles sans fils et la sécurité des
réseaux pour améliorer la QOS.
AVNMP fournit un service de prédiction idéal pour les systèmes mobiles pour prédire leurs
endroits. Puisque l’allocation des mobiles peut être prédite, les situations de hand-off sont
connus avant qu’ils occurrent et l’organisation des hand-off peut prendre place avant
événements ce qui résulte un hand-off plus rapide et une meilleur QOS.
Dans le domaine de la sécurité de réseau, AVNMP peut anticiper le progrès d’une attaque à
travers tous les chemins possibles de vulnérabilité et incorporer cette information pour
prendre la décision. Une attaque peut être propagées à travers le système avant qu’elle arrive
pour déterminer son impacte. Plusieurs d’autres utilisations et scénarios de AVNMP sont
aussi valables.
Finalement, la gestion proactive est un ingrédient nécessaire pour gérer les futurs réseaux
Une partie des capacités proactives est assurée en analysant la performance courante et
prédisant les futures performances basées sur des événements qui peuvent avoir lieu dans le
futur et la réaction du réseau à ces événements.
39
2.3.3 Application Level Active Network
2.3.3.1 Introduction
D’abord les recherches dans le domaine des réseaux actifs étaient conduites au niveau réseau
(IP, routeur). Mais le réseau actif à ce niveau peut présenter des problèmes de sécurité et
inefficacité d’allocation des ressources.
Pour cela on a penser à implémenter un réseau actif au niveau applicatif d’où la notion
d’ALAN : Application Level Active Network.
Les réseaux actifs implémentés permettent à des serveurs spécifiques de lancer eux-mêmes
des programmes qui permettent le développement de nouveaux services de réseau.
2.3.3.2 Motivation
A nos jours, c’est très difficile d’ajouter des codes au niveau applicatif. Cette opération
implique une mise a jour an niveau logiciel et dans la plupart des cas ils sont installes dans
des machines spécifiques comme routeurs, serveurs d’accès, et d’autres machines
spécialisées.
Mais maintenant, i y a des serveurs qui sont connectes largement dans le réseau qui rendent
possible d’ajouter des fonctions similaires au niveau application comme celles qui existent
au niveau IP. Ceux ci doivent optimiser la communication et peuvent être introduit par des
codes dynamiques charges sur les serveurs d’extrémités.
2.3.3.3 Les Buts
Actuellement, le principal objectif d’un tel projet est de développer un logiciel pour le
modèle ALAN. La plateforme ALAN décrit des composants distincts qui possèdent toute les
capacités pour l’allocation des taches sur un réseau actif. On est concerné avec les problèmes
suivants :
Mobilité
Capacité de transporter le code entre les logiciels de plateformes différentes qui massacre
différents types de codes.
Sécurité
La capacité à limiter des ressources que les objets pourraient demander. Par exemple, ne pas
permettre d’écrire dans le système de classement local aux noeuds actifs. Ceci va en toute
probabilité être une partie de la tâche installée dans chaque noeud actif.
Efficacité
S'assurer que considérant les problèmes ci-dessus la performance ne sera pas affectée.
40
2.3.3.4 ALAN (Fry et Al)
Le modèle de base consiste d’une architecture client/serveur. Les clients peuvent être des
applications Standalone crées par n’importe quel ôte Internet. La communication entre les
clients et les serveurs est établie à travers Dynamique Proxy Server (DPS). Il est aussi
possible de charger dynamiquement les protocoles au système ALAN. Les composantes des
protocoles sont emmagasinées dans des Protocol Server et ils actent comme des filtres pour
rendre la communication entre les clients et les serveurs plus rapide. Ainsi, un client peut
demander un protocole spécifique pour établir un lien avec le serveur. Il faut aussi qu’un
accord entre le client et le serveur spécifiant quel protocole de communication va être valable
pour leur communication soit possible.
La figure 18 montre le diagramme du cadre ALAN proposé par Fry et Al.
Figure 18. Architecture ALAN
Dynamic Proxy Server – DPS
Ce type de serveur est le principal composent du système. Le DPS a des responsabilités de
s’occuper des Proxylets. Il rend l’exécution des codes des parties tierces prélevées du
Proylets Server faisable. Une cachette de serveur est adoptée au DPS pour rendre possible la
réutilisation des Proxylets. Juste avant que le DPS essaye de trouver une Proxylet d’un autre
serveur, le DPS cherche dans sa propre table. Si la Proxylet est trouvée mise à jour sur la
cachette locale, ce n’est pas logique de continuer la recherche sur les autres serveurs. La
41
notion de cache peut réduire le taux de ressources à l’aide de la réduction de l’utilisation de
la bande passante du réseau.
Typiquement, un DPS fournit les interfaces suivantes :
-Load_Proxylet (URL, ProxyletName)
Charge dynamiquement une Proxylet. Pour cela, un URL qui réfère à un Proxylet Server est
passé. La communication entre le DPS et Proxylet Server peut être établie en utilisant
n’importe quel protocole d’application valable. C’est mandataire qu’une validation soit
achevée à ce stage en utilisant les politiques qui se trouve emmagasinés dans le Policy
Server.
-Run_Proxylet (Proxylet Name)
Lance la Proxylet déjà chargée.
-Modify_Proxylet (Proxylet Name)
Utilisé pour changer l’état de la Proxylet.
-Stop_Proxylet (Proxylet Name)
Utilisé pour annuler une Proxylet qui n’a plus besoin d’être exécuté.
De plus, chacune des opérations mentionnées ci-dessus quand appelés, les rendements
emmagasine de l'information du comportement de DPS dans le Serveur de Comptabilité.
Cette information joue un rôle important pour l'interception de réseau et la visualisation.
Juste avant de traiter une opération, le DPS suit quelques indications de sécurité. D’abord, il
vérifie les règles de cloison pare-feu emmagasinées dans le Serveur de Serveur/Politique de
Cloison pare-feu. Ce serveur sert d'un filtre bloquant pour les opérations ou les hôtes
spécifiques. L'intégrité de code doit être vérifiée pour s'assurer que le code binaire n'a pas été
immédiatement changé.
Proxylet Server
Fondamentalement, il a la fonction de stockage de Proxylets dans la forme binaire. Il n'offre
pas une interface directement. Le DPS prélève Proxylets de ce serveur utilisant les protocoles
de FTP ou HTTP.
Proxylet
D’abord, Proxylets sont des programmes être exécutés dans DPS. Un Proxylet peut contenir
des filtres et des protocoles qui sont attachés dans son propre code. Cependant, cette pratique
ne peut pas aider le réutilisation de Proxylet dans le DPS. La meilleure approche est pour le
chargement dynamique de Proxylet le composant de Pile de Protocole est exigée.
Dans notre implémentation le Proxylet de composant fournit une interface avec les
opérations :
42
Run () – Opération abstraite qui doit être implémentée par les développeurs de Proxylet avec
le code approprié pour l’exécuter dans le DPS.
Stop () – terminer une exécution de Proxylet.
Les deux opérations doivent être invoquées seulement par le DPS qui a une permission de
charger, lancer et arrêter une Proxylet.
De même que ceci, un Proxylet peut avoir autant de méthodes qu'il a besoin de. Bien que
seulement le Run () et le Stop () sera directement exécuté, un directeur de sécurité doit être
installé pour éviter n'importe quel défaut de sécurité avec la mémoire locale et le système de
classement local.
Protocol Stack
C'est une interface flexible disponible à l'entrepreneur de Proxylet. Cependant, il n'y a pas de
série fixe d'opérations comme nous avons trouvé dans l'interface de Proxylet. Chaque
entrepreneur de Pile de Protocole exporte pour ses utilisateurs une interface ouverte.
Fondamentalement, l'entrepreneur de Pile de Protocole spécifie quelles opérations devraient
être exportées. Cependant, nous avons trouvé utile définit quelques opérations cachées pour
cet entrepreneur. Cet arrangement vise à exécuter quelque vérification d'intégrité de code.
Retourner à notre exemple de serveur de FTP, nous pouvons agréger deux autres opérations
telles que Check_Integrity () et Verify_Firewall_Table (). Ces opérations ne sont pas visibles
pour les entrepreneurs.
Monitors Systèmes
Ce module fournit des moyens pour obtenir l'état de système d'ALAN actuel. Toutes données
pertinentes aux serveurs de réseau sont emmagasinées dans le Serveur de Comptabilité. Les
événements importants qui peuvent être observés sont :
-L’état de Réseau - l'information des Piles de Proxylets et Protocole. Quelques champs de
données qui semblent être utiles sont : l'adresse de IP, le serveur de dépôt, Proxylet ou le
nom de Pile de Protocole, le timestamp d'événement et l’état (le programme chargé, le
programme courant, le programme modifié, le programme terminé).
-L’état de Serveur - une série fixe d'information des serveurs de système tels que : l'hôte
nomme et IP, le système opérationnels et le statut de serveur (courant, occupé ou sans la
communication).
Ce module est serviable pour appliquer une balance de chargement dans le système d'ALAN.
Le système a besoin de conclure le sens des données de comptabilité emmagasinées afin
d'élaborer une carte de réseau sur le plan du chargement, l'usage de largeur de bande et les
autres mesures pertinentes qui peuvent améliorer l'exécution de réseau actif.
Client
Le client est une entité importante dans le cadre. Il développe ses programmes pour exécuter
Proxylets dans le DPS. Le résultat de calcul est donné dans les types de données accorder
entre Proxylet et le client. Donc, le client réagit réciproquement directement avec le DPS.
43
PARTIE 3. LA PROPOSITION
Proposition d’architecture de réseau actif pour le déploiement et la gestion d’un
réseau Peer to Peer.
3.1 Introduction
Donc dans notre proposition d’architecture de réseau actif pour le déploiement et la gestion
d’un réseau p2p, on va se baser sur l’architecture d’ALAN dont on a déjà parler, qui n’est
autre qu’un réseau actif au niveau application, pour la gestion des réseaux p2p.
Pour cela, il faudrait aborder quelques notions qui sont les Superpeers, avec leurs
implémentations et les Rendez-vous Superpeer, et VAP Virtual Active Peer qui introduisent
de nouvelles couches au niveau des superpeers qui sont AOL, VCC et NOL dont on verra
leurs spécifications ultérieurement.
Je vais ajouter à cette proposition ma propre contribution qui sera un attachement à
l’idéologie de SERVENT, qui est la définition de base du réseau Peer to Peer et qui dit que
chaque peer peut être client et serveur à la fois.
3.2 Super Peer
Un super peer est un noeud dans un réseau P2P qui opère de deux façons "serveur" pour un
set de client et équivalent dans un réseau superpeers.
Les réseaux super peer assurent une balance entre l'efficacité des recherches centralisées et
l'autonomie, la charge et la robustesse contre les attaques fournies par la recherche distribuée.
De plus ils prennent l'avantage des capacités hétérogènes a travers les peers (comme la bande
passante) que les nouvelles études ont démontre qu'ils sont énormes.
Les nouveaux et anciens systèmes P2P comme Kazaa et Gnutella sont entrain d'adopter les
supers peers dans leurs systèmes.
Les réseaux super peers pressentent un passage entre les systèmes pures et les systèmes
hybrides. Un super peer est un nœud qui acte comme un serveur centralise à un certain
nombre de clients. Les clients envoient leurs requêtes vers leurs super peers et reçoivent les
résultats de lui comme un système hybride. Mais les supers peers sont aussi connectes les uns
aux autres comme des peers dans un système pure qui route les messages sur le réseau,
répond et reçoit les requêtes de leurs clients. Donc les super peers sont équivalents dans le
terme de la et tous les peers (inclus les clients) sont équivalents dans le terme du
téléchargement.
Un réseau superpeer est simplement un réseau P2P constitué de ces super peers et de leurs
clients. A cause de la combinaison que les réseaux super peers font entre les éléments des
systèmes purs et des systèmes hybrides, ils ont le potentiel de combiner l'efficacité de la
recherche centralisée avec l'autonomie, le balancement des charges et la robustesse contre les
attaques fournies par la recherche distribuée.
44
Par exemple, puisque les super peers réagissent comme des serveurs centrales pour leurs
clients, ils peuvent contrôler les requêtes avec plus efficacité Cependant puisqu'il y a
relativement plusieurs super peers dans un système aucun superpeer a besoin de contrôler
une grande charge, si un peer devient aura goulot d'étranglement ou un unique point d'échec
pour le système entier.
3.2.1 Les Réseaux Superpeers :
Un réseau super peer opère exactement comme un réseau P2P pur, à l'exception que chaque
nœud, comme décrit avant est un superpeer et chaque superpeer est connecté à un set de
clients. Les clients sont connectes à un seul superpeer.
La figure illustre comment la topologie d'un réseau superpeer va être. On appelle superpeer et
ses clients "clusters", où la taille du cluster est le nombre de clients et du superpeer dans un
cluster.
Figure 19. Illustration d’un réseau Superpeer
Un réseau P2P pur est alors un réseau superpeer "dégénéré" où la taille du cluster est de 1
c'est à dire que chaque nœud est un superpeer avec aucun client.
Quand un superpeer reçoit une requête d'un voisin, il traite la requête sur la part du client au
lieu d la transmettre à lui. Pour traiter la requête pour ses clients, un superpeer laisse un
indexe sur les donnes des clients. Cet indexe doit prendre des informations suffisantes pour
répondre a toutes les requêtes. Par exemple si les données partagées sont des fichiers et les
requêtes sont des mots clefs recherchés sur le titre du fichier alors le superpeer doit laisser
une liste sur le titre des fichiers que le client possède.
Si le superpeer trouve un résultat, il retournera un message "Réponse". Ce message contient
des résultats et l'adresse de chaque client dont sa collection a produit un résultat.
Pour qu'un superpeer maintient cet index quand un client joint le système, il envoie une
donnée de sa collection au superpeer et le superpeer va ajouter les données du client dans son
indexe. Si un client met à jour ses données (insertion, effacement ou modification) il envoie
une mise a jour au superpeer aussi. Donc les réseaux superpeers introduisent deux actions de
base en plus que Query qui sont "join" et "update".
Quand un client veut soumettre une requête au réseau, il envoie la requête au superpeer
seulement. Le superpeer va soumettre ensuite les requêtes vers ses voisins comme si ces
requêtes étaient ses propres requêtes et de même envoie n'importe quelle Réponse qu'il reçoit
vers ce client. Au dehors d'un cluster une requête d'un client n'est pas distinguée des requêtes
du superpeer.
45
Nom
Graph type
Graph size
Cluster size
Redondance
Avg. Outdegree
TTL
Défaut
Power
10000
10
No
3.1
7
Query rate
9.26 .10-³
Update rate
1.85 .10-²
Description
Type de réseau
Nombre de peer dans le
réseau
Nombre de nœuds par cluster
Valeur booléenne
TTL du message query
Nombre de requête par
utilisateur par seconde
Nombre de mise à jour par
utilisateur par seconde
Figure 20. Paramètres de configuration et valeurs par défaut
Basé sur des études faites sur le réseau Gnutella
3.2.2 Rendez-vous superpeer (RDV):
Rendez-vous sont des peers qui se sont mis d'accord pour cacher les indexe d'annonces
(pointeurs vers les peers pour garder l'annonce correspondante). Le concept de rendez-vous
correspond à des endroits bien connus, utilises pour indexer et localiser l'annonce. La
politique par défaut d'un rendez-vous fournit l'infrastructure minimale pour amorcer d'une
façon efficace un ping de haut niveau pour l'annonce de haute recherche.
Figure 21. Rendez-vous Superpeer
Par exemple, à travers un rendez-vous, un peer peut trouver des peers suffisant pour amorcer
des politiques de recherches avancées. Des services de recherches avancés sont prévus de
fournir des mécanismes de recherche plus efficaces car ils peuvent avoir une meilleure
connaissance des contenus de la topologie.
46
L'infrastructure du rendez-vous peer par défaut fournit un mécanisme de découverte de bas
niveau pour découvrir les annonces, mais de l'autre cote fournit des crochets pour allouer des
services de découvertes de haut niveau pour participer au processus d'annonce de recherche.
Les peers de bordure maintiennent une relation spéciale avec leur rendez-vous peers,
n'importe quel peer peut devenir un rendez-vous peer s'il y a les bonnes qualifications.
Un rendez-vous juste maintient un indexe d'annonce publié par leur peer de bordure.
Ne pas garder les annonces fait de l'architecture rendez-vous plus "scalable" et réduit le
problème de laisser des annonces qui ne sont pas mis à jour.
Le service SRDI Shared Ressource Distributed Index est utilise par les peers de bordure
pour indexer leurs annonces sur le rendez-vous. Les peers de bordures utilisent SRDI pour
pousser les indexes d'annonces à leurs rendez-vous quand une nouvelle annonce est publiée.
Les indices peuvent être pousser d'une façon synchrone quand une nouvelle annonce est
publie, ou d'une façon asynchrone par le démon SRDI qui est lancé à des intervalles fixes.
La figure précédente, par exemple, montre comment les peers A et B sont entrain de pousser
leurs annonces vers leurs rendez-vous respectifs Rdv1 et Rdv2.
Quand une requête d'annonce est distribuée du peer A pour une annonce emmagasinée sur le
peer B, la requête est transmise au rendez-vous du peer A qui est Rdv1 (1). Rdv1 voit s'il a
un indexe de cette annonce, s'il ne trouve pas il propage la requête (2) au rendez-vous suivant
Rdv2.
Quand la requête arrive au Rdv2 il trouve l'indexe de l'annonce et l'avance vers le peer B (3).
Ceci est fait pour assurer que la dernière copie de l'annonce sur le peer B sera transmise au
peer A. Quand Peer B reçoit la requête il envoie une annonce au peer A (4).Il est important
de noter que n'importe quel peer indépendamment de sa position peut être un rendez-vous.
Dans la figure on voit que le peer 2, physiquement est derrière un NAT et il réagit comme un
rendez-vous.
3.3 ALAN (Architecture)
Monitor Interface
Execution Environment
for Proxylets (EEP)
Proxylet
Server
Protocol
Server
Proxylet
Gnutella Active Peer
Proxylet
Control
Interface
Superpeer
Gnutella Ctrl
Interface
Gnutella Mon.
Interface
Figure 22. ALAN
47
Peer
Peer
Le système est constitué de proxylets et de EEPs
Proxy let
¾ Applet ou Servlet aux extrémités d’une connexion
¾ Modules de code dynamique spécifiant la gestion de protocole
¾ Une seule copie mise au serveur central; identifiée par une référence
(URL)
EEPs
¾ Environnement d’exécution des proxylets; localisé à des points
stratégiques
¾ Proxylets de contrôle: load, run, modify, stop
¾ Déploiement dynamique
¾ Attend les requêtes pour démarrer les proxylets
¾ Routage, découverte et gestion des erreurs des proxylets
3.4 VAP Virtual Active Peer
AO L
AO L
A c tiv e V ir t u a lP e e r
AO L
N o rm a l P e e r
Figure 23. Exemple de topologie à Virtual Peer Actif.
3.4.1 Introduction
Le logiciel et les fonctions des réseaux actuels sont incorporés par les vendeurs dans les
noeuds du réseau à un temps donné; l'évolution et le changement de ces fonctions et du
logiciel sont à ce moment très complexe et les processus lents souvent exigent des années de
travail et de beaucoup de protocoles.
L'initiative récente de DARPA et les recherches des réseaux actifs, ont reconnu l'erreur
d'assortiment et ils cherchent à changer ceci en rendant programmables les noeuds du réseau.
Le réseau actif est l'un qui soutient le déploiement et l'exécution dynamique du logiciel de
réseau dans les noeuds intermédiaires. Ce logiciel, tels les nouveaux protocoles, le
monitoring du trafic et le filtrage du logiciel, ou la configuration des ressources, peuvent
exécuter le traitement actif sur les applications de données. Par exemple, avec un réseau actif
on pourrait déployer des protocoles efficaces originaux pour la téléphonie IP, ou déployer les
48
fonctions de Firewall dynamiquement afin de contrôler les changements de topologie dans un
réseau mobile.
L'Architecture Virtual Active Network (VAN) proposée est une architecture originale de
réseau actif virtuel qui fournit des caractéristiques qui sont nécessaires pour que les
applications prennent tout l'avantage des réseaux actifs.
Le but de (VAN) sera de rendre capable les grandes applications du réseau pour contrôler et
configurer la topologie du réseau et les ressources pour mieux soutenir leurs besoins. VAN
est particulièrement utile pour les applications qui exigent une des services suivants à être
fourni par le réseau
•La couverture de réseau d'un service
• La conscience d'emplacement du réseau
• Le soutien QoS spécialisé
• Disponibilité et fiabilité importante
• Sécurité
Par exemple, des applications cache du Web profiteront très fortement des services qui
fournissent la couverture d'un emplacement spécifique dans le réseau ; et les applications de
multi diffusion profiteront du soutien de QoS spécialisé. La disponibilité, la fiabilité et la
sécurité ont d'intérêts généraux à n'importe quelles applications dans le réseau.
L'architecture VAN définit des abstractions par lesquelles les applications peuvent spécifier
un réseau actif virtuel avec un type de service désiré, une caractéristique de topologie, une
contrainte de ressource et une contrainte de fiabilité. L'architecture VAN fournit des
algorithmes et des protocoles pour construction dynamiques d'un tel véritable réseau actif
selon la spécification de l'application. Quand les VAN multiples sont simultanément
construites d'une façon distributive, les potentiels 'deadlock' qui résultent des différentes
VAN concourant pour le noeud partagé et les liens entre les ressources, sont résolu par le
conflit de l'algorithme de résolution et du protocole de l'architecture VAN. A l'exécution,
l'architecture VAN contrôle la condition physique du réseau et adapte en conséquence à
mieux garde la VAN sémantique quand des échecs commencent, par exemple quand un lien
physique échoue.
Virtual Active Peer est une architecture de Middleware qui permet aux applications de
configurer la topologie du réseau et allouer les ressources aux nœuds et aux liens.
Active Virtual Peer
¾ Réseau actif
¾ Cœur de réseau ou bordure de domaine
¾ Informations et contrôle supplémentaires
Fonctionnalités
¾
¾
¾
¾
Restriction de la signalisation (par domaine)
Routage paramétré par l’état des liens
Redirection des requêtes de téléchargement
Implémente le contrôle et l’adaptation de la topologie
49
AA
EE
AA
AA
EE
AA
EE
VAN
OS
Node HW
Figure 24. Pile protocolaire
3.4.2 Architecture de AVP (Super peer):
Proxy let Active d’une application
Application Optimization Layer
Virtual Ctrl Cache
Network Optimization Layer
Figure 25. Architecture AVP 1
Application Optimisation Layer – AOL
¾ Proxy let: exécuté dans un EE
¾ Connexion à d’autre AOL
¾ Implante les fonctions de gestion
Virtual contrôle cache – VCC
¾ Capacité d’agrégation au niveau application
¾ Facilite la différentiation
¾ Gain de performance et économise les ressources
Network Optimisation Layer – NOL
¾ Mapping (optimale) du trafic P2P dans la couche réseau
¾ Assure une ingénierie de trafic « dynamique »
Figure 26. Déploiement de AVP
50
3.4.3 Gestion de AVP :
Active Proxy let
Optimization
LayerPerformance
Topology CtrlApplicationPolicy
Ctrl
Monitoring
Virtual Ctrl Cache
Network Optimization Layer
Figure 27. Architecture AVP 2
3.4.3.1 Le contrôle d’accès :
Création de domaines contrôlés à l’intérieur d’un système P2P
Contrôle d’accès aux peers et leurs ressources
Synthèse des messages
Figure 28. Gnutella vs réseau AVP
3.4.3.2 Routage :
Module de routage multi protocole
o Message AOL - AOL
o P2P protocole
o Routage entre les réseaux AVP
Protocole de routage avancé
o Décroître le trafic de signalisation
o Routage probabiliste
3.4.3.3 Topologie contrôle
Assurer une connexion stable avec d’autres EEPs
Termine une connexion
51
Distribution des annonces (Ping)
Etablir et détruire les connections basées sur les métriques :
Virtual Link State
Virtual Peer State
Figure 29. Contrôle de Topologie
3.4.3.4 Gestion de Ressources :
AVP produit des composants de VCC
Les requêtes des peers sont générer par l’AOL et envoyer au VCC
Les réponses des requêtes vont passer par le VCC
Figure 30. Gestion de ressources
3.4.4 Contribution
Mon point de vue :
Bien que les groupes (domaines) soient efficaces, un superpeer devient un unique point de
défaillance et d'échec pour le cluster et présente un potentiel goulot d'étranglement. Quand un
52
superpeer échoue ou simplement part du système, tous ses clients deviennent temporairement
déconnectés au moment où ils trouvent un superpeer pour se connecter à lui.
Dans le but de maximiser l'utilité du peer et d'augmenter sa stabilité et pour fournir une
fiabilité pour le cluster et de diminuer la charge sur le superpeer, je vais introduire ma
contribution concernant ce cas.
En effet on est entrain d'étudier un réseau peer to peer. Pourquoi ne pas garder l'idéologie des
systèmes peer to peer et au lieu de s'inspirer des systèmes client/serveur, qui sont en grande
différence avec les systèmes peer to peer, comme le tableau suivant nous rappelle, pourquoi
ne pas avoir un système où tous les peers peuvent agir, à un certain moment, comme
équivalent.
Peer-to-Peer
Client/Serveur
• Auto organisé
• Evolution dynamique, Ad hoc
• Découverte des peers
• Flux distribué (mesh)
• Symétrie du réseau
• Communication par Messages
• Adressage dynamique au niveau application
• Entités Autonomes
• Attaques difficiles (mobilité, anonymat)
• Management centralisé
• Configuré
• Consultation de tables
• Flux centralisé
• Asymétrie du réseau
• Orienté RPC
• Adressage statique @IP
• Entités dépendantes
• Attaques plus simples
La méthode que je propose est la suivante :
La supériorité au niveau des peers dans un certain groupe va être donnée au peer qui répond
le plus aux conditions du réseau. De la même façon peut être que le mode PIM Sparse utilisé
pour le routage dans Multicast, on peut spécifier peut être un «Join Spécifique » qui sera
généré par la station qui demande de prendre la supériorité et devenir Super peer.
Ainsi beaucoup de problèmes seront résolut ont :
-Allocation et découverte des ressources
-Réduire le trafic de synchronisation
-Agrégation et organisation
-Perte de la bande passante/latence/paquet
53
PARTIE 4. L’ IMPLEMENTATION
4.1 Création d’un service Web:
4.1.1 Environnement :
Le service Web peut être créer sur une machine Windows 2000 ou XP Professional, mais
dans les deux cas, le composant IIS (Internet Information Service) doit y être installé. En
effet, les applications Web ASP et les services Web XML exigent qu le IIS soit installe pour
le développement de ce type de projet.
4.1.2 Langage de programmation :
Notre service Web est développe avec le langage C# sur la plate-forme Microsoft .NET. Le
langage C# est orienté objet, ce qui facilite la manipulation des services Web XML. En effet,
il existe une classe System.Web.Services.WebService qui fournit un accès direct aux objets
ASP.NET. Lorsqu’un service Web est créé sur la plate-forme .NET, il hérite
automatiquement de cette classe.
Les propriétés de l’attribut du service Web :
•
•
•
Description : La valeur de cette propriété contient un message descriptif du service Web.
Name : La valeur de cette propriété contient le nom du service.
Namespace : Chaque service Web XML a besoin d’un unique Namespace.
Le Namespace va permettre aux clients de différencier entre les services Web qui
utilisent des fonctions de nom identiques.
4.1.3 Les fonctions Web (WebMethod) :
Lorsqu’on crée un service Web, celui-ci doit obligatoirement contenir des fonctions qui
peuvent être appelée à distance par des clients Web. Ces fonctions s’appellent WebMethod.
Dans le code C#, chacune de ces fonctions doit être déclarée avec l’attribut [WebMethod] qui
la précède.
4.1.4 Page d’aide du service Web :
Les services Web XML utilisent des fichiers d’exécutions .asmx qui peuvent être visualises
avec le web browser. Ces fichiers génèrent automatiquement une page du service Web
nomme Service1 .asmx qui fait partie du projet WebServer sur la machine locale, on utilise
l’url suivant : http://localhost/WebServer/Service1.asmx
Voici ce qu’on voit sue le Web browser :
54
Figure 31. Test 1
Cette page permet d’abord de tester que le service Web fonctionne. Ensuite, on peut
visualiser une description du service en question. Enfin, on peut accéder aux fonctions
proposées par ce service.
4.2 Fonctionnement global du réseau peer-to-peer centralisé
On a auparavant donne un aperçu sur ce type de réseau. On va maintenant expliquer son
fonctionnement plus en détail. Ce réseau doit contenir des machines appelées peers pouvant
échanger des fichiers. Il faut alors trouver une entité intermédiaire qui puisse simplifier la
recherche de fichiers sur le réseau et ceci d’une manière assez performante. C’est le rôle du
service Web. Nous allons d’abord présenter les fonctions Web du serveur.
4.2.1 Enregistrement d’un fichier sur le serveur :
Cette étape est indispensable pour le fonctionnement du système. Le peer doit pouvoir
partager un ou plusieurs fichiers sur le réseau .Il doit donc envoyer les informations
essentielles concernant le fichier à partager au serveur Web.
Ces informations sont :
•
•
•
L’adresse IP du propriétaire du fichier pour permettre aux autres peers de le retrouver sur
le réseau.
Le path pour accéder au fichier sur la machine du propriétaire.
Le nom du fichier.
55
• La taille du fichier en bytes.
Remarques :
•
•
•
L’adresse IP et le path doivent être transparents par rapport aux utilisateurs. Ce sont des
données uniquement utilisées par l’application.
On aurait pu ajouter un autre paramètre à ces quatre comme une description du fichier par
exemple.
Ces données sont effacées du serveur lorsque le peer est déconnecté.
Pour assurer le transfert de ces données, une fonction WebMethod doit être définie sur le
serveur. Cette fonction prend en paramètre ces quatre variables.
4.2.2 Page d’aide du service Web :
On a vu précédemment comment voir la page d’aide relative au service. Cette page contient
les fonctions Web de ce service. Si on clique sur l’une de ces fonctions, une nouvelle page
s’ouvre. Voici la page d’aide de la fonction qui enregistre un fichier.
Figure 32. Test 2
Cette page nous permet d’abord de s’assurer que la WebMethod fonctionne correctement.
Ensuite, om peut faire des tests en ajoutant manuellement des données au serveur.
On a vu comment on peut enregistrer un fichier sur le serveur. Maintenant il s’agit de
rechercher un fichier sur le serveur.
56
4.2.3 Recherche d’un fichier :
Le peer qui cherche un fichier précis doit tout simplement envoyer le nom de ce fichier au
serveur. Le serveur compare la chaîne de caractère qu’il a reçu avec les noms des fichiers
préenregistrés. Ensuite, le serveur renvoie au peer les informations sur tous les fichiers
correspondants à ce nom sous forme de tableau.
Il reste la dernière étape qui est en fin de compte l’essentiel. Il s’agit du téléchargement de
fichier. Notons que cette étape n’est pas une fonction du serveur. Le téléchargement concerne
seulement les peers.
4.2.4 Télécharger un fichier :
Apres que le peer ait reçu ce tableau, l’utilisateur peut choisir un fichier pour le télécharger.
Ici, on revient a la définition d’un peer qui est une entité jouant le rôle de client et de serveur
en même temps. Donc un peer, comme tout serveur, doit être continuellement en mode
d’écoute. Voici les étapes du téléchargement :
•
•
•
Le peer qui veut télécharger se connecte au peer propriétaire du fichier par une connexion
TCP/IP, comme tout client se connectant a un serveur.
Le peer « client » envoie au peer « serveur » le path du fichier pour qu’il sache de quel
fichier il s’agit.
Le peer « serveur » envoie au peer « client » le fichier.
4.3 Développement de l’application
L’application doit être présenté sur chaque peer. C’est une GUI (Graphic User Interface), elle
est programmée aussi en C# sur le Microsoft .NET. Le namespace utilise est
System.Windows.Forms qui contient des classes relatives a la construction de GUI. Voyons
d’abord comment cette application peut utiliser les services Web.
4.3.1 Création de références Web :
Pour simplifier le développement des applications clients des services Web, un concept de
références Web est introduit. Une référence Web est une classe proxy qui représente
localement les fonctionnalités d’un service Web. Lorsque l’application client crée une
instance de cette classe proxy, il est alors capable d’appeler les fonctions du service Web
comme s’il était un composant local. Par exemple, le client peut au sein de l’application,
appeler la fonction RegisterFile pour enregistrer un fichier sur le serveur.
4.3.2 Déroulement de l’application :
4.3.2.1 L’enregistrement de fichiers :
Nous avons vu que le peer doit fournir quatre paramètres pour l’enregistrement d’un fichier.
En réalité, l’utilisateur ne fournit qu’un seul paramètre qui est le path du fichier. L’adresse
IP, le nom et la taille du fichier sont directement pris en charge par l’application.
57
Figure 33. Test 3
4.3.2.2 Recherche et téléchargement :
Il existe une nouvelle page employée pour la recherche de fichiers. Lorsque le serveur
effectue la recherche, il envoie les données sous forme de tableau. Sur l’interface graphique,
seuls le nom et la taille du fichier sont visibles pour l’utilisateur. Celui-ci peut alors choisir le
fichier qu’il désire, et le télécharger. Ce fichier sera dans un répertoire nomme « p2p
download » crée dynamiquement par l’application.
Figure 34. Test 4
58
4.4 Monitoring avec WMI
Microsoft Windows Management Instrument (WMI) est à ce qu’on dit le grand secret de
Microsoft de gestion pour Windows. Qu’est-ce que cela implique? Si vous gérez des serveurs
et des postes de travail Windows ou si vous des applications de gestion Windows, il est
indispensable de connaître WMI.
4.4.1 Qu’est-ce que WMI ?
Lance a l’origine en 1998 comme composant additionnel de Windows NT 4.0 Service Pack
4, WMI est la technologie centrale de gestion intégrée a la gramme Windows 2000, Windows
XP et produits Windows Server System. Basée sur des WMI regroupe les instruments et la
plomberie via lesquels toutes –ou quasiment toutes- les ressources Windows peuvent faire
l’objet d’un accès et être configurées, gérées et surveillées.
Avant WMI, tous les outils administratifs graphiques de Windows s’appuyaient sur des
interfaces de programmation d’applications (API) Win32 pour accéder aux ressources
Windows et les gérer. Pourquoi ? Parce que la seule manière d’accéder aux ressources
Windows par programmation avant Wmi était par l’intermédiaire des API Win32. Cette
situation ne mettait a la disposition des administrateurs de systèmes Windows aucune
manière rapide d’automatiser les taches courantes d’administration des systèmes en utilisant
les langages de script courant, car la plupart de ces langages ne pouvaient pas appeler
directement les API Win32.WMI change cela en proposant un modèle et une infrastructure
homogènes via lesquels toutes les ressources Windows sont décrites et exposées au monde
extérieur. De plus les administrateurs système peuvent utiliser la bibliothèque de scripts
WMI pour créer des scripts d’administration de systèmes afin de gérer n’importe quelle
ressource Windows exposée via WMI.
En utilisant Windows Script Host et Microsoft Visuel Basic Sripting Edition (VBScript), on
peut écrire des scripts pour gérer et automatiser les aspects suivants des systèmes,
applications et réseaux d’entreprise :
•
Gestion des produits Windows Server System, Windows XP Professional et
Windows 2000. On peut écrire des scripts pour extraire des données de performance,
gérer des journaux d’évènements, des systèmes de fichiers, des imprimantes, des
processus, des paramètres de bases de registres, un planificateur, la sécurité, les services,
les partages et de nombreux autres composants et paramètres de configuration du système
d’exploitation.
•
Gestion des réseaux. On peut créer des scripts bases sur WMI pour gérer des services de
réseau tels que les services DNS, DHCP et SNMP compatibles.
•
Surveillance en temps réel de l’état de santé. A l’aide des abonnements aux
évènements WMI, on peut écrire des scripts pour surveiller et réagir en temps réel aux
entrées du journal d’évènements, aux modifications des systèmes de fichiers et des bases
de registres et à d’autres modifications en temps réel subies par le système d’exploitation.
Du point de vue conceptuel, les abonnements aux évènements et notifications
59
d’évènements de WMI sont a WMI ce que les interruptions SNMP sont au monde du
SNMP.
•
Gestion des produis Windows Server System. On peut écrire des scripts pour gérer
Microsoft® Application Center, Opération Manager, Systems Management Server,
Internet Information Server, Exchange Server et SQL Server.
4.4.2 Architecture de WMI :
L’architecture de WMI comprend trois couches principales, comme illustre dans la figure cidessous :
•
•
•
Ressources gérées
Infrastructure de WMI
Consommateurs
4.4.2.1 Ressources gérées :
Une ressource gérée est tout composant logique ou physique, exposé et gérable en utilisant
WMI. Les ressources Windows pouvant être gérées a l’aide de WMI incluent le système
informatique, les disques, les périphériques, les journaux d’évènements, les fichiers, les
dossiers, les système d’exploitation, les compteurs de performance, les imprimantes, les
processus, les paramètres de base de registres, la sécurité, les services, les partages, les
utilisateurs et les groupes SAM, active Directory, Windows Instaler, les pilotes de
périphériques Windows Driver Model (WDM) et les données SNMP Management
Information Base (MIB). Une ressource gérée par WMI communique avec WMI via un
fournisseur.
4.4.2.2 Infrastructure de WMI :
La couche intermédiaire est l’infrastructure de WMI. WMI comprend trois composants
principaux : le Common Information Model Object Manager (CIMOM), le référentiel
Common Information Model (CIM) et les fournisseurs.
Ensemble, ces trois composants fournissent l’infrastructure via laquelle sont définies,
exposées, atteintes et extraites les données de configuration et de gestion. Un quatrième
composant, même s’il est petit mais absolument essentiel aux scripts, est la bibliothèque de
scripts de WMI.
4.4.2.3 Consommateurs WMI :
Les consommateurs constituent la couche supérieure. Un consommateur est un script, une
application de gestion d’entreprise, une application basée sur le Web ou un autre outil
administratif qui accède et contrôle les informations de gestion disponibles via
l’infrastructure de WMI.
On ne va pas rentrer plus en détail dans le fonctionnement de WMI, on va plutôt s’intéresser
à notre application de monitoring, notamment le monitoring des services web.
60
4.4.3 L’application de gestion
Figure 35. Test5
L’application que j’ai développé est une simple application développée sous C#, comme on
peut voir dans le menu de contrôle, on peut spécifier le nom de la machine sur le réseau dont
on veut contrôler même les compteurs nous laisse voir n’importe quel paramètre qui nous
parait important.
A chaque fois qu’un chargement sera complété, on peut choisir le paramètre à gérer selon son
type. Des qu’on choisi un paramètre a contrôler un graphe sera visible qui nous montre l’état
de ce compteur. On peut arrêter ou faire marche le graphe au moment ou l’on veut, ainsi
qu’on peut voir plusieurs graphes en même temps ainsi qu’on peut avoir plusieurs fenêtres
dont chacune peut comporter plusieurs graphes en même temps.
Le développement d’applications utilisant WMI peut être très simple, et se révèle très
fructueux quant a l’importance des informations qu’il pourrait nous procurer. Dans notre cas,
on fait un monitoring sur presque tous les paramètres de notre machine et même des
machines voisines, en WMI ; ceci pourrait donner plusieurs idées, comme utiliser le
monitoring sous des services Web, c’est adire de mettre des fonctions faisant le monitoring
en tant que Web Methods accessible depuis les clients. Ceci permettrait d’avoir plus
d’interactivité entre les clients et le service web.
61
PARTIE 5. CONCLUSION
En guise de conclusion, je voudrais seulement mentionner que cette proposition m’a
fourni beaucoup d’information et d’expérience, surtout que les thèmes de réseau actif et de
peer to peer attirent plus d’attention dans la communauté de réseau à nos jours.
Les systèmes peer to peer sont récemment devenus des moyens très populaires à
travers lesquels un très grand nombre de données sont partagés.
Les réseaux actifs eux déjà bien connus et déterminés, mais leur implémentation pose
plusieurs défis. Leurs performances doivent être comparable à celle des réseaux existants.
Ainsi qu’ils doivent offrir au moins la même sécurité et la même robustesse, ce qui est un
grand défi quand le code peut migrer et s’exécuter dans un grand réseau hétérogène.
La proposition d’architecture de réseau actif pour le déploiement et la gestion d’un
réseau p2p est bien placée, malgré que plusieurs autres questions puissent avoir lieu comme :
au lieu d’appliquer un certain mécanisme comme proposé « join spécifique » : Quel sera
l’effet de la redondance sur de telles architectures ? Est-ce qu’elle sera bien supportée ?
62
Bibliographie:
Réseaux P2P:
-Aberer, K. and Hauswirth, M., Peer-to-Peer informations systems: concepts and models,
state-of-the-art, and future systems, Tutorial 2002.
-Wireless/Networking: Introduction to P2P Networks.
-Minar, N. and Hedlund, M.; A Network of Peers; P2P: Harnessing the power of a disruptive
technologie; Oral; Mar. 2001.
-Les protocoles P2P et leurs utilisations, Guillaume Doyen, Feltin, Festor-Loria.
-Napster messages, open-nap-source forge/ Napster.txt.
-Gestion de reseaux Pairs a Paires, Exposé d'avancement de thèse, Doyen-Loria.
-Project JXTA: Java Programmer Guide; Sun Microsystems, Inc; 2001.
-Management of p2p networks applied to IM, Nataf, Doyen, and Futor.
-RRS Design Document – implementation details clip2.
-Satinel – p2p based networks systems & applications monitoring.
-The Gnutella Protocol specification v0.4; Jun. 2001.
-Managed P2P – A new architecture for Service Management-Stephenson-2002.
Disruption P2P VoIp Tech.
-Designing a Super-Peer Network, by Yang-Molina.
-Project JXTA 2.0 Super Peer Virtual Network, Traversat – Duigou 2003.
Réseaux Actifs :
-Active Networks: Applications, Security, Safety and Architecture-Psounis.
-Active Virtual Network Management Prediction-Bush.
-An Active Network Management Architecture using XML-based MIB-Lee, Hong.
-ALAN Programming Manual-Fry, Ghosh.
-Milojicic, D. and Kalogeraki, V. and Lukose, R. and Nagaraja, K. and Pruyne, J. Richard,
B. and Rollins, S. and Xu, Z., Peer-to-Peer Computing, HP Laboratories Research Report,
HPL-2002-57, March 2002.
Les sites Webs:
www.hpl.hp.com/techreports/2002/HP-2002-57.pdf
www.sourceforge.net/projets/rfc-gnutella
www.smartmobs.com
www.techdictwireless.com
www.geckzone.co.nz
www.skype.com
www.numapps.org
www.clips2.com
http://www.prism.uvsq.fr/~tad/rapport/ants.html
http://www.rennes.enst-bretagne.fr/RHDM99/reseauxactifs.pdf
http://www.inria.fr/rrrt/rt-0270.html
http://www.cpmsoc.org/pubs/surveys/1q99issue/psounis.html
http://www-rp.lip6.fr/euronetlab/actnet.html
63