Systèmes Multiagents Distribués Et Systèmes Distribués Multiagents - Thèse Gilles Klein

U.F.
R des Sciences des Organisations

Université
Paris IX École doctorale EDDIMO
Dauphine
Systèmes Multiagents Distribués et

Systèmes Distribués Multiagents
THÈSE
présentée et soutenue publiquement le 27 Mai 2005
pour l’obtention du
Doctorat de l’Université Paris IX Dauphine

(spécialité informatique)
par
Gilles Klein
Composition du jury
Directeur : Madame Amal El Fallah-Seghrouchni

Professeur à l’Université Paris X - Nanterre
Rapporteurs : Monsieur Jean-Pierre Briot
Directeur de Recherche, CNRS
Madame Salima Hassas
Maı̂tre de Conférences à l’université Lyon I,
Habilitée à diriger des recherches
Examinateurs : Monsieur Richard Emilion
Professeur à l’Université d’Orléans
Madame Suzanne Pinson
Professeur à l’Université Paris-Dauphine
Monsieur Pierre Sens
Professeur à l’Université Paris VI
Invités : Monsieur Patrick Taillibert
Ingénieur de Recherche, THALES
Laboratoire d’Analyse et Modélisation de Systèmes pour l’Aide à la Décision UMR 7024

Mis en page avec la classe thloria.
Table des matières
Table des figures vii
Partie I Plan détaillé et Introduction 1
Chapitre 1
Plan détaillé
Chapitre 2
Introduction
Partie II Systèmes multi-agents et informatique partagée : un

état de l’art 13
Chapitre 1
Technologies de partage de ressources informatiques
1.1 Architectures issues des systèmes distribuées . . . . . . . . . . . . . . . 15

1.1.1 Les solutions de distribution de charge . . . . . . . . . . . . . . 15
1.1.2 Les systèmes de type “cluster” . . . . . . . . . . . . . . . . . . . 25
1.1.3 Grid programming et systèmes peer to peer . . . . . . . . . . . 29
1.2 Architectures agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.2.1 Les agents et les SMA . . . . . . . . . . . . . . . . . . . . . . . 41
1.2.2 quelques applications caractéristiques des SMA . . . . . . . . . 44
1.2.3 Le code mobile et les agents mobiles . . . . . . . . . . . . . . . 46
1.2.4 Architectures de partage basées sur des technologies agents . . . 51
i
Table des matières
Chapitre 2
Méthodes de conception orientées agents
2.1 Interactions, communications . . . . . . . . . . . . . . . . . . . . . . . . 53

2.2 Conception de systèmes multiagents . . . . . . . . . . . . . . . . . . . 54
2.3 Les méthodes de conceptions de SMA “classiques” orientées agents ou
rôles et leurs limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.4 Programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Chapitre 3
Méthodes de représentations
3.1 Les réseaux sémantiques : . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2 Les réseaux de Petri et leurs extensions, les réseaux de Petri récursifs
et colorés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.1 Les réseaux de Petri colorés . . . . . . . . . . . . . . . . . . . . 61
3.2.2 Les réseaux de Petri récursifs . . . . . . . . . . . . . . . . . . . 61
3.3 Les treillis de Galois . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.1 Description des treillis de Galois (Concept lattices) tels qu’ils
sont utilisés pour la représentation de connaissances . . . . . . . 64
3.3.2 Notre utilisation des treillis de Galois . . . . . . . . . . . . . . . 66
Partie III Méthodologie de conception de systèmes multia-

gents orientée vers une répartition efficace des charges : HA-
MAC et ASMAA 67
Chapitre 1
Pourquoi une nouvelle méthode de conception de systèmes multia-
gents ?
Chapitre 2
Notre méthode de conception de SMA et ses hypothèses d’application
2.1 Une présentation rapide de notre méthode de conception de SMA . . . 71

2.1.1 Une méthode de conception globale . . . . . . . . . . . . . . . . 71
2.1.2 Présentation des différentes étapes . . . . . . . . . . . . . . . . 71
ii
2.2 Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.3 Une rapide présentation de DOGS multiagent . . . . . . . . . . . . . . 74
Chapitre 3
La phase statique de notre méthode de construction de systèmes mul-
tiagents : HAMAC
3.1 Un résumé rapide de la partie statique de notre méthode : HAMAC . . 77

3.2 Le processus d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.2.1 Analyse des tâches et des processus . . . . . . . . . . . . . . . . 78
3.2.2 Analyse des moyens de l’utilisateur . . . . . . . . . . . . . . . . 81
3.2.3 Analyse des composants recyclables . . . . . . . . . . . . . . . . 81
3.2.4 Analyse des communications externes . . . . . . . . . . . . . . . 83
3.3 Processus de conception de la société du système multiagent . . . . . . 83
3.3.1 Conception des agents . . . . . . . . . . . . . . . . . . . . . . . 85
3.3.2 Description des interactions . . . . . . . . . . . . . . . . . . . . 86
3.3.3 Modélisation des agents . . . . . . . . . . . . . . . . . . . . . . 86
3.3.4 Construction du modèle du système multiagent et description
des interactions entre les agents . . . . . . . . . . . . . . . . . . 90
3.4 La distribution physique des agents . . . . . . . . . . . . . . . . . . . . 96
3.4.1 Placement des agents . . . . . . . . . . . . . . . . . . . . . . . . 96
3.4.2 L’expérience de DOGS . . . . . . . . . . . . . . . . . . . . . . . 96
3.5 Conception et implantation des protocoles d’interaction et de commu-
nication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.5.1 Les interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
3.5.2 Les communications . . . . . . . . . . . . . . . . . . . . . . . . 98
Chapitre 4
La phase de redistribution dynamique de la répartition : ASMAA
4.1 Redistribution dynamique des charges : introduction de la mobilité . . 101

4.1.1 La distribution physique des agents . . . . . . . . . . . . . . . . 102
4.1.2 La décision de migration . . . . . . . . . . . . . . . . . . . . . . 102
4.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
iii
Table des matières
Chapitre 5
Un modèle d’agent centré autour de la distribution des charges et des
communications
Chapitre 6
Résultats obtenus
6.1 L’architecture des premières versions d’Arès . . . . . . . . . . . . . . . 111

6.2 Le réseau de bibliothèques virtuelles . . . . . . . . . . . . . . . . . . . 111
6.2.1 Notre application : un réseau de bibliothèques virtuelles . . . . 111
6.2.2 Conception de cette application . . . . . . . . . . . . . . . . . . 112
6.2.3 L’architecture CLAIM de notre application . . . . . . . . . . . 115
6.2.4 Les tests et les résultats obtenus . . . . . . . . . . . . . . . . . 116
6.2.5 Conclusion et perspectives . . . . . . . . . . . . . . . . . . . . . 118
Partie IV Notre système de partage de ressources 121
Chapitre 1
Introduction
1.1 De ASMAA vers un outil de partage de ressources informatiques . . . . 123

1.2 Un outil de partage de ressources informatiques . . . . . . . . . . . . . 124
Chapitre 2
Quelle clientèle pour un système de partage
2.1 Les communautés d’utilisateurs . . . . . . . . . . . . . . . . . . . . . . 127

2.2 Les différents types de communautés et leurs spécificités . . . . . . . . 128
2.2.1 Utilisation au sein d’une société . . . . . . . . . . . . . . . . . . 129
2.2.2 Utilisation au sein d’une communauté d’abonnés . . . . . . . . 129
2.2.3 Utilisation au sein d’une communauté liée par un intérêt scien-
tifique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
2.2.4 Utilisation au sein d’un groupe d’utilisateurs d’un jeu vidéo
multi joueurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Chapitre 3
Description des ressources partagées
iv
3.1 Description du système physique . . . . . . . . . . . . . . . . . . . . . 133
3.1.1 Les ressources informatiques . . . . . . . . . . . . . . . . . . . . 133
3.1.2 Le réseau de communications . . . . . . . . . . . . . . . . . . . 134
3.2 Description du système logiciel . . . . . . . . . . . . . . . . . . . . . . 135
3.3 Description des prérogatives des différents agents . . . . . . . . . . . . 137
3.3.1 Le Manager de machine . . . . . . . . . . . . . . . . . . . . . . 137
3.3.2 Les agents Tâches . . . . . . . . . . . . . . . . . . . . . . . . . 138
3.3.3 Les agents Sniffers . . . . . . . . . . . . . . . . . . . . . . . . . 140
Chapitre 4
Problèmes posés par un système de partage
4.1 Capacité d’un agent à juger de la qualité des services . . . . . . . . . . 143

4.2 Capacité d’un agent processus à évaluer et à prédire ses besoins . . . . 144
4.3 Capacité des hôtes à juger de la pertinence des accointances qui lui
sont proposées (ou qu’elle applique en ce moment). . . . . . . . . . . . 144
4.4 Gestion de l’hétérogénéité des hôtes . . . . . . . . . . . . . . . . . . . . 145
4.5 Gestion des priorités . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.6 Les données réutilisables . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Chapitre 5
Description du fonctionnement de la plateforme et état d’avancement
du prototypage
5.1 Les agents Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

5.1.1 Juger un ordinateur par rapport à un besoin spécifique . . . . . 148
5.1.2 Le système d’agglomération des valeurs . . . . . . . . . . . . . . 151
5.1.3 Les autres fonctionnalités de l’agent Manager . . . . . . . . . . 153
5.2 Les agents Sniffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.2.1 Description des agents Sniffers . . . . . . . . . . . . . . . . . . 153
5.2.2 Représentation des préférences en utilisant des treillis de Galois 154
5.2.3 Justification des Sniffers par rapport à une solution par envoi
de message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.3 Les agents Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
5.4 Quelques questions de sécurité . . . . . . . . . . . . . . . . . . . . . . . 157
5.4.1 Les droits des agents . . . . . . . . . . . . . . . . . . . . . . . . 157
5.4.2 Informations accessibles et droits des Sniffers . . . . . . . . . . 158
v
Table des matières
Chapitre 6
Les tests et les résultats obtenus
6.1 Le prototype de plateforme . . . . . . . . . . . . . . . . . . . . . . . . 161

6.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
6.1.2 Présentation des tests et résultats . . . . . . . . . . . . . . . . . 161
6.1.3 Expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.1.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.2 Validation du fonctionnement du module de choix des Managers . . . . 166
6.2.1 Implantation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
6.2.2 Difficultés des tests . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.2.3 Génération des descriptions . . . . . . . . . . . . . . . . . . . . 167
6.2.4 Les différents types d’ordinateurs sélectionnés . . . . . . . . . . 167
6.2.5 Les résultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . 169
6.3 Quelques données probabilistes concernant notre système . . . . . . . . 171
6.3.1 Construction de l’architecture de partage . . . . . . . . . . . . . 172
6.3.2 Estimation d’une requête . . . . . . . . . . . . . . . . . . . . . 173
6.3.3 Propagation de l’information concernant les variations des sites 174
Partie V Conclusion 175
Bibliographie 179
vi
Table des figures
1.1 Un exemple de réseau, les carrés sont des routeurs, les points des sites
informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Exemples d’architectures classiques . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Un exemple d’architecture hiérarchique . . . . . . . . . . . . . . . . . . . . 20
1.4 Un exemple de “super cluster” de clusters . . . . . . . . . . . . . . . . . . . 30
1.5 Architecture de Napster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.6 Représentations de deux protocoles de Gnutella : l’arrivée d’un nouveau
client et une recherche de fichier . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7 Extrait de l’article cité ci-dessus, une schématisation de l’architecture de
Chord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.8 Un exemple de clônage faible d’un objet O de classe C . . . . . . . . . . . 47
1.9 Un exemple de migration faible d’un objet O d’une classe C . . . . . . . . 49
2.1 Méthode de conception et implémentation de SMA . . . . . . . . . . . . . 72
3.1 Exemple d’analyse des tâches réalisée en utilisant des réseaux de Petri
récursifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.2 Comment distribuer les tâches en fonction du réseau de Petri . . . . . . . . 84
3.3 Exemple de distribution de tâches entre deux types d’agents . . . . . . . . 88
3.4 Un modèle de communication entre agents à base de réseaux de Petri . . . 90
4.1 Architecture de plate-forme conforme à MASIF [MAS] . . . . . . . . . . . 103

4.2 Prise de décision de migration . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.1 Notre modèle d’agent “le danseur de Maccarena” . . . . . . . . . . . . . . . 108
6.1 Représentation du processus de recherche et d’emprunt d’un ouvrage et de

la gestion de la bibliothèque dans son ensemble . . . . . . . . . . . . . . . 113
6.2 Architecture de la plateforme SyMPA . . . . . . . . . . . . . . . . . . . . . 115
6.3 Architecture d’une bibliothèque distribuée . . . . . . . . . . . . . . . . . . 117
6.4 Temps d’attente des agents dans la première section de la bibliothèque en
fonction de l’architecture (différentes courbes) et du nombre d’agents présents118
6.5 Temps d’attente dans les différentes sections selon le type de test réalisé . . 119
3.1 Un exemple de “réseau câblé routé” . . . . . . . . . . . . . . . . . . . . . . 135
5.1 Un exemple de représentation de préférences par treillis de Gallois . . . . . 155
vii
Table des figures
6.1 L’architecture de SyMPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

6.2 L’architecture de la plateforme de test . . . . . . . . . . . . . . . . . . . . 165
6.3 résultats des tests de la plateforme . . . . . . . . . . . . . . . . . . . . . . 166
6.4 Description d’ordinateur destiné à faire des calculs lourds . . . . . . . . . . 168
6.5 Description d’ordinateur destiné à servir de “serveur” à un cluster d’ordi-
nateurs semblables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
6.6 description d’ordinateur semblable à “mon PC personnel” . . . . . . . . . . 169
6.7 Description d’ordinateur destiné à service de point de départ pour la re-
cherche spécifique d’autres ordinateurs spécialisés . . . . . . . . . . . . . . 170
6.8 Résultats des tests de la plateforme pour 100 simulations . . . . . . . . . . 170
6.9 Résultats des tests de la plateforme pour 1000 simulations . . . . . . . . . 171
viii
Première partie
Plan détaillé et Introduction
1
Chapitre 1
Plan détaillé
Introduction/justification
La croissance de la puissance des machines s’arrête lorsque les réseaux de-
viennent plus puissants que les individus.
Répartition de la puissance
La puissance de calcul n’est aujourd’hui plus le fait des superordinateurs centralisés. Il
y a 30 ans 70 % de la puissance de calcul était le fait de gros systèmes. Aujourd’hui la
multiplication des ordinateurs personnels rend la puissance de calcul de la catégorie des
superordinateurs négligeable. En fait, la majorité de la puissance de calcul actuelle est
comprise dans les cartes à puces qui sont infiniment moins puissantes que les ordinateurs
mais infiniment plus nombreuses.
La plupart des ordinateurs sont largement sous-utilisés (d’après [FPR95] et [TL89],
le taux d’occupation des processeurs oscille entre 32 et 93 %) et la plupart de ceux qui
sont poussés jusqu’à leurs limites ne le sont en fait que quelques heures par jour au plus.
Croissance des besoins

Lors de la création des premiers PC, IBM et Microsoft considéraient que les utilisateurs
d’ordinateurs personnels n’auraient jamais besoin de plus de 640 Ko de mémoire vive.
Aujourd’hui, il vaut mieux avoir 512 Mo pour pouvoir utiliser sereinement le dernier
système d’exploitation de la marque citée ci-dessus. Les applications sont devenues de plus
en plus exigeantes. En fait, on découvre que le besoin naît des moyens et non l’inverse.
Toutes les fonctions industrielles deviennent de plus en plus exigeantes.
Même les ordinateurs les plus puissants ne sont plus suffisants pour gérer certaines
applications (cas Volkswagen ou SETI). De nouveaux types de besoins sont apparus au
cours des cinq dernières années :
– Jeux vidéo en réseaux (dits massivement multi joueurs)
– Commerce électronique et partage d’information au sein d’entreprises virtuelles
Conclusion
Les deux paragraphes précédents mettent en avant un paradoxe : la puissance de calcul
du parc informatique planétaire est sous-employée et en même temps, la plupart des
3
Chapitre 1. Plan détaillé
utilisateurs souffrent régulièrement de la surcharge de leur système informatique. Cela

nous amène à notre conclusion : il faudrait pouvoir proposer un système de partage
des ressources informatiques au sein de communautés d’utilisateurs (qu’elles soient des
groupes de particuliers ou des entreprises voire des groupes mixtes).
Ainsi,
la première partie de ce travail, l’état de l’art présente l’environnement scientifique qui
enveloppe nos travaux. Il traite donc de plusieurs sujets (parfois très différents), puisqu’il
faut rendre compte des différentes avancées dans les différents domaines auxquels touche
ce travail. L’état de l’art est composé de deux parties fondamentalement distinctes :
– L’état de l’art en matière d’outils de partage et de distribution de charge, qui nous
permet d’éclairer l’environnement scientifique et l’intérêt de ce travail. Après quoi,
nous présentons l’état d’avancement des méthodes de conception de systèmes muli-
tagents.
– Le deuxième chapitre de cette partie présente l’état de l’art dans différents domaines
non pas directement liés à notre propos mais aux outils que nous utilisons pour
surmonter les différentes difficultés présentées par notre travail.
Technologies de partage de ressources informatiques

Dans ce premier chapitre, nous présentons le contexte de notre travail, c’est-à-dire les
systèmes distribués et les systèmes de partage.
1. Technologies de partage issues des systèmes distribués
Dans cette partie, nous présentons les technologies de partage de ressources infor-
matiques. Nous nous concentrons surtout sur les technologies permettant la dis-
tribution d’applications informatiques sur un parc d’ordinateurs, cependant nous
traitons aussi des systèmes de partages de fichiers “peer-to-peer” puisque ce sont en
pratique les seuls systèmes réellement destinés à “partager” des ressources entre des
utilisateurs mal connus, alors que les systèmes de partage de puissance sont plutôt
destinés à optimiser l’occupation d’un parc d’ordinateurs connus ; les problématiques
sont donc assez dissemblables.
– Les solutions de distribution de charge
Dans cette section, nous présentons rapidement les différentes solutions de distri-
bution de charge, “load-balancing” statique et dynamique, centralisé ou distribué,
etc.
– Les systèmes de type clusters
Dans cette section, nous présentons le fonctionnement des “clusters” d’ordinateurs,
les buts, les principes de fonctionnement et différents exemples de ce type de
technologie.
– “Grid-programming” et systèmes “peer-to-peer”
Après avoir décrit les clusters, nous décrivons les systèmes distribués à “grande
échelle” (grid-computing), qui utilisent des outils issus des clusters pour construire
des systèmes largement distribués. Après quoi, nous nous intéresserons aux sys-
tèmes de partage de données peer-to-peer qui se différencient par leur approche,
ce sont des outils de partage de fichiers entre utilisateurs mais aussi par leur
ouverture.
4
Comme l’un de nos buts était de construire un système de partage de ressources
entre utilisateurs, il est tout à fait logique de s’intéresser aux seuls vrais outils de
partage à grande échelle utilisés à l’heure actuelle.
2. Architectures agents Dans cette section, nous nous intéressons aux systèmes de dis-
tribution de charges utilisant des technologies agents. C’est un point intéressant
puisque les SMA sont “naturellement distribués”. Cependant, construire des “sys-
tèmes agents” distribués présente des spécificités. Pour pouvoir présenter ces outils,
nous devons nous arrêter sur les Systèmes Multiagents et sur diverses technologies
qui leurs sont associées.
– Les Agents et les SMA
Dans cette partie, nous décrivons les agents informatiques et les systèmes multia-
gents.
– Quelques applications caractéristiques des SMA
Nous présentons plusieurs visions des SMA, puisque selon les applications, un
système multiagent peut être un outil de résolution de problèmes distribué (mais
aussi un outil de résolution de problèmes distribués. . . ), une “plateforme de ren-
contres”.
– Le code et les agents mobiles
Nous présentons ensuite rapidement les technologies de code mobile, les principes
de la mobilité, le clonage faible, la mobilité faible, la mobilité forte. Après quoi,
nous présentons les applications de la mobilité aux technologies agents sous la
forme des systèmes d’agents mobiles.
– Architectures de partage basées sur les technologies agents
Nous présentons, ici, quelques utilisations des SMA dans le domaine des outils de
partage de ressource.
M
éthodes de conception orientées agents Dans ce chapitre, nous présentons les méthodes
de conception de systèmes multiagents (SMA). Cette présentation se trouve dans cette
section pour des raisons car, dans la deuxième partie, nous présentons une méthode de
conception de SMA. Cependant, son contenu s’appuie sur la présentation des technologies
agents qui se trouve dans la section Outils.
Cette section se sépare en trois sous-sections :
– La description des interactions et des communications,
– La description des différentes méthodes de conception de SMA classiques ainsi que
la mise en exergue de leurs limites,
– Les spécificités de la programmation et de l’implantation des SMA.
Méthodes de représentation
Dans ce chapitre, nous présentons différentes méthodes de représentations . . . de don-

nées, de préférences, de processus, etc. que nous avons utilisées ou dont nous nous sommes
inspirés pour construire nos différents systèmes. Nous nous arrêterons sur les différents
types de réseaux sémantiques, les réseaux de Petri (RdP), puis sur leurs extensions, les
RdP récursifs et les RdP colorés. Enfin, nous présenterons les treillis de Galois.
5
La conception de systèmes multiagents distribués : HAMAC et ASMAA

Cette partie contient une extension de l’état de l’art, cependant, ses buts divergent de ceux
de la première partie, puisqu’il nous permet en fait d’introduire les questions auxquelles,
selon nous, une méthode de conception de SMA doit répondre.
Dans cette partie, nous décrirons :
– HAMAC notre méthode de conception de systèmes distribués, ses spécificités, les
différentes étapes qui la composent, ses buts et ses limites actuelles. HAMAC est
une méthode de construction de SMA (plutôt qu’une méthode de conception) en ce
qu’elle prend en compte toutes les phases de la construction d’une application, de
sa conception abstraite jusqu’à son déploiement. En cela, elle diffère des méthodes
de conception comme GAIA par exemple.
– son extension destinée à permettre la redistribution des agents au cours de l’exé-
cution ASMAA qui utilise les technologies d’agents mobiles et les architectures
classiques des outils d’équilibrage de charge pour permettre de répondre au mieux
aux spécificité des applications agents.
– Nous présenterons aussi, rapidement, ARES qui est une plateforme multiagent
que nous avons conçue pour permettre la construction de systèmes multiagents
distribués.
– Nous finirons en présentant le projet DOGS multiagent de THALES sur lequel
s’est construit notre méthode. DOGS nous servira d’exemple pour éclairer le fonc-
tionnement et les différentes étapes de HAMAC tout au long de la présentation
de la méthode de conception de systèmes.
– Enfin, nous présenterons notre réseau de bibliothèques virtuelles, notre dernière
application construite en utilisant HAMAC et ASMAA.
Un système de partage à grande échelle basé sur les agents mobiles

Dans cette partie, nous décrivons notre système de partage de ressources informatiques
à grande échelle. Pour construire notre application, nous avons utilisé une architecture à
base d’agents, certains mobiles, d’autres non. Cette partie s’articule autour des buts, des
hypothèses, de l’architecture de notre plateforme de partage. Après quoi, nous présentons
les résultats obtenus lors des différents tests réalisés.
Quelle clientèle pour un système de partage

Le partage de ressources se fait nécessairement au sein d’un groupe d’individus. Ici les
individus concernés sont des propriétaires (ou au moins des utilisateurs) de ressources
informatiques. On appelle ce groupe d’utilisateurs “communauté d’utilisateurs”. Les diffé-
rentes hypothèses du partage dépendent largement du type de communautés concernées.
En effet, “prêter” son ordinateur peut être quelque chose de dangereux, selon les critères
de sélection qu’il faut remplir pour être membre de la communauté de partage.
Parce que la nature de la communauté de partage et les hypothèses qui en découlent
sont primordiales pour le fonctionnement d’un système de partage, nous devons nous
arrêter à la fois sur ce qu’est une communauté et sur les différents types de communautés
que nous pouvons envisager comme utilisateurs d’un système de partage.
6
La deuxième hypothèse primordiale pour la définition d’un système de partage est la
nature des produits partagés (on ne partage pas un gâteau et un jouet de la même fa-
çon), nous devons donc décrire les ressources que nous comptons partager car c’est une
hypothèse fondamentale du fonctionnement d’une plateforme de partage.
De ces hypothèses, nous allons déduire une esquisse de l’architecture de notre système,
puis les différentes caractéristiques des différents agents que nous concevons pour remplir
les différentes tâches nécessaires au bon fonctionnement de la plateforme (qui a été conçue
en suivant un processus similaire à celui décrit dans la partie 2, même si la nature de
l’application ne rentrait pas dans les hypothèses de la partie 2).
Problèmes posés par un système de partage

Dans cette section, nous décrivons les différentes difficultés qu’entraîne la construction
d’une plateforme répondant aux hypothèses ci-dessus.
– Capacité des agents à décider eux-mêmes à trouver les ressources dont ils ont besoin,
– Gestion des priorités,
– Utilisation des données récoltées au cours d’un partage, etc.
Description du fonctionnement de la plateforme et état d’avancement du

prototypage
Dans cette partie, nous décrivons les différents agents de la plateforme et leur fonction-
nement, à la fois, dans leur version actuelle et dans ce qu’ils devraient être à terme,
de plus, nous prenons en considération différents points de sécurité qui nous paraissent
primordiaux pour que l’on puisse envisager une utilisation réelle de notre application.

Dans cette dernière partie, nous présentons les différents tests réalisés pour vérifier la
validité de notre application.
Conclusion
Nous concluons sur l’impact du partage sur “le monde” de l’informatique et nous ouvrons
les perspectives d’unification des deux parties principales de ce document.
7
8
Chapitre 2
Introduction
Ces dernières années ont vu apparaître de multiples applications distribuées à grande

échelle. Certaines, comme SETI@HOME [Set], ne connaissent pas une grande notoriété
en dehors du milieu de l’astronomie ou de la recherche en informatique, d’autres comme les
systèmes de partage de fichier “peer-to-peer” (ou de pair à pair) comme Kazaa ou Overnet
[BSV03] sont devenus de réels phénomènes de société. Le développement des jeux vidéo
dits massivement multi joueurs comme Neverwinter Night, Ultima Online ou Everquest
montre de plus que les applications partagées peuvent connaître un public en dehors des
laboratoires de recherche. En fait ces jeux et ces applications ont un point commun qui
les différencie de nombre d’applications parallèles du domaine de la recherche : le partage.
Ces différents programmes sont “sociaux” : dans les jeux multi joueurs, on joue ensemble,
il serait donc logique par exemple que l’on partage la charge de la gestion du monde de
jeu comme on partage les frais entraînés par les activités sociales plus classiques ; de la
même façon les utilisateurs d’applications de partage de fichiers peer-to-peer partagent
leurs fichiers mais aussi le poids de la gestion du système de partage.
Le développement fulgurant des technologies et des applications peer-to-peer n’est que
la partie visible de l’état actuel mais surtout du futur du partage de ressources informa-
tiques.
En effet, la puissance de calcul informatique est aujourd’hui de plus en plus distribuée,
il y a plus de puissance de calcul dans l’ensemble des micro-ordinateurs des particuliers
que dans l’ensemble des gros systèmes de l’industrie, de la recherche et du renseignement
réunis. En fait, il y a même plus de puissance de calcul dans les cartes à puces aujourd’hui
que dans les ordinateurs. La plupart de cette puissance est complètement sous-utilisée.
Par exemple, les unités de calcul des cartes à puces des téléphones portables ne sont
presque pas sollicitées lorsque le téléphone n’est pas en communication ; pire, celles des
cartes de crédit à puces ne sont, elles, même pas alimentées lorsque la carte ne sert pas
pour effectuer un paiement. Mais c’est aussi vrai pour la plupart des ordinateurs. Par
exemple, le taux d’occupation de l’unité de calcul d’un PC basé sur un Athlon à 1,5 GHz
ne dépasse pas 50 % lors de l’utilisation simple de Word sous Windows XP, qui est l’une
des utilisations les plus courantes des ordinateurs personnels. Il en va de même de la
plupart des jeux vidéo qui sont très exigeants en matière d’affichage (donc pour la carte
vidéo si elle est de bonne qualité) mais demandent peu de calcul en dehors de cela, ce qui
laisse l’unité de calcul libre la plupart du temps.
9
Chapitre 2. Introduction
Dans ces conditions, il est logique de tenter de partager les ressources informatiques.
En effet, la plupart des ordinateurs (d’une société, d’une organisation ou même d’une
communauté d’utilisateurs) sont sous-utilisés à chaque instant, alors qu’un petit nombre
d’entre eux est dans le même temps surchargé. Plutôt que d’investir dans un meilleur
matériel, il serait préférable de s’associer de façon à profiter de la puissance de calcul
inutilisée des autres postes.
Les travaux des domaines associés au grid computing [FK99] ou à la programmation
de clusters [BFG+ 00] à plus ou moins grande échelle tendent vers ce but : utiliser au
mieux toutes les ressources informatiques même si elles sont distantes. Les ordinateurs
multiprocesseurs sont toujours hors de portée de la plupart des utilisateurs. Pourtant
l’informatique distribuée se démocratise : les clusters de PCs [Edi00] mettent les sys-
tèmes parallèles à la portée des petites entreprises et même de certains particuliers aux
usages spécifiques. Il faut de plus noter que certaines compagnies ont envisagé d’utiliser
la puissance des ordinateurs connectés aux réseaux de partage de fichiers P2P (peer-to-
peer) [Bor02]. Si la croissance continue de la puissance des processeurs limite l’intérêt des
ordinateurs multiprocesseurs pour la plupart des usages (ils nécessitent des applications
spécifiques pour exprimer tout leur potentiel et sont souvent à la fois encombrants et diffi-
ciles à concevoir), nous pouvons penser que le partage des ressources promet à terme que
la plupart des utilisateurs d’ordinateurs utiliseront bientôt des ressources “distantes” et
pourront accéder à la puissance de calcul de plusieurs processeurs au travers d’un réseau.
Il faudra donc, à terme que les applications même simples, destinées aux particuliers soient
conçues pour pouvoir être distribuées efficacement car cela deviendra un critère important
d’efficacité des programmes informatiques et ce quel que soit leur public.
Cependant, pour pouvoir profiter pleinement de cette manne de puissance de calcul
inutilisée, plusieurs considérations doivent être prises en compte :
– Les applications doivent être conçues de façon à pouvoir être distribuées. Il est
en effet inutile de distribuer une application séquentielle sans revoir son code. Il
faut de plus noter que même si plusieurs tâches d’une application peuvent être
exécutées en parallèle, il faut prendre en compte le coût des communications : si
deux processus physiquement distants partagent trop de ressources, il se peut que les
communications entre ces deux processus soient tellement coûteuses qu’elles freinent
l’exécution de l’application au lieu de l’accélérer.
– Il est de plus nécessaire de concevoir des systèmes informatiques qui permettent de
distribuer les processus sur les ordinateurs inutilisés tout en garantissant le respect
de l’intégrité, de la sécurité et de la confidentialité, non seulement des sites partagés
mais aussi des processus migrants. Ces “plateformes de partages” doivent de plus
prendre en compte la diversité des systèmes informatiques, avec leurs qualités et leurs
limites mais aussi la diversité des applications informatiques et de leurs besoins.
Les systèmes issus du grid computing ne répondent en général pas à toutes ces attentes.
Nous allons tenter, dans ce document, de répondre autant que faire se peut à ces différentes
attentes. Nous ne prétendons pas construire une vision universelle de la construction
d’applications réparties. Nous nous bornerons donc à tenter de donner une démarche
efficace pour construire des applications multiagents distribuées efficaces, puis en utilisant
ces mêmes agents, nous avons construit un système de partage de ressources informatiques.
D’une certaine façon, au cours de ce travail, nous allons revenir aux origines des systèmes
10
multiagents, même si ce sont des origines un peu oubliées.
Les systèmes multiagents (SMA) sont généralement considérés comme tenant du do-
maine de l’intelligence artificielle. Cependant on peut dire que ces systèmes se situent
plutôt à l’intersection entre l’intelligence artificielle, la programmation à base d’objets et
de composants et de l’informatique distribuée. Tout au long de ce mémoire nous allons
nous concentrer sur cette troisième spécificité. Plutôt que de considérer les agents comme
de l’IAD (Intelligence Artificielle Distribuée), nous nous plaçons ici, en quelque sorte, du
point de vue de l’informatique distribuée cognitive.
Au cours de ce document, nous nous intéresserons successivement :
– à la distribution physique des systèmes multiagents. Nous tenterons de construire
une méthode systématique permettant de construire un SMA distribué efficace ;
– puis nous pousserons encore plus loin vers le domaine de l’informatique distribuée
en utilisant les agents comme outils pour encapsuler des processus destinés à être
distribués sur un réseau en suivant une problématique proche de celle des systèmes
peer-to-peer, de la programmation de clusters ou du grid programming.
Ces deux problématiques sont liées : il s’agit toujours de tenter d’utiliser au mieux les
ressources informatiques distribuées qui sont caractéristiques des systèmes informatiques
d’aujourd’hui. Les buts de ce travail sont donc intimement liés à ceux des recherches dans
le domaine du grid, des clusters ou des systèmes peer-to-peer ; néanmoins, ils utilisent
des technologies caractéristiques des systèmes multiagents, du code mobile, et même à
terme de la programmation évolutionniste ou de l’apprentissage à cause de la nature
terriblement changeante des systèmes étudiés. Cependant, pour pouvoir utiliser les agents
pour distribuer des charges encapsulées dans des agents de façon à respecter les hypothèses
citées plus haut, il est nécessaire d’utiliser au mieux les caractéristiques des agents de
façon à améliorer les performances à la fois individuelles (de chaque agent) et collective
(du système en général).
L’un des principaux avantages de la “programmation agents” est l’autonomie qui ca-
ractérise théoriquement les agents. Cette autonomie devrait permettre une distribution
relativement simple d’un “programme agent” sur un système complexe. Les agents ap-
paraissent donc très adaptés à la distribution et au partage de charge sur un système
multiprocesseurs.
En réalité, répartir des agents sur un système distribué n’est pas simple, et ce, parce
que les systèmes multiagents sont aussi très dynamiques et donc assez imprévisibles. Dès
lors, la distribution de charge multiagent doit être dynamique elle aussi. Cependant les
méthodes habituelles de distribution dynamique de charge s’adaptent mal aux agents. Le
fait que chaque processeur observe sa pile et se décharge de certains processus en fonction
de son encombrement réduit considérablement l’indépendance et l’autonomie des agents.
en supposant que le système d’équilibrage de charge ne sépare pas les processus d’un
même agent (ce qui briserait son intégrité), cela revient, d’une certaine façon, à ce que
les agents soient “baladés” entre les processeurs. Dans notre cas, cela pose un problème
plus grave : cela rend très difficile de garantir l’intégrité et la confidentialité des agents
distants. Les agents devraient choisir seuls de migrer et vers quelle destination.
Il faudrait en fait que les agents aient les moyens de décider par eux-mêmes de mi-
grer selon leurs besoins et les exigences de leur hôte du moment. C’est d’autant plus
évident que, dans un système hétérogène, les services proposés par les différents ordina-
11
teurs peuvent être très divers. Ce type d’indépendance exige un niveau d’indépendance
supérieur de la part des logiciels : la liberté de mouvement pour les agents.
Cette autonomie est très exigeante. Les agents ne doivent pas seulement être capables
de migrer par eux-mêmes mais aussi capables de décider quand migrer et quand demander
une aide locale (dans le cas où la migration permet d’obtenir une ressource spécifique).
De plus, comme l’environnement des agents (c’est-à-dire le système multiagent distribué)
sera probablement très dynamique et qu’il sera très difficile de prédire ses tendances
lors de la phase d’implémentation, les agents devront être capables de s’adapter à un
environnement perpétuellement en évolution. Cela signifie qu’ils pourraient être forcés
d’apprendre comment et quand migrer en fonction de l’état du système.
Pour être réellement capable de créer des agents qui puissent migrer au sein d’un
système distribué de façon à répartir la charge entre les différents composants de ce
système et pour accéder à certaines ressources physiquement situées de façon à remplir la
tâche qui leur a été donnée, nous devons construire des agents mobiles dotés de capacités
d’analyse, voire d’apprentissage concentrées sur la recherche d’une réponse à la question
“où vais-je aller ensuite ?”
Avant de décrire notre méthode de conception de systèmes multiagents destinés à être
physiquement répartis sur des systèmes multiprocesseurs ou de construire notre système
de distribution de charge, nous allons décrire les différentes technologies soit que nous
utilisons soit dont nous nous inspirons dans nos buts ou dans nos outils. Nous allons
donc ouvrir ce document par un chapitre consacré à différentes techniques très diverses
et parfois sans liens apparents entre elles.
– Nous aborderons pêle-mêle les technologies liées au partage et à la distribution de
charge (“load-balancing”, “clusters”, “grid computing” et les systèmes de partage de
fichiers de pair à pair (P2P)).
– La programmation évolutionniste, puisque les méthodes qui lui sont associées se-
raient, comme nous l’avons dit très adaptées au milieu en perpétuelle évolution
comme les ordinateurs.
– Les technologies agents, aussi bien les agents eux-mêmes que les systèmes multia-
gents. Il était nécessaire de s’arrêter suffisamment sur ces derniers car les agents
et les SMA sont non seulement l’outil mais aussi le sujet de notre travail (puisque
nous nous sommes intéressés aux façons de les distribuer correctement sur un sys-
tème multiprocesseur dont les communications pourraient être coûteuses (comme
les clusters ou les systèmes à plus large échelle).
– Enfin, nous devons nous arrêter sur les technologies dites de “code mobile” et plus
précisément sur les agents mobiles puisqu’il est nécessaire d’utiliser la mobilité pour
partager des ressources et distribuer des charges non définies a priori.
12
Deuxième partie
Systèmes multi-agents et informatique

partagée : un état de l’art
13
Chapitre 1
Technologies de partage de ressources

informatiques
1.1 Architectures issues des systèmes distribuées

Dans cette partie, nous nous arrêterons d’abord sur les systèmes distribués les plus
classiques et sur leurs bases théoriques, les solutions de distribution de charge (“load-
balancing”), sur les algorithmes et les méthodes caractéristiques de ces solutions et sur
leurs limites.
Il existe déjà diverses façons de partager des ressources informatiques et de distribuer
la charge de travail sur le système ainsi conçu. La solution la plus classique pour utili-
ser la puissance d’un ensemble d’ordinateurs pour réaliser des tâches distribuées est le
“clustering” mais les clusters ont des limites qui les rendent difficiles à appliquer à un réel
partage de ressources à grande échelle. Nous nous intéresserons donc aussi aux systèmes
dits “grid-computing” et “peer to peer”.
1.1.1 Les solutions de distribution de charge

Dans cette partie, nous présenterons les systèmes distribués “théoriques”, c’est-à-dire
les architectures multiprocesseurs, les méthodologies et les algorithmes de distribution de
charge.
Les architectures de systèmes distribués

Quand on décrit un système distribué, deux choses doivent être distinguées, l’architec-
ture physique du réseau de microprocesseurs qui le compose et la représentation abstraite
du système informatique qui peut découler d’autres données que l’architecture physique
du système.
Les architectures de réseau

L’existence de systèmes partagés exige l’existence de plusieurs entités communiquant
de façon à se transmettre leurs différentes surcharges. Ces systèmes peuvent ête de deux
types, ce sont soit des ordinateurs multiprocesseurs soit des groupes d’ordinateurs en
15
Chapitre 1. Technologies de partage de ressources informatiques
réseau fonctionnant comme une seule machine capable de calculs parallèles. Les deux so-
lutions ne sont pas fondamentalement différentes puisqu’un ordinateur multiprocesseur
n’est pas autre chose qu’un réseau de multiprocesseurs. Cependant, les architectures de
ces réseaux de processeurs sont spécifiquement conçues dans le but d’améliorer les perfor-
mances du système multiprocesseur, alors que les architectures des réseaux d’ordinateurs
se basent généralement sur une architecture IP qui a d’autres buts (se référer au chapitre
sur les couches de réseau et de transport dans [Tan03] et dans [Puj02] aux chapitres
architectures de réseau et ceux sur les réseaux TCP et les réseaux Ethernet). Nous avons
représenté un réseau routé sur la figure 1.1, on peut comprendre que l’efficacité d’une hy-
pothétique distribution de charge est secondaire devant la redondance des communications
et la volonté de minimiser les goulots d’étranglement.
Fig. 1.1 – Un exemple de réseau, les carrés sont des routeurs, les points des sites infor-
matiques
16
1.1. Architectures issues des systèmes distribuées
C’est pour cette raison que si les ordinateurs multiprocesseurs ont des architectures
très particulières (hypertoriques, hypercubiques, en étoile . . . ) beaucoup plus efficaces que
celles des réseaux d’ordinateurs qui ont en fait celles des intranets, extranets . . . servant
de base à ces systèmes informatiques distribués.
Les ordinateurs multiprocesseurs

Nous ne rentrerons pas dans le détail des architectures multiprocesseurs, et ce pour
plusieurs raisons. D’abord ces machines sortent de notre étude car elles sont naturellement
construites pour permettre le partage des ressources entre leurs différents processeurs.
Ensuite parce que les architectures employées pour construire ces machines sont très
diverses. En effet même au sein des ordinateurs d’une même marque les architectures
peuvent varier.
Il existe cependant deux grandes catégories :
– Les systèmes à mémoire partagée (qu’ils soient réels comme certains supercalcula-
teurs ou virtuels comme dans le cas de certains outils pour clusters) :
Les systèmes à mémoire partagée minimisent les difficultés liées au transfert d’in-
formation entre les différents processeurs. En effet, tous les processeurs partagent
la même mémoire vive (RAM). Les différentes tâches parallèles d’un programme
peuvent ainsi facilement partager des données puisque toutes les tâches peuvent ac-
céder aux données des autres. Chaque tâche baigne dans le même environnement.
Ce partage de mémoire peut entraîner quelques problèmes de synchronisation et de
cohérence. Il faut donc empêcher deux tâches parallèles d’accéder simultanément
aux données si l’une d’elles y accède en écriture. . . Il est donc nécessaire d’assurer
la synchronisation des tâches tout en évitant d’engendrer des blocages du type du
problème des philosophes. Ce type d’architecture est utilisé dans tous les types d’or-
dinateurs multiprocesseurs. Elle est utilisée dans les PCs multiprocesseurs comme
dans les très gros systèmes multiprocesseurs. Ces systèmes s’avèrent très efficaces
car ils peuvent facilement se substituer à leurs équivalents monoprocesseurs, certains
servent même de station de travail personnelle. Les noyaux des principaux systèmes
d’exploitation permettent de les gérer (aussi bien les Linux standards que les sys-
tèmes à base NT (Microsoft), il existe même un patch pour les systèmes de type
Win 9.x qui permet d’utiliser un PC biprocesseur).
– Les systèmes à mémoire séparée :
Les systèmes à mémoire séparée ressemblent plus à un assemblage d’ordinateurs.
Dans ce cas chaque microprocesseur possède sa propre mémoire vive indépendante.
Cette architecture est assez classique sur les très gros systèmes (Origin 2000 par
exemple), mais elle est parfaitement inexistante sur les petits multiprocesseurs (comme
les PCs biprocesseurs, par exemple). Cette architecture rend plus difficile la concep-
tion de programmes distribués puisque les différents processeurs doivent communi-
quer en utilisant du “message passing” (envoi de message). Il n’existe dès lors plus
de problèmes de synchronisation des accès aux ressources mais il faut gérer les en-
vois de messages nécessaires au partage des informations. Les envois de messages
posent un autre problème de synchronisation : sur un réseau il peut être difficile
de garantir la synchronisation des messages (respect de l’ordre d’émission) et même
17
simplement leur arrivée. Dans le cas des ordinateurs multiprocesseurs, ces deux ques-
tions se posent peu. Les connexions entre les microprocesseurs sont telles que l’on
peut faire l’hypothèse de la sécurité du réseau et de la synchronisation des messages.
Cette hypothèse peut être dangeureuse mais elle est assez valide au vu de la qualité
des communications internes à ces machines et des distances considérées (au plus
quelques dizaines de centimètres).
– Les différentes architectures :
Nous allons présenter rapidement quelques topologies classiques des systèmes mul-
tiprocesseurs [BP97]. E. Billard et J. Pasquale calculent les distances aux seins de
ces différentes topologies pour pouvoir prendre en compte la proximité de façon à
minimiser le coût des communications par exemple. Nous allons montrer dans la
figure 1.2 un exemple de chacun des cas suivants :
– En anneau
– En étoile
– En hypertor
– En hypercube
Les systèmes en réseau

Les systèmes en réseaux sont, en général, construits sur des réseaux de type de ethernet
ou FDDI. Ces réseaux sont très classiques et leur architecture est assez bien connue. Leur
forme réelle est souvent simplement une étoile autour d’un switch ou d’un hub. On les
appelle systèmes en cluster (ou simplement clusters). Nous traiterons plus en profondeur
de ces systèmes dans la section Systèmes de type “cluster”. Il faut aussi prendre en compte
les systèmes construits à plus large échelle (comme par exemple les systèmes répartis
connectés par Internet) ces systèmes seront décrits dans la section sur le Grid computing.
Dans ce cas les systèmes concernés sont séparés par des routeurs et l’architecture physique
réelle du système devient extrêmement complexe, elle n’est de plus souvent connue que
très partiellement.
Ces différents systèmes sont souvent construits autour d’une architecture abstraite qui
permet de gérer et d’utiliser les ressources au mieux .
Les architectures abstraites

On trouve des systèmes dont les architectures simulent les cas cités précédemment mais
aussi des systèmes hiérarchiques (figure 1.3, on représente des ordinateurs reliés par une
architecture hiérarchique : chaque processeur dispatche les tâches sur les ordinateurs qu’il
domine en cas de surcharge. Si tous les sites du niveau inférieur sont occupés, la tâche
remonte au niveau supérieur qui peut alors les dispatcher dans une autre branche, les
réaliser ou les remonter d’un niveau . . . ) ou basés sur des domaines.
En fait, certains systèmes permettent même de simuler l’existence d’une mémoire
partagée sur un cluster. On appelle ces solutions systèmes à mémoire partagée distribuée
(voir Linda).
On peut envisager d’autres modèles, selon les besoins et la nature du partage, des
systèmes très divers sont possibles (voir la section sur les systèmes “peer to peer” et la
partie sur notre système de partage grâce aux agents).
18
segment
étoile
grid
anneau clique
Fig. 1.2 – Exemples d’architectures classiques
Quelques modèles de systèmes de distribution de charge
Les architectures statiques et dynamiques
Les architectures statiques

Dans cette partie, nous décrirons les systèmes de distribution de charge statiques, ainsi
que leurs avantages et leurs limites :
– Perfection théorique
– Inadaptabilité
– Hypothèses simplificatrices dangereuses
19
Fig. 1.3 – Un exemple d’architecture hiérarchique
Les architectures de distribution de charge statiques suivent un schéma semblable assez

simple :
On commence par couper la tâche à réaliser en en différents “morceaux” puis on répartit
ces morceaux sur les différents ordinateurs en maximisant le parallélisme. Ces méthodes
sont inspirées des solutions de génie industriel. En fait, on traite la distribution des charges
informatiques comme un problème d’ordonnancement de tâches sur des machines outils.
Assimiler nos problèmes de distribution de charges informatiques à un problème d’or-
donnancement sur machine est très logique puisque les problèmes sont essentiellement
très semblables :
– Dans les deux cas, il s’agit de distribuer des travaux à différentes " machines ",
– De façon à minimiser la durée du travail global et à maximiser l’utilisation des
différents postes.
20
Cependant, certaines différences qui peuvent sembler cosmétiques ont une importance
capitale t peuvent entraîner des divergences majeures :
– On construit l’ordonnancement des tâches sur les machines-outils pour chaque tra-
vail donné à " l’application " ensemble de machines-outils alors que l’on désire
construire un système d’ordonnancement de tâches informatique liée à l’application
en général et non pas à chacune de ses applications spécifiques. D’autant plus que
l’on ne connaît pas toujours a priori l’ensemble des sous tâches nécessaires à la
résolution de chaque utilisation de l’application distribuée,
– Les différentes tâches d’une machine-outil sont très clairement définies alors que
pour distribuer une application, il faut d’abord la couper,
– Les sous tâches d’une applications informatique doivent communiquer entre elles car
l’état de certaines d’entre elles peut influer sur celle des autres.
Ces différences sont capitales, en effet, pour connaître à coup sûr toutes les tâches d’une
application, il faut la dérouler entièrement, cela ne pose pas de problème lorsque la tâche
consiste en le déroulement complet d’un algorithme non récursif, dans d’autres cas, cela
peut tout simplement consister en l’exécution complète de la tâche, ce qui rend la distri-
bution statique impossible. De la même façon, il faut répondre à la question : comment
couper les tâches ? en effet, chaque processeur généraliste peut réaliser toutes les tâches
que font les autres et la granularité des tâches informatique est extrêmement petite. Or
comme nous le rappelons, les communications entre différentes tâches distantes ont un
coût non négligeable, il faut donc concilier le gain dû à la distribution et le coût des
communications [ESHH01].
Cependant les méthodes d’ordonnancement de tâches peuvent être très utiles si elles
sont utilisées à bon escient (par exemple pour construire un système de distribution de
charge dynamique voir plus loin).
Les architectures dynamiques

Dans cette sous-partie, nous décrirons les architectures les plus classiques des systèmes
distribués :
– Systèmes à distribution centralisée,
– Systèmes à distribution annelée,
– Passage à l’échelle et systèmes à domaine.
La distribution de charges est naturellement liée aux questions d’ordonnancement de
tâches et de tolérance aux pannes. Comme Leila Baccouche [Bac95] le souligne dans sa
thèse, la tolérance aux pannes est souvent atteinte par “redondance” des services et des
données. Pour pouvoir construire un système réellement redondant, il est nécessaire que le
système soit distribué (posséder des versions redondantes de ses données sur un même site
ne protège pas des problèmes que pourrait connaître l’ordinateur). En fait, elle conclut
qu’il n’existe que deux raisons à l’existence de l’informatique distribuée : la tolérance aux
pannes et la distribution des charges les plus lourdes sur des machines parallèles pour
accélérer leur exécution. Ces deux buts sont cependant difficiles à atteindre car ils exigent
que le système soit capable de fonctionner sous les contraintes “temps réel” ce qui est
difficile à obtenir puisque les ordinateurs ne sont pas nécessairement synchronisés. On
peut minimiser ces problèmes en utilisant certains outils comme les horloges vectorielles
21
[Maz01].
La distribution de charge peut être réalisée selon deux modèles différents, l’un statique
et l’autre dynamique. Dans le premier cas, chaque processus du programme s’exécute sur
une machine choisie non pas au début de son exécution mais lors de la phase d’implémen-
tation du système. Cette méthode demande une connaissance parfaite a priori du poids
et des besoins de chacun des différents processus. Ce besoin est rarement satisfait dans
le cas de programmes et d’applications complexes et il n’est jamais satisfait si le système
interagit de façon importante avec l’extérieur (utilisateurs, phénomènes physiques . . . ).
Même dans le cas où la connaissance est parfaite, les algorithmes de distribution tirés des
méthodes d’optimisation exigent des approximations qui peuvent entraîner des différences
notables de performances entre la distribution “théoriquement parfaite” et la distribution
effectivement optimale. [12] Il devient de plus très difficile d’assurer un minimum de sta-
bilité en cas de panne d’une machine puisque le système est prévu pour fonctionner en
suivant une distribution très précise.
Il est donc en général nécessaire de construire des systèmes capables de distribuer la
charge de travail dynamiquement, c’est-à-dire des systèmes qui placent les processus sur
un site quand ils apparaissent, en fonction de la charge instantanée et qui les déplacent
si la situation change. Pour obtenir ce résultat, plusieurs approches sont possibles. Ce-
pendant on considère en général la distribution de charge (dynamique comme statique)
comme un problème d’optimisation que l’on résout en utilisant les méthodes de recherche
opérationnelle.
La recherche opérationnelle et les méthodes d’optimisation offrent un grand nombre
d’algorithmes qui apportent une solution parfaite au problème de distribution statique de
charge à diverses vitesses, cependant le problème est NP-difficile, ces méthodes ne sont
donc que des heuristiques plus ou moins efficaces. La distribution dynamique de charge
peut être envisagée de différentes façons mais elle est souvent traitée comme un problème
de distribution de charge statique régulièrement réactualisée. Un serveur arrête le système,
demande à chacun des processeurs la taille de sa pile et ses priorités puis redistribue les
tâches de la meilleure façon possible. Chaque réallocation des charges est beaucoup plus
rapide qu’un calcul complet d’allocation de charge (comme dans le cas statique) car seules
les piles des processeurs sont prises en compte. Ces méthodes permettent de construire
des systèmes distribués traitant des problèmes non déterministes (ou trop complexes pour
être complètement analysés) de façon efficace car les tâches sont distribuées plus ou moins
“comme elles viennent”. La contrepartie de cette efficacité est que la distribution elle-même
consomme de la puissance de calcul et force le système à des arrêts intermittents ce qui
ralentit tout le programme d’autant plus que cette réallocation n’est pas facile à réaliser.
Les caractéristiques des algorithmes de placement

Les algorithmes de placement ont certaines caractéristiques communes, ils doivent me-
surer la charge des processeurs, puis choisir sous quelles conditions se font les transferts de
charge et proposer des solutions pour le choix de la destination des charges surnuméraires.
La plupart de ces algorithmes sont destinés à placer des processus, cependant, il existe des
systèmes replaçant des données (et même des objets ou des agents). Les problématiques
ne diffèrent pas vraiment, c’est pourquoi nous ne prendrons en compte, ici, que le cas des
22
algorithmes de placement de processus.

– Les indicateurs de charge peuvent être de nature très diverse, ils permettent de
mesurer la charge des machines concernées. Ils sont en général réduits à une va-
riable agglomérant les différents facteurs considérés comme primordiaux par les
concepteurs du système (charge du processeur, occupation de la mémoire vive, accès
aux disques. . . ). Ils peuvent cependant être représentés sous forme de vecteurs, par
exemple, mais la complexité de la représentation de ces données peut augmenter
énormément le poids du système de partage.
– Les politiques de transfert : les politiques de transfert se concentrent sur le fait
suivant : la distribution parfaite n’est pas souhaitable, ce que l’on désire obtenir,
un ensemble de processeur dont aucun élément n’est surchargé si d’autres ne sont
pas occupés au maximum. Le but devient donc de faire migrer les processus si “une
machine est surchargée et il en existe une autre qui peut accueillir des processus
supplémentaires”. Les politiques divergent largement en fonction des buts recherchés
par les concepteurs.
– Politique d’information et de localisation : pour que l’application puisse tourner
correctement, il faut que les processus puissent communiquer entre eux malgré leurs
migrations. Pour obtenir ce résultat, il est nécessaire que les processus puissent se
localiser et se retrouver, voir que deux processus en forte interaction ne puissent
être placés “loin” l’un de l’autre.
Distribution centralisée
Par définition, une distribution de charge statique est construite avant l’implémentation.
On peut donc considérer que c’est un processus centralisé puisqu’elle n’est pas construite
sur les processeurs du système distribué. Au contraire, une distribution de charge dyna-
mique peut être répartie ou centralisée. Un système de distribution de charges centralisé
comprend un hôte spécifique qui distribue et redistribue les charges sur les différents
processeurs en fonction de l’encombrement de ces derniers ou d’autres critères.
Le serveur (c’est à dire l’hôte chargé de répartir les tâches entre les différents proces-
seurs) doit avoir une connaissance correcte et régulièrement remise à jour de la charge de
chacun des processeurs. Pour cela, il devient nécessaire que les différents processeurs com-
muniquent leur état très régulièrement au serveur. Ces communications ne sont pas très
coûteuses sur un superordinateur, mais elles peuvent devenir un réel frein sur un système
plus lent (comme un extranet, par exemple), enfin elles seraient simplement impossibles
sur un système ouvert à grande échelle. De plus comme nous l’avons déjà dit, le calcul
d’une solution au problème d’optimisation associé au système partagé est un problème
NP-complet par rapport au nombre de processeurs [BF96] même si certaines heuristiques
permettent de l’accélérer. Enfin, dans un système ouvert, un serveur centralisé pose un
problème puisque son bon fonctionnement est absolument indispensable au bon fonction-
nement du système dans son ensemble. On ne peut simplement pas gérer un système de
partage à grande échelle de façon centralisée. Il faut de plus noter qu’un système centra-
lisé risque de ne pas être adapté à la gestion d’un système ouvert car chaque ordinateur
se connectant devrait commencer par s’inscrire auprès du serveur ce qui peut être très
coûteux et même entraîner la surcharge de ce dernier qui utiliserait toute sa puissance de
23
calcul pour gérer les entrées et les sorties. Il paraît donc logique d’utiliser un système de
distribution de charge réparti pour gérer un système à la fois large et ouvert.
Distribution partagée
Cependant ces systèmes sont difficiles à construire, une solution de distribution de
charge demande une connaissance globale du système. Pour construire un système distri-
bué de répartition de charge efficace, le plus simple est donc de partitionner le système
en régions et de choisir au sein de chaque région un serveur local qui gérera de façon
centralisée un système qui aura été réduit d’échelle [AG91].
Ce type de solutions ne permet pas de construire un système vraiment distribué. On
se borne ici à réduire l’échelle du système multiprocesseur pour le ramener à une taille
gérable de façon centralisée. Cette solution peut être suffisante dans certains cas d’autant
plus qu’elle a été adaptée à la gestion des systèmes ouverts [BF96]. Cependant cette
méthode présente de sévères limites :
– La connaissance de chaque serveur est limitée. Il se peut qu’il puisse communiquer
avec les autres serveurs par exemple pour permettre la distribution de charge non
pas au sein d’une seule région mais entre régions plus ou moins chargées, mais dans
ce cas il faut gérer la distribution de charge entre régions ce qui exigerait un “super
serveur” de “super région” qui gérerait la distribution au niveau global comme les
serveur de chaque région gère la gère au niveau local. On construit dès lors une
hiérarchie pyramidale à la fois complexe et coûteuse (puisqu’un grand nombre de
machines doivent gérer des problèmes complexes), peu sûre (si le serveur de plus
haut niveau a un problème tout le système s’arrête. . . ) et en général sujet à tous
les défauts des systèmes centralisés. Si par contre, les régions ne communiquent pas,
le système risque d’avoir du mal à s’adapter (certaines régions seront surchargées
alors que d’autres seront complètement vides).
– L’existence de sous régions présente aussi quelques problèmes car tous les ordinateurs
ne sont pas équivalents. Dans un système multiprocesseur hétérogène (comme le
parc informatique d’une société ou d’un laboratoire), certaines tâches doivent être
données à un certain type d’ordinateur (parce qu’ils offrent des services spécifiques
ou parce qu’elles ont des caractéristiques techniques particulières). Construire une
architecture permettant de gérer les relations interrégionales peut être difficile.
– La troisième limite de ces méthodes a déjà été entr’aperçue plus haut, elle concerne
la sécurité du système dans son ensemble. Le (ou les) serveur(s) est une cible fa-
cilement identifiable pour une attaque car ils sont nécessairement connus de tous
les hôtes et de tous les programmes. Dans le cas d’un serveur unique, si le serveur
s’arrête, l’application entière doit être arrêtée. Cependant dans le cas d’un système
régionalisé, certains serveurs pourraient s’arrêter sans que les autres s’en rendent
compte, ce qui peut engendrer des erreurs non détectées donc extrêmement dange-
reuses.
– Il est de plus facile de gêner le système, puisqu’il est centré sur les serveurs. Sur-
charger les serveurs de messages peut suffire à provoquer le “plantage” du système
dans son ensemble et ce parce que le serveur communique dans les deux sens avec
les hôtes (il reçoit leurs caractéristiques instantanées et renvoie les modifications du
24
plan). Enfin, le serveur est le seul lien entre les données partagées, donc, s’il est
corrompu, les informations réparties ne sont plus protégées.
Ces méthodes de répartition de charges sont à la fois relativement simples à implémenter et
théoriquement très efficaces, puisque le serveur centralise toutes les informations possibles
puis redistribue les charges en suivant la meilleure distribution théorique. Les algorithmes
permettant cette distribution profitent d’années de recherches en aide à la décision et
en recherche opérationnelle. Cependant, leurs évidentes faiblesses dans la gestion et la
sécurité des systèmes ouverts et à grande échelle les rendent difficiles d’utilisation sur des
systèmes scalables et ouverts répartis sur la Toile.
Les hypothèses classiques

Les systèmes de distribution de charge suivent en général les hypothèses suivantes
[BF96] :
– On distribue des processus,
– Sur lesquels on ne possède aucune information,
– Le critère de préférence est le temps moyen d’exécution.
La distribution dynamique de charge n’a de tout façon de sens que pur une minorité de
processus très lourds. En effet, en prenant UNIX pour exemple, plus des trois quarts des
processus ont une durée de vie inférieure à une seconde CPU [BF96].
Bernard et Folliot [BF96] décrivent aussi les buts habituellement associés aux plate-
formes de distribution de charge : on doit obtenir les meilleures performances possibles,
sur une plateforme dont la distribution doit être transparente pour l’utilisateur. Le sys-
tème doit aussi être stable et tolérant aux fautes. Enfin, il doit être extensible, c’est-à-dire
pouvoir accueillir un grand nombre d’ordinateurs.
1.1.2 Les systèmes de type “cluster”

A la fin des années quatre-vingts, il est apparu que les systèmes distribués (comme par
exemple les ordinateurs multiprocesseurs à mémoire partagée) permettaient d’obtenir des
résultats comparables (à l’époque 10 fois inférieurs environ) aux plus puissants ordinateurs
monoprocesseurs . . . à des coûts mille fois moindres. Sont apparus dès lors de plus en
plus d’ordinateurs multiprocesseurs, on a même trouvé des multiprocesseurs dans certains
ordinateurs particuliers. Cependant la principale avancée dans ce domaine a peut-être été
l’apparition de systèmes à mémoire séparée. C’est de ces technologies que découlent les
clusters.
Définition
Les clusters [DK01] qui sont rapidement décrits dans des éditoriaux du journal “Paral-
lel Computing” [Edi00] sont des ensembles d’ordinateurs utilisés comme un seul ordinateur
capable de calcul parallèle. Il en existe de plusieurs types (en fonction des technologies
utilisées), les clusters comme ceux présentés dans [DK01] et [BFG+ 00], mais aussi les
clusters BSP [DHS00], couplés [Wat00].
25
Pour fonctionner, ces systèmes exigent de très bonnes connexions réseaux puisque les
différents processus parallèles devront communiquer par envoi de message en utilisant le
réseau qui relie les différents ordinateurs membres du cluster. Cela limite en général la
forme des clusters. En effet, comme les communications peuvent être le principal frein
des clusters, on les construit en général en reliant quelques machines avec un réseau à
haut débit (Ethernet ou FDDI). Cependant le développement des communications à haut
débit permet maintenant d’envisager des clusters constitués d’ordinateurs distants. Ce
type d’installation entraîne quelques hypothèses simplificatrices que nous nous devons de
noter.
– Les problèmes de sécurité et de tolérance aux pannes sont réduits ou différents (en
effet les ordinateurs concernés peuvent tous être observés par un utilisateur).
– Les ordinateurs sont peu nombreux, il n’y a donc pas de problème de passage à
l’échelle.
– De plus cela permet de considérer que le code à exécuter est présent partout.
– Tous les “propriétaires” des différents ordinateurs sont tous coopératifs (puisqu’ils
sont sans doute tous gérés par le même responsable).
– Les ordinateurs sont souvent homogènes (les possibilité de communications sont
maximales, envoi de pile mémoire . . . ).
Il existe deux grands types de modèles pour l’informatique partagée, les systèmes à mé-
moire partagée et les systèmes à mémoire séparée. Ces deux modèles découlent de l’ar-
chitecture des ordinateurs multiprocesseurs : soit chaque processeur a sa propre mémoire,
soit tous les processeurs partagent la mémoire. Chacun des deux modèles a ses avantages
et ses défauts. Cependant, dans l’ensemble les systèmes à mémoire partagée sont plus
rapides dans le cas où les tâches parallèles partagent beaucoup de données car les diffé-
rents processus partagent le même environnement. Dans les systèmes à mémoire séparée,
des envois de messages sont nécessaires pour que les données soient à jour. Comme les
clusters ne sont pas un multiprocesseur mais des ordinateurs reliés par un réseau, ils sont
nécessairement, sur le plan technique, des systèmes à mémoire séparée. Pourtant, cer-
taines plateformes de clustering permettent de simuler un système à mémoire partagée.
On appelle cette “mémoire” une mémoire partagée distribuée. L’implantation de systèmes
de ce type exige une grande prudence. En effet, il faut garantir la synchronisation et la
cohérence des données. Nous donnons un exemple de fonctionnement de la mémoire par-
tagée distribuée dans la section sur Linda (voir plus bas). Il faut cependant noter que
si l’existence d’une mémoire partagée simplifie la programmation des applications distri-
buées (il n’y a plus à vérifier si les messages sont corrects puisque la plateforme garantit
la cohérence et le transfert des données, on ne gagne en aucun cas la vitesse gagnée avec
un système à mémoire partagée. En effet les transferts se font toujours par le réseau donc
ils sont aussi lents que si la mémoire n’était pas partagée et même un peu plus puisque
la plateforme utilise une partie de la puissance pour simuler la mémoire partagée.
Hétérogénéité des composants

La plupart des clusters sont constitués d’ordinateurs homogènes, cela réduit leur op-
timisation à un problème de distribution de charge. Mais l’hétérogénéité des systèmes
informatiques concernés étant une hypothèse de base de notre étude, nous allons nous
26
arrêter sur les travaux réalisés sur la gestion de l’hétérogénéité dans les clusters.
Sunderam et Geist dans [BDG+ 91, Sun94] décrivent les différents types d’hétérogé-
néité possibles :
– Différents systèmes et architectures (SIMD, MIMD, scalaires. . . )
– Différentes configurations sur des ordinateurs de même architecture (PCs diffé-
rents. . . )
– Différentes influences externes
– Différences de réseau
– Différences logicielles.
L’hétérogénéité pose des difficultés sérieuses. Les processus ne peuvent plus communi-
quer puisque les structures de données diffèrent d’un système à l’autre, les synchronisations
sont plus complexes (et donc plus lentes) puisque les ordinateurs ne vont pas à la même
vitesse. Et bien sûr, les questions de distribution de charges deviennent plus complexes
puisque les processus doivent être partagés entre des hôtes différents. Cela devient encore
plus complexe si l’on prend en compte les qualités spécifiques de chaque ordinateur. Il
faut alors répondre à la question : quel ordinateur répond le mieux aux besoins spécifiques
de chaque tâche ?
Plusieurs plateformes gèrent les systèmes hétérogènes, elles ne résolvent pas tous les
problèmes cités plus haut.
Linda
Linda a été présentée en 1993 par N. Carriero et D. Gelernter [CG89]. Ce système
est issu d’un projet de recherche de l’université de Yale. Linda est basée sur le concept
d’“espace t-uplet” lequel représente un espace abstrait dans lequel les processus coopèrent.
Linda propose une alternative aux deux solutions généralement envisagées en matière
d’informatique parallèle, le modèle à mémoire partagée et le modèle à mémoire séparée.
Linda est une plateforme destinée aux clusters, elle est donc implantée sur un système à
mémoire séparée mais elle place une couche au dessus des communications qui permet de
construire un système à “mémoire partagée distribuée”. Chaque unité de mémoire est un
bloc placé sur un ordinateur. Lorsqu’un processus utilise ce bloc, il le “retire” du t-uplet
des blocs, le modifie et le replace. Ce système garantit la synchronisation lors des appels
de données à la façon d’un sémaphore (personne ne peut accéder à un bloc utilisé puisque
son utilisateur l’a retiré du t-uplet).
Linda a été étendue par “Pirhana”. Alors que Linda ne gère que le partage du système,
Pirhana permet une certaine distribution de charge en utilisant des agents : chaque ordi-
nateur est un agent qui cherche à récupérer les tâches émises par le serveur et qui les reçoit
en fonction de ses ressources disponibles. Linda et Pirhana servent de modèle à de nom-
breuses plateformes pour l’informatique partagée. Ils servent même de modèle à certains
systèmes de partage à grande échelle, mais seulement dans le cadre de projets de recherche
car les communications de Linda sont assez lentes (d’autant que certaines d’entre elles
sont redondantes). Cependant l’amélioration des communications permet d’imaginer que
l’on puisse bientôt utiliser des systèmes proches de Linda dans des systèmes de partage à
grande échelle.
27
P4
P4 [DGMS93] est une bibliothèque de fonctions destinées à aider à la programmation de
systèmes multiprocesseurs. P4 contient les fonctions nécessaires à la gestion de systèmes
à mémoire partagée et à mémoire séparée. De plus elle introduit quelques primitives qui
nous semblent capitales comme la différenciation entre les communications bloquantes et
non bloquantes. P4 ne permet pas la constitution d’une mémoire partagée distribuée.
Message Passing Interface [MPI]

En 1992, un groupe constitué d’universitaires et d’entreprises a commencé à définir un
standard pour les envois de messages. En 1994, paraît MPI-1 qui décrit les différentes
primitives associées aux différents types de communications (communications point à
point, collectives) ainsi qu’aux différents types d’architectures multiprocesseurs. Il faudra
cependant attendre MPI-2 publié en 1997 pour que l’on puisse appliquer les primitives
MPI aux systèmes hétérogènes. En effet, MPI-1 ne définissait pas de standard de début
de processus.
PVM
PVM [GAD+ 94] est un ensemble de primitives permettant l’existence d’un cluster d’or-
dinateurs complètement hétérogène pouvant être lui-même constitué de clusters hétéro-
gènes reliés par des réseaux différents (comme plusieurs systèmes connectés par Internet).
Les processus parallèles sont des composants informatiques d’un niveau de granularité
assez élevé (pour minimiser les communications). Un daemon appelé pvmd doit être lancé
sur chacun des ordinateurs partagés et ce sont ces daemons qui initialisent ensemble la
machine virtuelle.
Les programmes utilisant PVM voient le cluster comme un système parallèle très
flexible, mais les problèmes sous-jacents (comme les questions de communication) sont
transparents pour les applications. Parmi les avantages de PVM, l’un des plus notables
est qu’il n’exige aucun droit particulier pour fonctionner (n’importe quel utilisateur valide
de l’un des hôtes potentiels peut installer PVM sur sa machine). Le système dans son en-
semble peut de plus être vu comme une unique mainframe puisque chaque utilisateur peut
lancer des tâches à partir de son hôte. Le dernier avantage de PVM découle de sa trans-
parence : puisque les programmes voient le système comme un multiprocesseur à mémoire
distribuée, programmer des applications pour PVM n’est pas différent de programmer des
applications pour n’importe quel système de ce type (comme les architectures hypercubes
d’Intel). Il faut cependant noter que les communications peuvent être un réel frein pour
tous les systèmes distribués (comme PVM) donc que la granularité de la décomposition
en tâches parallèles ne doit pas être trop élevée. Il faut noter que le parallélisme de PVM
a pour granularité minimale le processus et ce même au sein d’un ordinateur multipro-
cesseur (contrairement aux ordinateurs vectoriels qui peuvent paralléliser les opérations
jusqu’au niveau des boucles). Pouvoir paralléliser les threads (processus légers) au sein
d’un ordinateur permettrait de permettre de profiter de la mémoire partagée plutôt que
de devoir faire communiquer les tâches parallèles par l’intermédiaire d’envois de messages.
PVM présente de plus quelques lacunes en matière de tolérance aux pannes. En effet,
PVM propose un système de notification qui implique qu’un administrateur surveille le
28
système et qui ne prend pas en compte de potentielles pannes graves non détectées des
hôtes. En effet, un hôte quittant la machine virtuelle permet normalement aux tâches
hébergées de notifier leur hôte d’origine ou les autres tâches mais si l’ordinateur plante,
les tâches n’ont aucune alternative.
La version actuelle de PVM peut être installée sur les Windows à noyau NT et sur la
plupart des UNIX, elle inclut les fonctions d’espace t-uplet (voir Linda), la génération et
la destruction dynamique des tâches. Il est à noter que PVM obtient des résultats très
corrects aux tests du banc d’essai de la NASA, NAS [DGMS93].
Les concepts de base de PVM ont servi de base à d’autres projets comme Harness
[MS99, MS00] qui étend le principe de la machine virtuelle à des systèmes de partage à
large échelle.
Conclusion
Les clusters sont une base des systèmes distribués modernes. En effet, ils coûtent
beaucoup moins chers que les superordinateurs et obtiennent des résultats acceptables.
Cependant, la conception des clusters a exigé des avancées technologiques intéressantes. Il
n’était pas facile de faire fonctionner plusieurs ordinateurs comme un seul. Les méthodes
et techniques caractéristiques des clusters se retrouvent aujourd’hui dans les technologies
de “grid programming”. C’est en cela que les clusters sont les plus intéressants pour nous :
ce sont les solutions développées pour la conception des clusters que l’on tente d’appliquer
à grande échelle sur les systèmes scalables. En fait, on peut même utiliser les technolo-
gies de cluster en les passant à l’échelle en construisant des “super cluster” comme celui
représenté sur la figure 1.4, c’est-à-dire des clusters de clusters. Cependant, pour fonc-
tionner correctement, il est nécessaire de modéliser finement les communications car les
réseaux locaux sont en général beaucoup plus rapides que les réseaux à large échelle, il est
donc nécessaire de distribuer les tâches en prenant en compte les communications entre
processus de façon beaucoup plus avancée [FCM03].
1.1.3 Grid programming et systèmes peer to peer

Dans cette partie, nous allons décrire les caractéristiques des systèmes dits de “grid-
programming” et les systèmes pairs à pairs (P2P ou peer to peer). Le “grid-programming”
est un développement récent des systèmes parallèles et distribués qui se concentre sur les
systèmes à larges échelles répartis sur Internet ou d’autres réseaux vastes. Notre démarche
s’inscrit donc totalement dans ce mouvement. Nous allons d’abord décrire les approches
de partage pair à pair car elles présentent un intérêt pour nous, les utilisateurs partageant
leurs fichiers sont des particuliers, ce qui leur impose des règles que ne connaîtraient pas
des employés d’une société au sein d’un réseau sûr.
Les systèmes de partage de données pair à pair

Dans cette première partie, nous allons décrire les systèmes de partage de données
pair à pair puis nous présenterons un exemple de système pair à pair destiné à fournir des
services sous forme de composants au travers de l’Internet. Il est à noter qu’il existe aussi
29
Wide
Era
Network
Fig. 1.4 – Un exemple de “super cluster” de clusters
quelques systèmes de partage de puissance de calcul pair à pair, nous discuterons de ces
systèmes dans la section suivante.
Définition
On peut considérer que les systèmes que nous allons décrire dans la suite sont avant
tout des communautés d’utilisateurs, ce qui d’après Howard Rheingold [Rhe01] : “Les
communautés virtuelles sont des regroupements socioculturels qui émergent d’un réseau,
lorsqu’un nombre suffisant d’individus participent à ces discussions publiques, assez long-
temps et en y mettant suffisamment de cœur, pour que des réseaux de relations humaines
se tissent au sein du Cyberespace.”
On appelle système de partage “peer to peer” (P2P) un système qui permet à des
utilisateurs de partager leurs ressources directement. La plupart des systèmes P2P sont
30
des systèmes de partage de données. Les plus connus étant, outre le défunt Napster,
KAZAA, E-Donkey 2000 ou Morpheus.
Historique
Les systèmes pair à pair sont apparus avec Napster en mai 1999. Napster a aujourd’hui
disparu mais le nombre de ses héritiers est assez impressionnant. On compte Morpheus et
Kazaa, E-Donkey et Overnet. . . Ces systèmes ont tous plus ou moins le même but avec des
différences notables de fonctionnement. Certains d’entre eux utilisent “Gnutella” comme
modèle, d’autres sont légèrement différents. Nous allons décrire le fonctionnement des plus
importants.
Principaux systèmes et modèles

Après avoir défini le terme, nous décrirons le fonctionnement de Napster, après quoi
nous décrirons Gnutella, puis nous décrirons quelques systèmes spécifiques car leurs carac-
téristiques donnent de bonnes indications sur ce que doit ou ne doit pas faire un système
de partage.
Napster
D’une certaine façon, Napster est deux fois un précurseur. Non seulement, il a été le
premier service de partage de fichiers sur Internet mais sa disparition a poussé ses succes-
seurs à concevoir des technologies qui les mettraient à l’abri en cas de déboires du même
type. En effet cette disparition est la cause d’une bonne partie des évolutions techniques
qui caractérisent les autres systèmes. Napster était un système destiné à permettre le par-
tage de fichiers sonores (sous forme de MP3). Cette spécificité en a immédiatement fait la
cible de la RIAA (société de protection des droits sur la musique aux Etats-Unis). Napster
a disparu le 26 juillet 2000 suite à une décision juridique qui donna raison à la RIAA.
L’un des principaux défauts de Napster est la cause de cette disparition : Napster n’était
en fait seulement que très partiellement pair à pair comme on peut le voir sur la figure
1.5. En effet, chacun des fichiers partagés était indexé sur un système qui centralisait ces
informations. Les différents utilisateurs n’avaient donc qu’à se connecter à ce serveur pour
pouvoir indexer leurs propres fichiers partagés (ce qui permettait au autres utilisateurs de
les repérer) et de pouvoir trouver les fichiers désirés pour pouvoir les télécharger. Le télé-
chargement était ensuite effectivement pair à pair puisque l’utilisateur désirant un fichier
le téléchargeait directement de l’ordinateur de l’utilisateur le possédant. Cette centralisa-
tion a été la cause de la disparition de Napster. En effet, non seulement les gestionnaires
du système étaient en tort puisqu’ils connaissaient l’emplacement de fichiers illégaux et il
était facile de faire disparaître Napster, il suffisait d’éteindre le serveur central.
Afin de ne pas être pris en défaut de cette façon, les concepteurs de la seconde géné-
ration de systèmes de partage ont créé les premiers systèmes réellement “peer to peer”.
Gnutella
Gnutella [AH00, Rip01] est le système qui définit la deuxième génération de systèmes de
partage de données pair à pair. Il a été conçu par les équipes de Nullsoft, pour permettre le
partage de recettes de cuisine sur Internet. Avant que la direction d’AOL (le propriétaire
31
Client B
Client C Client A
on
ati
ex
Ind
Demande de fichier
Envoi du fichier
Serveur Napster
Adresse de A
Recherche
Client D
Client E
Fig. 1.5 – Architecture de Napster
de Nullsoft) comprenne les implications du programme présenté et le retire, il s’était

suffisamment disséminé pour que plus rien ne puisse être fait. Les logiciels utilisant le
protocole Gnutella ont été réalisés à partir du “back-engineering” (rétro analyse) sur le
logiciel d’origine.
Dans Gnutella, les serveurs centralisés ont disparu. Ici tous les utilisateurs sont serveurs
et clients.
Le principe est le suivant : lors d’une connexion au service de téléchargement (Mu-
tella ou Morpheus utilisent le protocole GNUtella), les utilisateurs se connectent avec un
serveur d’entrée lequel les met en communication avec un certain nombre d’autres utili-
sateurs (quatre ou cinq selon les services). Les serveurs-clients (appelés servents) vérifient
continuellement la présence de leurs correspondants en les “pingant” très souvent.
– Les requêtes sont anonymes et se transmettent par inondation (c’est-à-dire qu’elles se
32
transmettent de proche en proche jusqu’à avoir “inondé” tout le réseau d’utilisateurs

ou jusqu’à ce qu’à la fin de leur durée de vie TTL). Un message de requète ne peut
transiter que par un nombre maximum de sites, on appelle ce nombre le TTL.
– Les réponses (messages de type QueryHit) contiennent, elles, toutes les informations
nécessaires pour identifier et retrouver leur expéditeur, elles remontent le flux des
requêtes.
– Les téléchargements se font en utilisant http, ce qui permet de passer la plupart des
pare-feux. Il faut noter que les téléchargements utilisant http ne sont pas anonymes.
Dans la figure 1.6, nous décrivons l’entrée d’un nouveau client dans la communauté de
partage et une recherche de fichier lancée à partir du client dénommé A qui une réponse
positive sur le client F.
Arrivée d’un nouveau client
Nouveau
n
io
client 3
ex
2
nn
1
co
de
A
de
de
an
e
ss
m
De
re
Ad
Serveur
Client A
Un exemple de recherche
2 3
Client B Réseau de
1
partage
Client D
2 2
Client A
1 1 2
Client C
2
Client E
2
Client F
Retour « fichier »
Fig. 1.6 – Représentations de deux protocoles de Gnutella : l’arrivée d’un nouveau client
et une recherche de fichier
33
Aujourd’hui, il existe de nombreux programmes de “servents” Gnutella, le plus im-

portant d’entre eux est Morpheus mais ils permettent tous de se connecter aux mêmes
réseaux de partage.
Gnutella présente plusieurs inconvénients, mais le principal est le coût des communica-
tions ; en effet la méthode de répercussion des requêtes par inondation est très coûteuse en
communication (d’autant plus que les servents la reçoivent souvent plusieurs fois) ; elle est
de plus d’une efficacité limitée puisqu’il suffit que le document recherché soit trop éloigné
(au-delà du TTL) pour que le document ne soit jamais trouvé, alors qu’il est présent.
Kazaa
Les nouvelles moutures de Kazaa utilisent un autre protocole qui permet de corriger les
lacunes de Gnutella. Avec Kazaa, les requêtes ne sont plus transmises par “inondation” du
réseau et les nœuds ne sont pas égaux. Le principe est le suivant les meilleurs nœuds (ceux
qui retournent une réponse positive le plus souvent) sont reliés entre eux et forment une
épine dorsale (changeante puisque ces super hôtes restent des hôtes comme les autres) pour
tout le système, les autres utilisateurs sont connectés préférentiellement suivant une étoile
autour de ces hôtes. Cela permet de minimiser le nombre de messages lors des requêtes.
Enfin Kazaa permet le téléchargement multi sources. En effet, lors de la connexion à
Kazaa, chacun des fichiers partagés reçoit un identifiant (grâce à une fonction de hachage)
ce qui permet de reconnaître les fichiers identiques chez différents hôtes et de télécharger
en parallèle chez les différents hôtes (la fin du fichier chez l’un et le début chez l’autre par
exemple).
Overnet
Overnet est basé sur un concept différent du simple partage. Dans le cas d’Overnet,
les données sont “publiées” ce qui accélère énormément la recherche. Le principe est le
suivant :
– Chaque utilisateur reçoit un identifiant de 128 bits unique lors de sa connexion.
– Cet identifiant permet d’obtenir un certain anonymat des utilisateurs.
– Chacun des fichiers partagés reçoit aussi un identifiant unique de 128 bits.
– Le programme lance alors une recherche sur le réseau pour trouver l’utilisateur
dont le numéro ressemble le plus à celui donné à chacun de ses fichiers partagés et
indexe les fichiers chez les hôtes dont les numéros leurs correspondent. Cela permet
de retrouver très facilement un fichier et de réunir dans le même index toutes les
sources possibles de ce fichier.
– Pour faire une requête, il faut donc d’abord identifier le fichier. C’est-à-dire trouver
son identifiant ou un identifiant proche, en effet un identifiant proche permet de re-
trouver l’hôte qui l’indexe. On obtient ainsi rapidement un grand nombre de fichiers
semblables (c. a. d. dont l’identifiant est semblable).
Chord
Chord [SMK+ 01] est un projet du MIT qui devrait permettre d’améliorer encore les
résultats obtenus par Overnet. Ici, les identifiants sont obtenus à partir d’une table de
hachage partagée sur les hôtes lesquels sont eux aussi représentés de cette façon. Les hôtes
34
sont chaînés sur un anneau. Chaque fichier est indexé sur la machine dont l’identifiant
(produit lors du hachage) a la plus grande valeur tout en restant inférieur au sien. On peut
démontrer que l’on retrouve un fichier en log(n) messages avec n le nombre de nœuds.
Pour l’instant Chord est un prototype mais il peut permettre d’entrevoir les solutions
techniques qu’utiliseront les prochaines versions de ces systèmes. L’architecture de Chord
est représentée de façon simplifiée sur la figure 1.7.
Figure 2: An identifier circle consisting of the three

nodes 0, 1, 2 and 3. In this example, key 1 is located
at node 1, key 2 at node 3, and key 6 at node 0.
Tiré de : « Chord: A Scalable Peertopeer

Lookup Service for Internet Applications »
Fig. 1.7 – Extrait de l’article cité ci-dessus, une schématisation de l’architecture de Chord
Autres systèmes de dernière génération

D’autres systèmes, comme Skipnet [HJS+ 03], Kelips [GBL+ 03], présentent des caracté-
ristiques similaires à celles de Chord ou d’Overnet. Ils ont cependant leurs caractéristiques
propres. Nous ne les décrirons pas ici. Il faut cependant noter qu’ils obtiennent générale-
ment des résultats légèrement meilleurs qu’Overnet (auquel ils se comparent) même s’ils
suivent les mêmes principes. Cependant, ces systèmes ne sont pas largement utilisés et ne
constituent pas de percées technologiques majeures.
Avantages et limites des systèmes de partage de données pair à pair

Les systèmes de données “peer to peer”, présentent des caractéristiques très intéres-
santes :
35
– Ils sont génériques : même s’ils sont plus efficaces pour retrouver certains types
de fichiers plutôt que de d’autres, ils peuvent être utilisés dans des situations très
vastes.
– Ils sont très robustes : même dans le cas des plus anciens d’entre eux, les problèmes
légaux de Napster ont assuré que l’existence de serveurs centraux était minimale.
Cela minimise les cibles potentielles pour une agression informatique contre le réseau
dans son ensemble. Les architectures ainsi développées sont très intéressantes.
– Ils sont assez anonymes : l’anonymat n’est pas garanti sur ces systèmes puisque
le téléchargement n’est souvent pas anonyme. Cependant, l’anonymat lors des re-
quêtes est un modèle intéressant puisqu’il nous paraît une condition sine qua non
du bon fonctionnement d’un système de partage de ressources entre des utilisateurs
moyennement coopératifs.
Ils ont bien sûr quelques limites évidentes. Partager des données est très différent de
partager des ressources computables. Leurs modèles pêchent donc sur les questions de
sécurité mais aussi de messages. Garder les connaissances sur le système dans son ensemble
à jour est extrêmement coûteux mais comme les transferts se font directement, les mises
à jour d’informations ne sont pas trop lourdes. Les performances du système dans son
ensemble ne sont donc pas trop diminuées. Enfin ces modèles ne répondent évidemment
pas à la question du modèle à employer pour permettre la représentation des qualités des
machines ni à celle de la forme des tâches distantes.
Les autres systèmes de Grid

Partager des données sur un réseau présente déjà certaines difficultés sérieuses. Mais
la difficulté augmente encore quand il s’agit de partager d’autres ressources. Cependant
l’idée n’est pas nouvelle. Fox a proposé d’utiliser les ressources distribuées sur Internet
pour faire du calcul scientifique [FG01, Gea02]. Ces applications sont très spécifiques mais
il serait possible d’utiliser ces ressources pour d’autres applications. Les applications des
générations précédentes étaient monolithiques (c’est-à-dire qu’elles étaient programmées
en utilisant un unique langage de programmation, qu’elles tournaient sur un unique ordi-
nateur qui pouvait être une mainframe multiprocesseur et qu’elles recevaient leurs données
des utilisateurs et terminaient en renvoyant des données à ces mêmes utilisateurs). L’uti-
lisation de composants logiciels et les nouvelles applications liées aux réseaux (comme
l’intégration verticale en entreprises virtuelles [FKNT02]), ont profondément modifié cet
état de fait. Enfin la distribution des ressources et leur sous utilisation générale ouvre
de nouvelles perspectives. Commencent donc à apparaître des applications intégrées et
distribuées à grande échelle.
SETI@HOME
L’une des premières d’entre elles, SETI@HOME (Search for Extra Terrestrial Intel-
ligence AT HOME) est sans doute la plus connue. SETI@HOME est une application
de calcul répartie. Son but est d’utiliser des ordinateurs sous utilisés pour analyser des
données spatiales. Le système que nous allons décrire ici n’est pas vraiment un système
peer to peer. En effet, il y a un serveur centralisé qui distribue les calculs à réaliser sur
l’ensemble des utilisateurs. Ce programme connaît pourtant une partie des difficultés ca-
36
ractéristiques des systèmes largement distribués, comme l’hétérogénéité des hôtes et leur
instabilité. C’est de plus l’un des précurseurs des systèmes réunis généralement sous la
dénomination de “grid programming”.
SETI se présente comme un économiseur d’écran, il se lance automatiquement quand
l’ordinateur sur lequel il est installé connaît une période d’inactivité. Après quoi il se
connecte au serveur de SETI lequel lui envoie les données à analyser. L’architecture de
SETI ressemble à celle de Napster, c’est un système en étoile autour des serveurs de
l’agence. Dans ce cas les problèmes qui ont découlé de cette architecture durant l’existence
de Napster sont sans importance vu les buts de SETI.
Cette architecture présente cependant quelques graves problèmes :
– Elle est extrêmement fragile car si le serveur de SETI est inaccessible, tout le système
disparaît. Dans le cas de SETI, cela n’a pas d’importance car si le serveur de SETI
est inaccessible, l’application n’a plus de raisons d’être. Ce type d’architecture paraît
cependant bien peu robuste pour d’autres applications.
– Elle est construite pour une application spécifique et est difficilement adaptable à
d’autres cas.
GLOBUS et LEGION
Le Globus Metacomputing ToolKit [FK] est un ensemble d’outils pour la conception
de systèmes distribués. On retrouve 7 groupes de services différents, GRAM (gestion de
ressources et allocation des processus), Nexus (fonctionnalités de communications), GSI
(gestion des problèmes de sécurité, qui dans les premières versions se limitait à l’authentifi-
cation), MDS (surveillance de l’état des différents composants systèmes et des processus),
GASS (accès aux données distantes par l’intermédiaire d’interfaces séquentielles et paral-
lèles) et GEM (construction, mise en commun et utilisation des exécutables).
L’architecture choisie dans Globus est une architecture structurée de façon souple,
le système est partagé en “domaines” qui sont séparément gérés par des GRAM qui
peuvent avoir des formes diverses (l’API GRAM fournit des gestionnaires de ressources
allant du plus simple, un “fork”, jusqu’au plus complexes (Network Queuing Environment,
CONDOR, EASY-LL. . . ). Les relations entre les utilisateurs et les GRAMs se font par
l’intermédiaire de brokers. Les ressources sont décrites en utilisant un langage spécifique
appelé Ressource Specification Language (RSL). RSL est un langage possédant plusieurs
niveaux d’abstraction, ainsi, un utilisateur décrit ses besoins de façon abstraite, le broker
spécialise les descritpions des besoins, et finalement les GRAMs reçoivent une version de
très bas niveau de ces besoins. Cette dernière description permet de sélectionner facilement
une machine.
Globus permet de distribuer une application sur une grille de forme très diverse en
essayant d’utiliser au mieux chaque ressource individuelle. Globus est un système par
couches. On peut toujours accéder aux couches les plus basses quand les besoins en terme
d’efficacité rendent nécessaire une programmation optimisée au plus bas niveau, mais le
niveau de programmation est normalement assez abstrait. Globus offre des services d’un
tel niveau d’abstraction que sur de nombreux points, on peut considérer qu’ils tiennent
en fait de la plateforme de développement (Globus garantit la cohérence des données
partagées en écriture, etc.).
37
Legion [WWHG] est un système de partage d’objets à très grande échelle. C’est midd-
leware qui plaque sur un ensemble d’objets actifs communiquant par appels de méthodes
à distance l’illusion d’une unique machine virtuelle. Legion est construit autour d’une
architecture constituée de plusieurs proxys lesquels redirigent les demandes vers les hôtes
hébergeant les objets concernés. Les objets peuvent migrer mais en fait, les migrations se
font par clonage local. Comme Legion n’est pas centralisé, le système est parfaitement sca-
lable. Les objets de Legion peuvent être actifs, inactifs ou sauvegardés sur le disque. Legion
pourrait être considéré comme un système de partage de données . . . actives. [WWHG]
nous montre que les résultats obtenus par Legion dans le cas d’invocations de procédures
à distance sont excellents.
Globus et Legion sont des systèmes dont les buts sont différents. D’ailleurs, Legion
peut être construit en utilisant les méthodes Globus. Ces deux systèmes représentent
peut-être les deux solutions de partage les plus avancées aujourd’hui. Il existe cependant
d’autres solutions de partage qui peuvent être soit des projets en cours de réalisation soit
des méthodes de conception d’applications distribuées. Il est à noter que même sorties de
leur contexte, certaines caractéristiques de ces deux systèmes restent très intéressantes.
Il faut aussi noter que les API des bibliothèques du programme Globus répondent à un
grand nombre des besoins de toute application partagée.
Les systèmes de partage

Après l’apparition de SETI, sont apparus plusieurs modèles de partage de ressources
à grande échelle. Pour l’instant, les applications de ces systèmes se limitent à des ap-
plications scientifiques (calculs de mécanique des fluides, etc.), ils restent donc de même
nature que SETI. On retrouve dans ces systèmes les concepts décrits dans la section sur les
clusters, comme les plateformes à mémoire partagée distribuée ou les systèmes à mémoire
séparée. Alors que sur les ordinateurs multiprocesseurs, la mémoire partagée permet des
gains de vitesse, la mémoire partagée distribuée, elle, ne permet qu’une simplification de
la conception des applications distribuées. En effet, la conservation de la cohérence de la
mémoire partagée consomme de la puissance de calcul.
Il existe un grand nombre de bibliothèques d’outils adaptés à la conception de systèmes
“grid”. Nous citerons MagPie [D.02], MPICH-G2 [MPI] qui découle des principes décrits
dans MPI 2 (voir clusters), ainsi que MPI-connect, MetaMPICH, PACX-MPI ; etc. qui
découlent tous de la même origine. Cependant, l’approche du “grid programming” par les
bibliothèques de fonctions est une approche très bas niveau et assez difficile. Pourtant,
il est intéressant de noter leur existence car des systèmes comme Globus les appliquent
(Globus utilise les fonctions de la bibliothèque MPICH-G2 dans ses fonctions d’authen-
tification et d’allocation de ressources, par exemple). Chacune de ces bibliothèques a ses
spécificités, par exemple, PACX-MPI a été conçu pour permettre d’associer au sein d’un
grid, des superordinateurs (Crays et Intel Parangons).
La plupart des systèmes de “grid-programming” sont basés sur le concept de “middle-
ware”. Le middleware est une couche intermédiaire entre le système et le concepteur de
l’application. Il simplifie la conception en rendant transparent un certain nombre de dif-
ficultés (par exemple en permettant l’utilisation d’une mémoire partagée distribuée (voir
clusters).
38
On peut considérer trois types de middlewares, les “Network-enabled servers”, les “fra-
meworks” et les technologies à base de composants [D.02].
Network-enabled server
Les systèmes NES, comme Netsolve [ADSV03, HBDV03] peuvent être perçus comme
des systèmes de calcul à distance destinés à permettre de distribuer les calculs numé-
riques. Ils permettent une conception relativement simple de systèmes tout en offrant la
possibilité d’utiliser les ressources spécifiques de chaque hôte (superordinateurs, capacités
spécifiques . . . ). Ils permettent d’implanter toutes les applications classiques et scalables
et permettent d’implanter tous les types de synchronisations entre les tâches.
Framework
D’après Laforenza [D.02], on peut considérer que les “frameworks” constituent des “en-
sembles d’outils logiciels qui facilitent le développement et l’exécution d’une application”.
Ce sont donc des ensembles d’outils d’aide à la programmation d’applications “grid pro-
gramming”. Nous pourrions citer Cactus comme faisant partie de cette catégorie. Cactus
[ABD+ 01] est un ensemble comprenant une plateforme qui fonctionne sur la plupart des
systèmes informatiques, un langage de programmation orienté objets qui permet de faire
l’interface entre des fonctionnalités écrites dans la plupart des langages classiques. Cactus
permet l’utilisation de la plupart des technologies développées pour les systèmes de “grid”
(comme le Globus Metacomputing Toolkit (voir Globus), des interfaces Web et divers
outils de visualisation. . . ).
Les systèmes à base de composants

Les systèmes à base de composants n’ont pas été conçus pour le grid programming. La
programmation orientée composants est une forme d’encapsulation destinée à permettre
le recyclage du code informatique et son évolution. Cependant, les systèmes à base de
composants présentent de grands intérêts dans le cas d’applications distribuées sur des
ordinateurs hétérogènes. En effet, en concevant une application comme un ensemble de
composants logiciels distincts, il devient simple de distribuer les tâches sur des ordinateurs
différents : il n’est plus nécessaire que les différents composants soient construits pour
fonctionner sur toutes les machines, il suffit de construire chaque composant pour le type
de machine sur lequel il sera installé, il devient possible de construire un composant de
façon à ce qu’il utilise de façon optimale les caractéristiques de l’ordinateur sur lequel il va
tourner. Il suffit ensuite de construire l’interface entre les différents composants distants.
Il devient de plus en plus simple de faire évoluer le système ou la plateforme de travail,
il suffit de changer les composants inutiles tout en gardant leurs entrées et leurs sorties.
Quand un hôte est remplacé, il suffit de reconstruire les composants qu’il abritait. Ainsi,
les méthodes de programmation par composant permettent une utilisation optimale des
fonctionnalités spécifiques de chaque ordinateur de la grille.
Les intérêts de la programmation par composant pour la conception et l’implantation
de systèmes “grid” sont très nombreux, mais pour en profiter à plein, il est nécessaire de
construire une bonne interface entre les différents composants.
Plusieurs technologies permettent cela :
39
– CORBA (Common Object Request Broker Architecture) Component Model [COR]

est une extension de CORBA incluse dans la version 3 des spécifications [OMG03].
CORBA n’a été spécifiquement conçu ni pour le grid programming ni pour la
programmation à base de composants. CORBA permet l’interfaçage de systèmes
construits avec des langages différents sur un système distribué hétérogène. C’est
un système client serveur conçu par l’OMG qui permet de faire travailler ensemble
des applications différentes (programmées dans des langages différents) installées sur
des ordinateurs hétérogènes en permettant le transfert d’objets de l’une à l’autre
en utilisant IIOP, un protocole défini dans ce but. Il faut noter qu’il est néces-
saire de programmer les classes pour les deux applications ; seules les instances sont
transmises. CCM offre des fonctionnalités permettant une meilleure reconfiguration
dynamique des applications utilisant CORBA. CCM reprend la plupart des carac-
téristiques des Java Beans [SUN04a].
– Il existe aussi d’autres bibliothèques, comme EJB qui permet de suivre la vie d’une
application distribuée en entreprise de la conception à l’implantation. EJB était à
l’origine basé sur les RMI [SUN04b] de JAVA, mais les dernières versions permettent
l’utilisation de CORBA. L’aide à la conception de middleware permet aux concep-
teurs de se concentrer sur des problèmes de plus haut niveau. On trouve aussi DCOM
(Distributed Component Object Model) [Mic96] qui représente une des failles les
plus classiques des produits Microsoft [Gib03] ou .NET [Mic](toutes deux conçues
par Microsoft). .NET est sans doute une des plateformes de développement les plus
abouties, à la fois en matière d’interopérabilité, de sécurité informatique et d’aide
au déploiement à très grande échelle.
Il est cependant à noter que ces travaux concernent plutôt les méthodes pour créer une
application distribuée que pour distribuer des applications. Le but n’est pas ici de partager
des ressources mais de concevoir des applications partagées.
Il faut aussi noter l’existence des services Web utilisant XML comme langage de des-
cription. Ces services sont en fait des fonctions accessibles décrites selon un standard via le
réseau. Il devient possible de concevoir des applications en utilisant des modules d’origine
très diverse. Nous citerons SOAP, UDDI, WSDL qui sont tous des standards de services
et de protocoles pour les services Web.
Enfin, cumulant ces différents éléments, il existe des projets (comme GrADS [BCC+ 01])
de conception d’un langage unique (associé à des compilateurs) pour permettre la concep-
tion d’applications scientifiques distribuées utilisant de façon optimale les ressources ac-
cessibles au sein d’un réseau à grande échelle.
Conclusion
Tout au long de cette section, nous avons rencontré deux types de projets fondamen-
talement différents :
– Des systèmes de partage de données (comme Kazaa ou Napster)
– Des méthodes de conception d’applications scientifiques massivement distribuées et
des applications scientifiques distribuées.
Il existe bien sûr quelques applications industrielles, mais elles sont rares. Comme nous
l’avons rappelé pour SETI@HOME, les applications scientifiques ont des caractéristiques
40
1.2. Architectures agents
qui simplifient le problème. il faut de plus noter que ces applications distribuées ne sont
pas très souples. Même Globus ou Legion ne permettent pas réellement à des utilisa-
teurs privés ou moyennement coopératifs de partager des ressources efficacement. En effet
Legion est très rigide dans son mode de programmation et même Globus qui est le plus
souple ne permet pas de répondre aux exigences d’un réel système de partage (confidentia-
lité minimale, système complètement réparti . . . ). Il faut de plus noter qu’apparemment
aucune d’entre elles ne prend en compte la mobilité du code qui serait nécessaire pour
réaliser de la distribution de charge en temps réel.
1.2 Architectures agents

Avant de s’intéresser plus spécifiquement aux systèmes de partages agents, il est né-
cessaire de présenter les agents et les Systèmes Multiagents (SMA) plus en profondeur.
C’est ce que nous allons faire dans cette section.
1.2.1 Les agents et les SMA

Les concepts sous-jacents aux technologies agents sont apparus il y a une trentaine
d’années ; pourtant leur développement n’a réellement commencé qu’avec le développe-
ment de l’Internet [BZW98]. Les technologies agents sont difficiles à classer, en effet elles
sont nées de plusieurs influences : l’Intelligence Artificielle, l’informatique distribuée et
même la robotique.
Il est difficile de donner une définition universelle des agents car les avis divergent sur
ce qu’elle devrait contenir.
Il faut de plus noter que la définition d’un agent n’est pas suffisante en soi : les agents
se définissent par leurs interactions avec leur environnement lequel contient normalement
d’autres agents. Les programmes basés sur une communauté d’agents sont appelés des
Systèmes Multiagents (SMA), nous devrons donc aussi éclaircir ce terme. Comme nous
allons le montrer plus loin les agents et SMA ont des utilisations et des intérêts divers. Ils
peuvent être vus comme un paradigme de programmation pour concevoir des systèmes
de résolution de problème, mais ils ont aussi certaines caractéristiques qui les rendent
particulièrement adaptés à certaines tâches.
Définitions
Comme nous l’avons précisé précédemment, il n’y a pas de définition universelle des
agents ou des systèmes multiagents, nous en avons malgré tout retenu une, celle de J.
Ferber [Fer95] :
Définition : on appelle agent une entité physique ou virtuelle
a. qui est capable d’agir dans son environnement,
b. qui peut communiquer directement avec d’autres agents,
c. qui est mue par un ensemble de tendances (sous la forme d’objectifs individuels ou
d’une fonction de satisfaction, voire de survie, qu’elle cherche à optimiser),
41
d. qui possède des ressources propres,

e. qui est capable de percevoir (mais de manière limitée) son environnement,
f. qui ne dispose que d’une représentation partielle de cet environnement (et éventuelle-
ment d’aucune),
g. qui possède des compétences et offre des services,
h. qui peut éventuellement se reproduire,
i. dont le comportement tend à satisfaire ses objectifs, en tenant compte des ressources
et des compétences dont elle dispose, et en fonction de sa perception, de ses représen-
tations et des communications qu’elle reçoit.
Nous en retiendrons plusieurs caractéristiques,
– d’abord les agents se caractérisent par une certaine autonomie qui est sous-jacente
à leurs tendances et à leur capacité à arriver à leurs fins soit en interagissant avec
l’environnement soit en communiquant avec d’autres agents,
– une certaine “cognitivité” liée à la qualité de leur connaissance de leur environne-
ment mais aussi à leur capacité à réaliser des buts complexes sans interventions
extérieures.
Il faut aussi noter qu’il existe une caractéristique importante des agents qui n’est pas
mise en valeur dans la définition ci-dessus, la coopération. La coopération est une caracté-
ristique importante d’un système d’agents, est-ce que les agents coopèrent naturellement,
uniquement s’ils sont forcés, est-ce qu’ils sont en compétition ? Les agents peuvent aussi
être classés selon leur niveau de coopération avec les autres agents (ne fût-ce au détriment
de leurs propres buts). On peut classer les agents selon ces trois caractéristiques.
Nous allons donner quelques exemples représentatifs des différents axes.
– Le robot Pathfinder est le meilleur exemple d’autonomie, en effet, il interagit phy-
siquement avec l’environnement martien, il n’est quasiment pas guidé mais peut
néanmoins communiquer avec les humains basés sur terre.
– Les exemples d’agents cognitifs les plus caractéristiques se retrouvent essentielle-
ment dans la science fiction, les IA des films comme celles de Wargame ou de 2001
l’Odyssée de l’Espace . . . représentent les plus aboutis des agents cognitifs, leur re-
présentation du monde est extrêmement complexe, ils prennent des décisions dont
les conséquences sur l’avancement de leurs buts sont très difficiles à prévoir . . .
– Les agents les plus coopératifs sont les programmes qui imitent les fourmis [DMC96,
DS01], leur phéromones sont destinées à permettre aux autres agents de trouver de
la nourriture et tous les agents ont le même but, nourrir la fourmilière.
Ces axes pourraient être complètement indépendants, il apparaît cependant que l’es-
pace n’est pas complètement couvert par les agents machines. Les agents permettent
l’existence d’applications informatiques très spécifiques.
Il est classique de classer les agents selon deux catégories, les agents réactifs et les
agents cognitifs, nous allons maintenant décrire ces deux catégories.
La coopération et l’interaction entre les différents agents nous amènent aux SMA.
Un SMA est une communauté d’agents plus ou moins coopératifs baignant dans le même
environnement, même si chacun des agents n’en a une connaissance que partielle. Les SMA
sont la base de la programmation agent, en effet, un agent seul peut être assimilé à un
42
système expert, c’est la multiplicité des agents et leurs interactions qui font la spécificité
du paradigme agents. Ferber définit ainsi système multiagents [Fer95].
Définition : on appelle système multi-agent (ou SMA), un système composé des
éléments suivants :
a. Un environnement E, c’est-à-dire un espace disposant généralement d’une métrique.
b. Un ensemble d’objets O. Ces objets sont situés, c’est-à-dire que, pour tout objet, il est
possible, à un moment donné, d’associer une position dans E. Ces objets sont passifs,
c’est-à-dire qu’ils peuvent être perçus, créés, détruits et modifiés par les agents.
c. Un ensemble A d’agents, qui sont des objets particuliers (A ⊆ O), lesquels représentent
des entités actives du système.
d. Un ensemble de relations R qui unissent des objets (et donc des agents) entre eux.
e. Un ensemble d’opérations Op permettant aux agents de A de percevoir, produire,
consommer, transformer et manipuler des objets de O.
f. Des opérateurs chargés de représenter l’application de ces opérations et la réduction
du monde à cette tentative de modification, que l’on appellera les lois de l’univers.
Cette définition est très large et notre monde peuplé d’humains entre parfaitement
dans la définition. Dans la suite, cependant, nous nous intéresserons uniquement aux SMA
informatiques. Ni les robots ni les êtres humains ne rentrent dans notre étude. Même en
réduisant notre sujet aux agents et aux SMA informatiques, le sujet reste vaste.
Les systèmes multiagents peuvent être de natures très différentes, certains d’entre
eux sont des applications informatiques complètes, d’autres sont de simples plateformes
offrant à des agents un certain nombre de services. Nous montrerons des exemples dans les
parties suivantes. Ces deux types de systèmes (et toutes les nuances qu’elles permettent)
entraînent une très grande diversité des formes des systèmes multiagents, lesquels peuvent
offrir des services (qui réunissent les relations, les objets et les opérations de la définition
précédente).
Tous pourtant doivent fournir quelques services génériques, comme les communications
entre les agents (si possible synchrones et asynchrones).
Agents cognitifs et réactifs

Au cours des années quatre-vingts, est apparue une séparation entre des agents dits
cognitifs et des agents dits réactifs. Les agents cognitifs sont difficiles à définir autrement
que par le fait qu’ils ne sont pas réactifs, nous allons donc d’abord décrire les agents
réactifs.
Les agents réactifs

Le concept d’agents réactifs a été créé pour contourner la difficulté de la représentation
de l’environnement interne à chaque agent. Il est basé sur l’idée qu’un comportement
rationnel et intelligent résulte des interactions de l’agent avec son environnement. Les
agents réactifs n’utilisent pas de représentation symbolique de leur environnement, leurs
décisions ne sont pas le résultat de manipulations syntaxiques de telles représentations.
43
Ce type d’agent est nommé “réactif” car il est souvent perçu comme simplement réagis-
sant aux stimuli de son environnement sans réflexion à ce sujet. Donc des agents réactifs
placés dans un environnement constant n’agissent plus. Les agents réactifs n’étant pas
dotés de représentation interne de leur environnement, ils ne sont pas capables d’actions
complexes seuls. Leur puissance réside donc dans leur nombre. Les SMA basés sur des
agents réactifs doivent donc contenir énormément d’agents.
Les agents cognitifs

Les agents cognitifs, à l’opposé des agents réactifs sont dotés d’une représentation in-
terne de leur environnement. Il en existe de plusieurs catégories, agents BDI, agents basés
sur la programmation logique . . . On introduit aussi, pour ces agents les concepts de rôles
car ici un agent peut avoir plusieurs rôles en fonction des agents avec lesquels il interagit.
Cela peut être expliqué très simplement en considérant que le même individu peut être
tour à tour le mari de sa femme, l’employé de sa société et le collaborateur de son pa-
tron. Nous reprendrons ces concepts dans la partie traitant des méthodes de conception
orientées agents.
Les agents cognitifs sont des agents beaucoup plus complexes et autonomes. Les SMA
basés sur ces agents peuvent être formés de quelques agents.
Une classification pertinente ?

On peut considérer que les agents cognitifs sont les agents “intelligents”, basés sur l’ap-
plication de concepts de sociologie et de psychologie et les agents réactifs sont les agents
“idiots” basés sur l’étude des sociétés d’insectes. Pourtant cette séparation est moins claire
qu’il n’y paraît. Les agents réactifs les plus simples n’ont pas de représentation interne de
leur environnement. Ils sont seulement programmés pour réagir à des stimuli extérieurs.
Ces réactions sont le fait d’un codage en dur plutôt que d’une représentation abstraite
mais ces stimuli et les réactions associées peuvent être considérés comme une représenta-
tion extrêmement simple de leur environnement. Ainsi la limite entre les agents réactifs et
cognitifs est en fait assez floue, d’autant plus que la puissance croissante des ordinateurs
ainsi que les possibilités ouvertes par l’informatique distribuée permettraient de concevoir
des systèmes constitués de milliers d’agents “cognitifs”.
1.2.2 quelques applications caractéristiques des SMA

Les SMA comme méthodes de résolution de problèmes distribuée
Il faut commencer par noter que les SMA s’avèrent normalement plus lents que les sys-
tèmes conventionnels (ne serait-ce que parce que l’encapsulation et le niveau d’abstraction
des messages augmente le coût des communications entre les diférents processus). Huhns
et Stephens dans [ML99] rappellent aussi que les systèmes distribués sont algorithmi-
quement moins performants que les systèmes centralisés. Or les SMA sont distribués à
l’extrême puisque les agents ne partagent rien. Pourtant distribuer les systèmes offre
d’immenses avantages car, si l’on perd en rapidité au niveau de l’algorithme, on gagne
beaucoup en puissance de calcul. Construire des SMA sur des systèmes monoprocesseurs
entraîne une perte des deux côtés, on ne gagne pas de puissance de calcul et on perd au
44
niveau algorithmique. Le très haut niveau d’encapsulation des agents freine sans doute
encore plus les SMA. Pour concevoir des SMA efficaces, il est donc nécessaire de profiter
au mieux des avantages qu’offrent le parallélisme naturel et l’encapsulation caractéristique
des systèmes à agents.
Les systèmes multiagents peuvent être une solution informatique à de nombreux pro-
blèmes. Dans certains cas, les systèmes multiagents permettent de rendre la conception du
programme de résolution de certains problèmes beaucoup plus simple que d’autres para-
digmes de programmation. Les systèmes multiagents peuvent même s’avérer plus efficaces
que des méthodes classiques dans certains cas et ce parce qu’ils permettent d’approcher
les problèmes à une autre échelle (par exemple, les SMA permettent d’étudier les flux
au niveau des individus (particules ou personnes) pour lesquels les lois sont très simples
(principe fondamental de la dynamique, chocs élastiques . . . ) plutôt qu’au niveau des cou-
rants (comme dans la mécanique des fluides) où les équations différentielles deviennent
insolubles. C’est pour cette raison que les SMA ont servi pour prédire les mouvements de
foule lors de la conception du stade de France [Mus00]. Le paradigme agent offre une en-
capsulation très importante, permet de construire un niveau de sécurité au niveau le plus
faible de granularité et est naturellement adapté à la conception d’applications parallèles.
Les plateformes SMA comme lieux de rencontre

Autant, il existe des solutions alternatives aux agents pour la résolution distribuée
de problèmes autant certaines applications ne peuvent être résolues que par des modèles
agents. Les agents permettent de concevoir des applications particulières comme des pla-
teformes de marché virtuelles. Les agents ont aussi permis l’émergence de certains types
de jeux vidéo comme les jeux massivement multi joueurs.
Les applications de commerce électronique utilisent naturellement les systèmes basés
sur des technologies agents. En effet les différents protagonistes d’une action commer-
ciale (les acheteurs et les vendeurs, par exemple) n’ont pas tous des buts compatibles
et même si certains ont les mêmes buts, ils n’ont pas nécessairement la même stratégie
pour atteindre ce but. Les technologies agents permettent donc de construire des systèmes
destinés à obtenir un compromis entre des utilisateurs différents [Leb03], [Syc88, Syc89],
[VEFS01], les systèmes multiagents permettent de simuler des enchères en prenant en
compte les stratégies des divers acteurs [HW98, HW01]. Les agents peuvent aussi rem-
placer les acteurs humains dans les processus d’enchères et suivre des stratégies complexes
[GFGRA98]. De part leur nature, ils sont la solution la plus logique pour représenter les
intérêts d’un utilisateur spécifique quand ils sont confrontés à ceux des autres. Les sys-
tèmes multiagents ouvrent donc la voie à de nouvelles applications informatiques pour
le commerce en ligne, comme la négociation automatique et en temps réel de services
ou de biens pour les utilisateurs. Ces systèmes ne servent pas seulement de plateforme
pour des simulations mais peuvent être de réels vecteurs d’échanges. D’après [BZW98], le
commerce par l’intermédiaire d’agents représentera 19 millions de dollars US en 1996, 357
millions en 1998 et 4,6 milliards en 2006. Ces applications ne représentent que quelques
pourcents des applications des systèmes multiagents, mais elles sont symptomatiques des
applications spécifiquement agents.
Les jeux vidéo nous donnent un autre exemple : les personnages non joueurs (PNJ)
45
des jeux de rôle en ligne (c’est-à-dire les “habitants” du monde du jeu qui ne sont pas
gérés par les joueurs mais par les serveurs) pourraient être gérés par un système cen-
tral ; c’est très efficace pour permettre l’existence d’une trame scénaristique mais c’est
ingérable quand des milliers de PNJ cohabitent dans le jeu avec des milliers de joueurs.
L’utilisation d’agents pour gérer chacun des personnages permet les distribuer facilement
et facilite grandement leur gestion (ils vaquent à leurs occupations et tentent de remplir
leurs buts). Bien sûr cela ne permet pas de gérer les personnages critiques d’un scénario
mais permet la gestion des personnages secondaires. De plus, l’utilisation de ces tech-
niques permet de gérer les personnages des joueurs absents, au moins de façon minimale.
Sans cela, les personnages des joueurs absents disparaissaient corps et biens du monde du
jeu, ce qui pouvait poser quelques problèmes de cohérence. Il devient possible, avec les
SMA, de résoudre ce type de problèmes (ces techniques sont utilisées dans divers jeux (de
Neverwinter Nights à Everquest).
Cependant programmer des systèmes multiagents n’est pas simple et s’ils permettent
ou facilitent la conception de certaines applications, ils apportent quelques difficultés
supplémentaires. C’est à cause de cela que l’on trouve plusieurs méthodes de conception
de systèmes multiagents.
1.2.3 Le code mobile et les agents mobiles

Notre système de distribution et de partage de charges est basé sur des “agents mobiles”
[FSS03b, KZ97, Pic01, BHRS98, CHK94]. On appelle agent mobile un agent logiciel qui
peut migrer d’un ordinateur vers un autre.
Cela demande l’utilisation de technologies dites de “code mobile” [HCF+ 94, CG98,
Car99]. Le code mobile peut tourner sur un ordinateur, s’arrêter puis migrer vers un autre
ordinateur au travers du réseau et reprendre son travail. La solution la plus simple pour
obtenir un résultat de ce type pourrait être dénommée “clonage faible d’agents”. C’est le
type de solution que l’on pourrait obtenir avec CORBA ou en utilisant de simples envois
de messages par sockets.
Prenons par exemple le clonage faible d’un objet dénommé 0. Deux composants lo-
giciels, que nous appellerons serveurs - l’un sur la machine Destination, l’autre sur la
machine Expéditeur- commencent le processus de migration en créant une nouvelle ins-
tance de la classe de O sur l’ordinateur Destination. Appelons cette instance O’. Le serveur
expéditeur envoie ensuite la valeur de toutes les variables de O au serveur destinataire
qui les recopie dans O’. O’ est dès lors une copie de O. Une fois cette copie réalisée, il
suffit d’effacer O, on peut alors considérer que O a migré de sa machine expéditrice vers
sa machine destinataire puisque il n’est plus sur la première alors qu’il existe maintenant
une copie de lui sur la seconde machine. Cet exemple est aussi présenté dans la figure 1.8.
Cette solution est la plus simple mais elle présente de nombreuses limites (et aussi
quelques avantages). La première limite est que les classes migrantes doivent être pré-
sentes non seulement sur la machine source mais aussi sur la machine destination dès
l’implémentation. Cela limite grandement les utilisations potentielles de ce type de mi-
gration. En fait cette solution peut seulement être utilisé dans le cadre de petits systèmes
fermés du type résolution de problèmes distribuée. Cela risque d’être lent puisque créer
une nouvelle instance d’une classe peut être relativement long d’autant plus qu’elle ne
46
Ordinateur Ordinateur
Expéditeur Message 1 : créer un Destinataire
objet
O’ O’ =vide
O (v1 = x1)
(………)
(vn = xn)
Classe Classe
C C
Expéditeur Message 2 : contenu de Destinataire
l’objet
O’ O’ =x1….xn
O (v1 = x 1)
(……..)
(vn = xn)
Classe Classe
C C
Fig. 1.8 – Un exemple de clônage faible d’un objet O de classe C
sera sans doute pas en mémoire et qu’il faudra donc aller la chercher sur le disque.
Cette méthode peut, de plus, être difficile à implanter sur des systèmes hétérogènes
puisque les classes migrantes doivent être présentes sur la machine source et sur la machine
destination. En effet, si ces machines sont différentes, il est nécessaire d’avoir programmé
deux classes parfaitement équivalentes sur ces deux ordinateurs. Comme les deux ordina-
teurs sont différents, ces deux classes n’ont pas le même code. En fait, les deux classes
peuvent être complètement différentes, elles doivent seulement avoir les mêmes variables.
Ainsi on peut considérer que ce type de migration est plus proche de la communication
d’informations entre deux objets similaires que de la véritable migration. En contrepartie,
cette méthode peut être implantée sur un système hétérogène aussi longtemps que les
47
ordinateurs sont capables de communiquer (même si c’est seulement par E-mail) et si le

code a été réécrit pour chacun des différents ordinateurs.
La mobilité faible
La mobilité faible est très similaire au clonage décrit précédemment. Ici la migration
suit les règles suivantes : l’objet migrant utilise certaines méthodes spécifiques qui peuvent,
par exemple, découler des RMI en JAVA pour créer une nouvelle instance de sa propre
classe sur l’hôte destination (même si celui-ci ne connaissait pas la classe au préalable).
Il copie ensuite son contenu dans cette nouvelle instance distante. Dans ce cas, comme
dans le précédent, il n’y a pas de réelle migration puisque l’objet n’est pas complètement
transféré (tous les calculs qui seraient toujours en cours au moment de la migration seront
perdus et devront être relancés depuis le début sur la machine destination). La mobilité
faible, contrairement au clonage décrit précédemment, exige théoriquement l’homogénéité
des machines concernées puisque du code écrit pour la machine source est transmis à la
machine destination (elles doivent donc être compatibles).
Il existe différentes variantes de la mobilité faible. Les RMI, par exemple, permettent
de créer une instance d’une classe locale sur une machine distante et permettent donc
la migration d’objets. Il faut pour cela lancer une méthode de clonage sur une machine
distante. Nous pouvons clairement penser à utiliser cette méthode comme solution pour
la résolution du problème du clonage partiel pour la distribution de charge [SSCJ98],
mais elle peut aussi permettre la “dissolution” d’un objet sur un réseau. Certaines de ses
méthodes tourneraient alors sur d’autres ordinateurs, même si cela exige des protections,
sémaphores et autres pour garantir sa cohérence.
Les limites de la mobilité faible peuvent être compensées de différentes façons : d’abord,
en utilisant un système basé sur une machine virtuelle, on peut permettre l’utilisation de
différents types d’ordinateurs aussi longtemps que la machine virtuelle existe sur chacun
d’eux. Cela ralentit le système mais est assez efficace.
Une autre solution est envisageable : chaque composant mobile pourrait avoir été
compilé pour chacun des types d’ordinateurs. Puis la machine expéditrice pourrait porter
une version de ses composants mobiles compatible avec chacune des machines du réseau.
Ainsi, elle pourrait envoyer la version adaptée au destinataire.
La mobilité faible est très similaire au clonage faible, puisqu’en pratique, on construit
sur l’ordinateur destinataire une instance de la classe de l’objet qui doit migrer, instance
qui reçoit les valeurs des variables de l’objet migrant lors de son dernier état stable. La
principale différence avec le clonage faible tient en ce que le code de la classe n’est pas à
l’origine présent sur l’ordinateur destinataire (figure 1.9).
La mobilité forte
La mobilité forte pourrait être appelée véritable mobilité car dans ce cas, le code en
exécution migre réellement. En effet, la migration est dite forte si elle ne concerne pas
le code compilé ou les données mais la pile du processeur. Dans ce cas, le programme
migrant reprend exactement à l’endroit où il s’est arrêté, les calculs partiels ne sont pas
perdus. . . La mobilité forte est la plus rapide puisqu’on ne crée pas de nouvelle instance
48
Expéditeur Destinataire
Message 1 :
initialisation de la migration
O (v1 = x1)
(………)
(vn = xn)
Classe
C
Message 2 :
transfert du code de la classe
O (v1 = x 1)
(……..)
(vn = xn)
Classe Classe
C C
Message 3 :
contenu de l’objet
O’ O’ =x1….xn
O (v1 = x 1)
(……..)
(vn = xn)
Classe Classe
C C
Fig. 1.9 – Un exemple de migration faible d’un objet O d’une classe C
de la classe etc. mais aussi parce que les calculs partiels ne sont pas recommencés au
début. Il est très difficile d’implanter un système de mobilité forte car elle demande la
compatibilité totale entre la machine expéditeur et la machine destination mais aussi parce
que peu de langages permettent l’accès à la pile du processeur (C++ le fait mais JAVA
non, par exemple). Théoriquement, la mobilité forte est implantable sur une machine
virtuelle (puisque une machine virtuelle simulant un processeur, elle a généralement une
pile virtuelle) mais JAVA ne permettant pas l’accès à la pile, cela ne fonctionnerait pas
avec une version classique de JAVA. Cependant, une version non officielle de JAVA 1.1
permettant l’accès à la pile existe [BSDLS00a, BSDLS00b], mais cette version n’est pas
compatible avec les versions postérieures officielles de JAVA et n’est de plus pas implantée
49
sur tous les systèmes d’exploitation. Elle n’est de plus pas garantie (ni même acceptée ou
validée) par SUN, elle ne peu donc pas être utilisée dans le cadre d’un partage pair à pair
des charges de travail. Il est possible que d’autres machines virtuelles (destinées à d’autres
langages de programmation) permettant la migration forte existent mais elles présentent
un toutes le même désavantage, elles ne sont ni largement distribuées si assez ouvertes
pour être sûre. Elles risquent en plus d’être assez lentes puisqu’elles ne sont sans doute pas
optimisées. La dernière limite de la mobilité forte est le risque qu’elle représente. Ce type
de mobilité est une réelle brèche de sécurité puisque le code reçu tournera directement
sur le processeur de son nouvel hôte. Ce dernier point est le plus grave dans notre cas.
Mobilité forte ou mobilité faible

Pour pouvoir utiliser des agents dans le but de construire un système destiné à per-
mettre la distribution et le partage de charge entre plusieurs utilisateurs différents, il est
nécessaire d’implanter des méthodes de migration.
En mobilité forte, le déroulement du code s’arrête sur l’hôte d’origine, après quoi, la
pile entière est transmise au nouvel hôte. Dans ce cas, les agents reprennent exactement
dans l’état dans lequel ils se sont arrêtés. La mobilité forte est la seule réelle mobilité car
la mobilité faible est en fait une forme de clonage. La mobilité forte n’est implantable que
sous certaines conditions de langage de programmation (accès à la pile) et de système (la
compatibilité entre les hôtes doit être complète. De plus elle est dangereuse car le code
transmis sera exécuté sans aucune vérification préalable sur le processeur (ou la machine
virtuelle) l’hôte destination.
On doit considérer sérieusement chacune des options lorsque l’on implante une plate-
forme destinée à gérer la mobilité car cela détermine non seulement le public (hétérogène
ou homogène, niveau acceptable de sécurité . . . ) mais aussi les applications possibles.
Les agents mobiles

Les agents mobiles sont (ou au moins devraient être) plus que des agents logiciels écrits
en utilisant du code mobile. Les agents sont comme nous l’avons déjà rappelé des entités
indépendantes et autonomes, des agents mobiles devraient donc pouvoir migrer par eux-
mêmes, ou au moins en suivant leurs propres désirs. Les agents mobiles sont difficiles à
gérer, la mobilité ajoutant encore à la difficulté des prédictions les concernant. Comme les
agents communiquent entre eux, il est nécessaire de pouvoir les suivre sur le réseau lors de
leurs migrations. Une plateforme d’agents mobile doit non seulement permettre “le suivi
du courrier” entre les agents mobiles mais elle doit aussi gérer les droits et les permissions
(car un hôte doit pouvoir accepter ou refuser chaque agent). Un système informatique
ouvert entraîne des difficultés supplémentaires, parce que les agents ne peuvent avoir de
connaissances que parcellaires du système et du réseau (elles seront difficilement remises
à jour) mais aussi parce que certains hôtes peuvent se déconnecter alors que des agents
les utilisent. Ces agents disparaîtraient, il faut donc construire des outils permettant la
pérennité des agents lors de la disparition de certains hôtes.
La mobilité entraîne de plus certaines interrogations de fond, comme par exemple la
question de la traçabilité : est-ce que l’on doit pouvoir retracer le parcours d’un agent au
50
travers de la toile des utilisateurs ? Mais aussi quels services le système doit fournir aux
agents lorsqu’ils sont placés sur un ordinateur distant ? L’OMG a répondu à certaines de
ces questions dans la définition de son standard : MASIF.
1.2.4 Architectures de partage basées sur des technologies agents

Systèmes de distribution de charges basés sur des technologies agent
Plusieurs auteurs se sont intéressés à la distribution de charges en utilisant des agents.
Dans [SST95], les auteurs ont utilisé des agents mobiles capables d’apprentissage par
renforcement pour améliorer la distribution de charge sur un réseau. Dans [SSCJ98], Katia
Sycara et O. Shehori utilisent le clonage d’agents comme outil pour répartir des charges sur
un réseau. L’idée de ces derniers est que distribuer des agents n’est pas suffisant puisque
les agents eux-mêmes peuvent profiter du calcul parallèle. Pour permettre un degré plus
élevé de parallélisme, ils conseillent de l’usage de technologies de clonage partiel d’agents,
c’est-à-dire de d’agents capable de créer des sous-agents capables de réaliser certaines des
sous-tâches de l’agent. Il devient ensuite possible de répartir ces sous-agents de façon à
profiter du parallélisme à un niveau plus fin, puis de les récupérer une fois leur travail
terminé. Cela permet de répartir les tâches à un niveau de finesse supérieur à la granularité
normale du problème. Cependant, cela demande d’avoir construit les agents de façon à
se qu’ils puissent se séparer ce qui est aussi difficile que d’avoir construit un système de
granularité égale à la granularité des sous-agents minimaux. De plus la solution la plus
simple est que chaque agent qui rencontre une nouvelle tâche instancie un nouvel agent
et lui donne la tâche à réaliser. Ce n’est dès lors plus très différent du fonctionnement de
DOGS (que nous décrivons plus loin dans ce document).
Gestion d’un système distribué basée sur des agents mobiles

L’un des problèmes que ne résolvent pas Sycara et Shehori se rapporte à la façon de
choisir une destination. En effet, les agents doivent choisir une destination sans passer
trop de temps à analyser les possibilités car la distribution ne doit pas consommer trop de
ressources ou elle ne serait plus rentable. Serge Fenet, dans sa thèse [Fen01], propose une
approche intéressante pour résoudre ce problème. Le système qu’il présente est basée sur
les stratégies de défense des insectes (son exemple est un système de sécurité de réseau,
mais les principes peuvent facilement s’adapter aux problèmes de partage de charge). Son
réseau peut être vu comme un champs de potentiel (appelé niveau de phéromones) qui est
émis par chacun des nœuds du réseau, chaque nœud prenant en compte la valeur de ses
voisins pour définir la sienne propre. Les agents peuvent transporter des informa-
tions d’un nœud à l’autre et ainsi remettre à jour la valeur locale du champ
et ses différentielles. Cette représentation pose quelques problèmes, d’abord, la valeur
du champ doit être remis à jour en temps réel ce qui peut être extrêmement coûteux en
communications. L’autre point litigieux concerne les voisins, dans un réseau IP, cette no-
tion n’est pas très claire et d’une certaine manière, tous les sites sont voisins (ou contigus)
puisque pour se déplacer de l’un à l’autre on ne traverse que des routeurs (donc aucun
autre site). En contrepartie, le système est distribué donc plus difficilement victime d’une
51
attaque informatique ce qui est important pour un programme de sécurité de réseau. Il

reste cependant quelques cibles centralisées (comme le serveur d’agents ou de
phéromones).
les systèmes “peer-to-peer” et de “grid” basés sur des technologies agents

Différents travaux se sont intéressés à l’utilisation des agents mobiles dans le cadre du
partage P2P de ressources informatiques mais aussi pour la gestion de systèmes distri-
bués. En effet, les agents offrent une bonne granularité pour la redistribution de charge en
cours d’exécution. Cependant différents usages sont possibles de cet outil. Par exemple,
dans [ea04], les auteurs présentent une solution P2P de partage de ressources basée sur
des agents mobiles, cependant, leur approche est très conservatrice en ce qu’ils appliquent
une solution technique proche de celles généralement employées pour le “load-balancing”,
puisque des agents gestionnaires de plateforme se partagent les charges qui sont encap-
sulées dans des agents mobiles. En cela le système présenté est destiné à optimiser le
parc informatique partagé plutôt qu’à permettre le partage des ressources entre utili-
sateurs “égoïstes”. En effet, l’intérêt de la communauté de partage prévaut sur celui des
utilisateurs pris individuellement. Ce choix peut être valide sous certaines conditions d’uti-
lisations, mais il est clairement inadapté à un réel partage pair à pair entre utilisateurs
n’ayant pas d’intérêts communs. C’est pour cette raison que si, dans [ea04], les auteurs
choisissent de faire prévaloir le bien de la communauté sur celui des individus, nous nous
intéressons au choix opposé.
D’autres auteurs se sont intéressés à la construction de systèmes P2P à base d’agents.
Il faut, par exemple, s’arrêter sur les travaux de Zhang et al. [Zha04] sur les systèmes
de recherche d’informations. Les agents doivent coopérer pour obtenir les informations
qu’ils recherchent. Pour accélérer la recherche, le réseau d’agent se reconstruit selon les
affinités de sujets. ce principe s’apparente à celui que nous avons présenté dans [KSFS04].
Cependant, le sujet est moins ardu car les similarités sont plus simples à définir puisqu’elles
portent sur des sujets de documents.
52
Chapitre 2
Méthodes de conception orientées

agents
La conception de systèmes multiagents est difficile. Il faut en effet construire non

pas des processus ou des objets mais des entités plus ou moins coopératives. Sur plusieurs
points, la conception d’agents s’apparente aux objets mais sur d’autres elle est plus proche
des méthodes procédurales. En effet, si les agents sont encapsulés à la façon des objets leur
niveau d’encapsulation les rapproche paradoxalement des procédures de la programmation
classique. En effet les agents “font” alors que les objets subissent. La différence entre les
agents et les objets parallèles tient en ces quelques mots. Cependant cette différence
est essentielle. On peut décrire un agent en programmation objet (en disant qu’il a des
modules de communication, de réflexion . . . ) mais on ne peut pas vraiment décrire une
architecture agent en utilisant une modélisation objet, il est en effet difficile de rendre
correctement des agents faisant de nombreuses tâches sans avoir de liens avec les autres
ou des agents choisissant quelles requêtes ils exécutent en fonction de leurs propres intérêts
et de leurs ressources. Il est possible de modéliser toutes ces choses en objets mais c’est
difficile et demande une granularité qui n’est pas celle de l’agent donc de l’organisation
du programme mais celle du module qui peut-être trop fine pour la conception théorique
d’un système.
2.1 Interactions, communications . . .

L’efficacité des systèmes multiagents réside dans les interactions entre les agents. En
effet, chaque agent séparément ne peut réaliser toutes les tâches du système. Les interac-
tions entre les agents peuvent se faire de différentes façons : au travers de l’environnement
comme dans le cas des traces de phéromones ou par transmissions directes auquel cas il
faut définir des protocoles de communications entre agents lesquels doivent eux-mêmes
être basés sur les protocoles de communications entre processus etc. il est donc nécessaire
de considérer différents niveaux d’abstraction lors de la conception d’un SMA. En effet
comme nous le montrerons plus loin, il est sans doute nécessaire de prendre en considé-
ration chacun de ces niveaux jusqu’à celui des communications réseaux pour concevoir
un système multiagents efficace. Les protocoles d’interactions entre les agents sont un
53
Chapitre 2. Méthodes de conception orientées agents
vaste sujet d’étude, ils couvrent des protocoles de communication de données, des pro-
tocoles de synchronisation (les systèmes multiagents sont des systèmes parallèles sans
vérification centrale, les agents doivent donc se synchroniser entre eux), des protocoles
de négociation . . . La FIPA définit un certains nombre de primitives (ainsi que de pro-
tocoles complets) pour permettre la plupart des communications potentielles entre les
agents [FIP98, FIP01]. Certains de ses protocoles ont été vérifiés par Hamza Mazouzi
dans sa thèse et d’autres travaux [Maz01, MEFSH02]. L’ingénierie de protocoles est une
des difficultés qui ne peuvent pas être dissociées de la conception de systèmes multiagents.
Comme les interactions entre agents sont la base de l’efficacité des SMA, la conception
des protocoles d’interaction est une étape capitale de la conception d’un SMA.
Les caractéristiques spécifiques des agents les rendent difficiles à modéliser en utilisant
les méthodes classiques (UML, MERISE . . . ). Il est assez aisé de concevoir des agents
en utilisant ces méthodes car les agents ne sont que des processus informatiques, mais
la conception de SMA exige de gérer les interactions entre les agents il existe donc des
méthodes spécifiques à la conception de systèmes multiagents. Nous allons en donner un
aperçu dans cette partie.
2.2 Conception de systèmes multiagents

Il existe de nombreuses méthodologies de conception de systèmes multiagents. Les
SMA présentant des caractéristiques très spécifiques, c’est assez logique. Dans ce chapitre,
nous ne présenterons pas les méthodologies agents de façon exhaustive, seulement quelques
exemples incarnant les grandes lignes des principes des méthodologies agents.
Pourtant, avant de rentrer dans ces descriptions, nous considérons qu’il est préfé-
rable de commencer par répondre à la question : “pourquoi existe t’il des méthodologies
agents ?”.
En effet, Abadi et Cardelli [AC96] ont montré que tous les processus pouvaient se
décrire avec des objets. On pourrait donc utiliser les méthodologies objets pour décrire les
systèmes à agents. C’est d’autant plus évident que bon nombre de SMA sont finalement
programmés en utilisant des langages objets comme Java (SyMPA [FSS03b, FSS03a,
SFS03], ARES [KFST02], JAK [Zhu00], les aglets [IBM03, KZ97, LO98] ou Zeus [Tel01]
par exemple). On peut donc en déduire que tous les SMA pourraient être conçus à l’aide
de méthodes objets.
Cependant, au niveau de granularité et d’abstraction des agents, ces méthodes ne sont
pas vraiment adaptées. En fait, même si les agents et les objets sont très similaires du fait
de leurs très hauts niveaux d’encapsulation respectifs, l’autonomie des agents les dissocie
plus largement des objets que leur encapsulation les en rapproche.
D’un point de vue informatique, on peut dire simplement que les objets sont “orientés
données” (puisque ils subissent les actions du programme sous forme d’invocation de
méthodes) alors que les agents sont plutôt “orientés processus” (puisque ils agissent sur
leur environnement). En fait représenter les agents comme des processus semblables à ceux
utilisés en programmation classique, est sans doute plus efficace qu’une représentation
objet. Donc utiliser des méthodologies issues de la programmation orientée-objets pour
construire des SMA n’est pas vraiment une bonne solution même si ces méthodes ont été
54
2.3. Les méthodes de conceptions de SMA “classiques” orientées agents ou rôles et leurs limites
arrangées pour coller aux besoins des agents comme dans le cas d’AUML [sita].
Les spécificités de la conception orientée agents ont été clairement décrites dans
[Jen99]. La programmation orientée rôles (de Gaia [MJK00] à Aalaadin [JO98]) proposent
de nouveaux paradigmes pour répondre à ces attentes. Cependant, même lorsqu’elle su-
bit d’assez fortes adaptations [JPS02], Gaia ne répond pas totalement au besoin de la
construction de SMA distribués efficaces car la gestion des de la distribution physique
des processus n’est en fait qu’un ajout de surface. Si l’architecture “rôles-agents” n’a pas
été construite avec la distribution des charges spécifiquement à l’esprit, l’organisation du
SMA en terme de processus peut rendre la distribution des charges très difficile et très
inefficace. Si des rôles parallèles ont été donnés au même agent, il ne sera jamais possible
de les faire tourner simultanément. De la même façon, deux agents ayant des rôles sys-
tématiquement consécutifs ne peuvent pas être séparés et distribués de façon à pouvoir
s’exécuter simultanément.
Pour toutes ces raisons, il apparaît que pour construire un SMA distribué efficace, il
faut utiliser une méthode qui s’articule autour des tâches et de leur possible parallélisation.
Il nous est apparu que les réseaux de Petri récursifs [ESA96] étaient très bien adaptés
pour résoudre ce type de problèmes, d’autant plus qu’il existe des travaux destinés à les
étendre de façon à prendre en compte les contraintes temps réel [RD85].
2.3 Les méthodes de conceptions de SMA “classiques”

orientées agents ou rôles et leurs limites
Contrairement à la programmation objet qui est largement concentrée sur les don-
nées (les classes pouvant être considérée comme des types de données très avancés), la
programmation agents est largement orientée processus (dans le cas d’un modèle coopé-
ratif). De ce point de vu, la programmation agents est plus proche de la programmation
de processus “classique” que du paradigme objet qui pourtant amène un plus haut ni-
veau d’encapsulation. La question qui sert de guide à la programmation objet est : “que
peut-on en faire ?” alors que celle qui guide la programmation objet est : “que peut-il
faire ?”. Ces deux questions montrent très simplement pourquoi les méthodes de concep-
tion objets ne sont pas vraiment adaptées à la conception de systèmes multiagents. Les
utilisateurs de méthodes orientées objet doivent dépasser les limites inhérentes de ces
méthodes en leur ajoutant des concepts tirés de l’intelligence artificielle distribuée (DE-
SIRE [Ev96, TJvdM01, Wei99]). Pourtant essayer d’adapter ces méthodes de cette façon
n’est pas une bonne solution car les corrections ajoutées vont à l’encontre des fondements
mêmes de ces méthodes. Tenter de changer la focalisation de ces méthodes des données
vers les processus n’est pas une bonne solution car c’est plus qu’une simple modification,
c’est contraire à la logique inhérente à ces méthodes.
Concevoir des systèmes multiagents présente un certain nombre de difficultés, voici les
plus importantes :
– Trouver “la bonne répartition” : La première tâche du concepteur de systèmes mul-
tiagents est la partition de la tâche à réaliser par l’application en sous tâches qui
pourront être distribuées aux différents agents.
55
– Trouver “les bons agents” : Il faut ensuite distribuer ces sous tâches aux différents
agents de la meilleure façon possible.
– Trouver les bons moyens de communication : Enfin, une fois que les agents ont
été créés (au moins formellement), le concepteur doit construire les interactions.
En effet un système multiagent n’est pas seulement un ensemble d’agents paral-
lèles et indépendants, ils sont aussi couplés donc en interaction. Les supports de
ces interactions entre les agents peuvent être de types très divers, des “phéromones”
informatiques des agents “fourmis” aux communications cryptées des agents foot-
balleurs. Dans le cas où les interactions entre les agents sont assez complexes pour
nécessiter des outils de communications spécifiques, il est nécessaire pour construire
ces outils d’analyser en profondeur les choix qui peuvent s’offrir. La construction
des communications entre les différents agents doit prendre en compte le coût et les
gains d’une potentielle distribution physique du système multiagent (par exemple
sur un réseau d’ordinateurs).
Pour résoudre les deux premiers problèmes, l’une des approches (la méthode GAIA
[MJK00] ou Aalaadin citeFER98) utilise des “rôles” abstraits qui peuvent ensuite être
distribués entre les différents agents ou donnés aux mêmes agents. Ce concept est intéres-
sant mais il entraîne deux nouvelles questions : comment les rôles doivent-ils être définis ?
Et comment doivent-ils être distribués entre les agents ? Il faut pour cela éclaircir les
relations entre les rôles et les besoins du système.
La méthode GAIA ne répond pas vraiment à la première question, les auteurs consi-
dèrent que la réponse à cette question peut être laissée au bon sens des concepteurs qui
les guidera dans leur conception des rôles en suivant le modèle des sociétés humaines
familières aux concepteurs du système.
Les auteurs donnent aussi un exemple de d’organisation humaine et ajoutent que
dans les sociétés comportant de nombreux individus, un même rôle peut être donné à
plusieurs individus alors que dans les petites sociétés, on a, à l’inverse, des individus qui
remplissent plusieurs rôles. L’analogie est cependant difficile à utiliser car in est difficile de
définir ce que serait une “start-up” d’agents et quand elle serait adaptée à la solution d’un
problème. en fait, le simple fait d’utiliser des modèles de sociétés humaines pour construire
des systèmes informatiques est probablement une mauvaise solution pour résoudre des
problèmes informatiques. En effet, les sociétés humaines sont régies par un certain nombre
de règles conçues pour permettre à la société de fonctionner malgré (ou grâce à) la nature
humaine, avec ses qualités et ses défauts qui ne sont pas les mêmes que ceux des agents
logiciels. Cette tendance à vouloir copier les sociétés humaines est peut-être un héritage
du début de la recherche en intelligence artificielle, quand le but des chercheurs était de
concevoir une machine “humaine”.
La distribution des différentes sous-tâches entre les agents peut être faite de deux
façons radicalement différentes. La première solution [BLH99] consiste à distribuer les
tâches à des agents déjà existants. Cette solution est très dangereuse car, dans la plu-
part des cas, le système construit a priori est en fait inadapté au problème à résoudre.
Cette solution exige de plus l’usage d’agents extrêmement génériques puisqu’ils devront
s’adapter à tous les types de tâches. La seconde solution consiste à ne rien présumer et
à construire les agents en fonction des tâches qu’on leur assigne. De cette façon, on ne
présume rien ni du nombre, ni de la nature des agents avant d’avoir réellement décider des
56
2.4. Programmation
tâches qu’ils auraient à réaliser. Cette solution permet de construire un système spécifique
à l’application à réaliser.
En fait, la distribution des tâches peut suivre différentes règles selon le but recherché.
Considérons trois cas extrêmes (les distributions réelles devraient être des fonctions moins
caricaturales car les besoins ne sont pas les mêmes pour tous les agents.
Considérons les trois types de distribution suivants :
– On peut avoir une distribution injective : chaque agent ne reçoit pas plus d’une
tâche (mais certaines tâches peuvent être données à plusieurs agents),
– Une distribution “surjective” : (chaque tâche n’est donnée qu’une seule fois, aucune
n’est répliquée et les agents peuvent avoir plusieurs tâches),
– Bijective : chaque agent reçoit une seule tâche et aucune tâche n’est répliquée sur
plusieurs agents.
Chacune de ces distributions présente des qualités et des limites qui doivent être jugées
à l’aune des critères suivants :
– La convergence du système (la réplication risquant d’entraîner des incohérences à
terme si certaines mesures ne sont pas prises).
– La couverture du système (il faut que toutes les tâches soient réalisées).
– La tolérance aux pannes (la réplication permet de minimiser les problèmes liés aux
pannes des sites)
– L’efficacité (la parallélisation permet d’augmenter les performances, pour paralléliser
au maximum, il faut minimiser le nombre de tâches par agents pour pouvoir ensuite
distribuer physiquement les agents).
2.4 Programmation
Préalablement à la construction d’un système multiagents, il faut prendre en compte
la difficulté de la représentation du système. Les plateformes multiagents utilisées dans
l’industrie sont en général plus rigides que les plateformes universitaires (JAC contre
MadKit) mais elles offrent aussi un cadre de programmation en fixant des limites quant
aux formats et aux contenus des agents.
La sécurité et la confidentialité des agents exigent que le système soit construit sur
une plateforme qui rende difficile la décompilation du code des agents (il faut se souvenir
que cela reste de toute façon possible). Cette considération s’oppose cependant à une
autre : les agents étant complexes, si l’on veut que la construction “d’agents à la volée”
soit possible, il est absolument nécessaire que l’on puisse les programmer dans un langage
ayant un haut niveau d’abstraction.
Il y a différents choix possibles :
– Les agents étant “cognitifs”, nous pourrions utiliser un langage de programmation lo-
gique comme l’une des différentes versions de PROLOG. Cette solution présenterait
de nombreux avantages car les langages logiques ont un haut niveau d’abstraction,
ce qui leur permet d’être extrêmement concis. Certains d’entre eux sont, de plus,
“compilables” (c’est-à-dire qu’il existe un compilateur pour eux sur la plupart des or-
dinateurs). Cependant, la programmation logique n’étant pas couramment utilisée,
il est difficile d’imposer ce type de conditions.
57
– Les langages de script les plus communs (PERL, TCL, PYTHON, . . . ) peuvent
incarner une autre solution. S’ils ne sont pas spécifiquement conçus pour écrire
des fonctions cognitives, ils sont largement utilisés, relativement sûrs (leur code est
souvent ouvert) et la plupart d’entre eux offrent quasiment toutes les fonctions des
langages classiques (ce qui peut être un problème quant à la restriction des droits
des agents sur leurs hôtes d’accueil).
– Il existe d’autres solutions, comme par exemple, SCHEME qui est techniquement
un langage de script mais qui est surtout un langage fonctionnel, ou SMALLTALK
[Sitb] (qui est un langage orienté objet et soit-disant agent dans ses dernières ver-
sions) qui est relativement bien adapté à la programmation agent. Ces deux langages
sont d’autant plus adaptés à notre situation qu’ils sont très stables, cependant, ils
présentent une limite puisqu’ils ne sont pas utilisés en dehors de leurs communautés
respectives. Ils sont cantonnés à la recherche universitaire. Il est donc difficile de
prétendre que l’on peut créer rapidement et simplement des agents dans ces lan-
gages, puisqu’il faudra que l’utilisateur commence par les apprendre. On pourrait
aussi utiliser CLAIM [FSS03b, FSS03a, SFS03]. Si CLAIM présente le même pro-
blème que les deux langages précédents, il présente l’avantage d’être spécifiquement
orienté agents et d’être relativement simple à utiliser.
58
Chapitre 3
Méthodes de représentations
Au cours de ce document, nous avons plusieurs fois eu recours à des méthodes de re-
présentations (de préférences, de processus . . . ). La représentation des processus et celle
des préférences peuvent toutes deux s’inscrire dans le domaine plus vaste de la représen-
tation de connaissances. Dans les deux cas, nous avons utilisé des réseaux “fonctionnels”
ou des treillis de Galois pour représenter les préférences des agents en matière de sites
informatiques, réseaux de Petri colorés et récursifs pour représenter les processus d’une
application. Dans ce qui suit, nous allons devoir décrire ces différentes représentations de
connaissances.
Nous commencerons par introduire les réseaux sémantiques, puis nous décrirons les
réseaux de Petri et nous finirons avec les treillis de Galois. En effet, ils sont, d’une certaine
manière, le lien entre les différentes représentations que nous présentons au cours de ce
chapitre. D’une certaine manière, toutes les autres peuvent être considérées comme des
réseaux “plus ou moins” sémantiques.
3.1 Les réseaux sémantiques :

On réunit sous la catégorie réseaux sémantiques différentes représentations de connais-
sances en utilisant des “nœuds” et des liens. En suivant cette définition, quasiment n’im-
porte quel graphique est un réseau sémantique. Cependant les réseaux que nous allons
décrire maintenant peuvent être formalisés en utilisant différentes logiques (logique des
prédicats, la logique dite “floue” (fuzzy logic ou la logique des descriptions comme dans
KL-ONE 1979 . . . ). [Bra85]
Sowa considère plusieurs types différents de réseaux sémantiques en fonction de leur
utilisation :
– Les réseaux de définition
– Les réseaux d’exécution
– Les réseaux d’implication
– Les réseaux d’assertion
– Les réseaux d’apprentissage
– Et les graphes hybrides qui sont à l’intersection de plusieurs des catégories précé-
dentes.
59
Chapitre 3. Méthodes de représentations
Nous commencerons par décrire rapidement certains réseaux sémantiques basés sur la
logique du premier ordre qui permet de décrire simplement des connaissances en utilisant
des objets (concepts) et des liens typés pour construire des connaissances liant les différents
concepts.
Voici par exemple, la description d’un camion (truck). [T railerT ruck : ∀] → (P art) →
[W heel : {∗} @18]
T railerT ruck = [T ruck : λ] → (P art) → [T railer]
[[T ruck : λ] → (P art) → [T railer] : ∀] → (P art) → [W heel : {∗} @18]
(∀x : T railerT ruck)(∃s : Set)(s@18 ∧ (∀w ∈ s)(wheel(w) ∧ part(x, w))).
La représentativité des réseaux sémantiques est généralement celle de la logique du
premier ordre. Les réseaux sémantiques peuvent être étendus en changeant la nature des
“liens”, en attachant aux liens une valeur numérique, on peut construire des relations
probabilistes ou équivalentes à la logique des possibilités (fuzzy logic) , mais il aussi
possible d’utiliser ces valeurs pour mesure la “distance” entre des concepts. Dans la thèse
de Wang, les liens sont associés à une valeur “d’appartenance”, qui est une mesure de la
différence entre les descriptions des deux concepts Donner un exemple math. De cette
façon, le lien entre un chien et un chat peut avoir une valeur assez élevée (puisque ce
sont des mammifères domestiqués par les humains). On peut aussi associer à un nœud le
cardinal de l’intersection de leurs extensions (dans ce cas la valeur associée au lien entre
les concepts de chien et de chat est nulle puisqu’il n’existe aucun chien qui soit aussi un
chat). On peut citer par exemple les systèmes de représentations de connaissances à base
de réseaux sémantiques suivants :
– les graphes existentiels (Pierce 1909) et conceptuels (Sowa 1976-1984-2000) dont les
différences sont essentiellement cosmétiques sont tous deux des modèles de graphes
d’assertion, ce qui signifie qu’ils permettent de représenter une assertion logique. Ces
derniers introduisent des cadres permettant de représenter les parenthèses et donc
de pouvoir représenter la négation d’expressions complexes. Dans l’exemple suivant,
l’expression suivante est représentée. L’utilisation des cadres permet de représenter
l’implication.
– Les réseaux de Petri (décrits plus loin en profondeur) sont le principal exemple de
réseaux d’exécution mais les différents diagrammes d’UML : les statecharts et les
activity diagrams, ainsi que les automates sont d’autres types de réseaux d’exécution
(ils sont een fait très semblables aux réseaux de Petri).
– KL-ONE est un exemple de réseaux de définition.
La représentation des préférences des agents Managers (voir cette section dans la troi-
sième partie de ce mémoire) en matière de sites connus dérive de la logique des descriptions
décrites dans KL-ONE et des réseaux de neurones. Elle pourrait être construite en utili-
sant l’une ou l’autre de ces représentations, cependant de par sa nature plutôt déductive
(puisque les Managers jugent les sites qu’ils connaissent en fonction de ces réseaux.
Pour montrer un exemple de transcription en logique des prédicats d’un réseau sé-
mantique, nous allons prendre la transcription des graphes conceptuels en logique des
prédicats et nous l’illustrerons par un exemple.
60
3.2. Les réseaux de Petri et leurs extensions, les réseaux de Petri récursifs et colorés
3.2 Les réseaux de Petri et leurs extensions, les réseaux

de Petri récursifs et colorés
Comme nous l’avons écrit précédemment les réseaux de Petri (Carl Adam Petri (1962))
sont considérés par Sowa comme une catégorie de réseaux sémantiques. Ils sont spécifi-
quement destinés à représenter formellement l’exécution d’une application.
A la différence des réseaux précédents, les réseaux de Petri sont constitués de trois types
“d’objets”, les places, les transitions et les jetons. Les places représentent les différents états
de l’exécution, les transitions sont les différentes actions et les jetons servent à représenter
l’exécution à proprement parler. Un réseau de Petri peut aisément être retranscrit en
logique des prédicats, en assimilant les jetons à des instances des différents états et en
considérant chaque lien comme l’état suivant. On obtient pour le réseau le plus simple, la
formule suivante. Les branches peuvent être décrite en logique des prédicats en utilisant
l’union (ou une formule de type si, alors, sinon en suivant d’autres formalismes). Les
boucles peuvent s’écrire en calcul des prédicats en utilisant une formule récursive.
3.2.1 Les réseaux de Petri colorés

Les réseaux de Petri colorés sont une extension des réseaux de Petri dans laquelle
chaque jeton est “identifiable”, en pratique cela signifie que selon l’instance d’un état, les
actions peuvent différer (en effet maintenant chaque état a un type qui dépend de la cou-
leur du jeton). En fait, les réseaux de Petri colorés peuvent être “développés” en utilisant
des réseaux de Petri classiques (il suffit d’écrire un réseau de Petri pour chaque couleur
de jeton). Les couleurs des jetons se rapportent aux variables des différents prédicats en
logique.
3.2.2 Les réseaux de Petri récursifs

De la même façon, les réseaux de Petri récursifs [ESA96] sont des extensions des
réseaux de Petri dans lesquelles les transitions peuvent être de trois types :
– abstraites,
– terminales,
– ou élémentaires.
On définit un réseau de Petri récursif comme suit :
Definition 3.1 (Réseau de Pétri récursif) Un RPN est défini comme un tuple < P, T, P re, P ost, V a
où
– P est l’ensemble des places
– T est l’ensemble des transitions telles que :
] ] ] ]
T = Telem Tabs Tend avecTabs = Tpar Texc et représente l’union disjointe
– P re est la est la matrice de préconditions, elle est la représentation matricielle de

d’un morphisme de P × T dans N
61
– P ost est la est la matrice de postconditions, elle est la représentation matricielle de

d’un morphisme de P × T dans N
– V ar est un ensemble de variables
– Call(t) est unun appel de méthode associé à t et Call(t) est défini en utilisant les
composants suivants :
– le nom de la méthode appelée,
– une représentation de l’agent appelant la méthode utilisant Var paramètres,
– une expression des paramètres d’appel (construite avec Var variables)qui repré-
sente donc les pré- et postconditons associées à la méthode.
Definition 3.2 (Un RPN initialisé) Un RPN initialisé est un tuple < R, M0 , Bind >
où :
– R est le squelette de RPN
– M0 est l’état du RPN au commencement du processus représenté (c’est donc un
morphisme de P dans N .
– Bind est la fonction qui relie les variables aux objets du domaine (elle peut être
complète et donc lier toutes les variables ou partielle).
Definition 3.3 (Un état de plan) Un état de plan est un arbre T r =< S, A > où :
– S est l’ensemble des nœuds
– A est l’ensemble des arcs a ∈ A tels que :
– a =< s, s0 > si et seulement si s0 est l’enfant de s dans T r
– Un arc a est nommé par une transition appelé T rans(a) où T rans est une fonction
de A dans T avec trans(a) = t
– L’état initial T r0 est un arbre réduit à un seul nœud s tel que : M(s) = M0 avec
M0 avec M0 l’état initial.
Definition 3.4 (A transition Firing Rule) Une transition t est dite fireable d’un nœud
s ∈ S si et seulement si :
– P re(s, t) ≤ M(s)
– R(s) est totalement initialisé
– Les préconditions de la méthode associée à t sont instanciées avec Call(t) et sont
dès lors valides
Definition 3.5 Une situation est dite situation d’échec si toutes les conditions de déclen-
chement d’une transition sont satisfaites à l’exception des préconditions de la méthode
associée.
Definition 3.6 (Transitions élémentaires) Soit t ∈ Telem . L’execution de t de s ∈ S

engendre le nouvel arbre T r0 avec le nouveau marqueur MT r0 de s tel que :
– T r0 = (ST r0 , AT r0 ) où :
– ST r0 = ST r tel que : ∀s0 6= s, MT r0 (s0 ) = MT r (s0 ) (i.e. le marqueur est inchangé
∀s0 6= s)
– AT r0 = AT r tel que ∀a ∈ AT r , T ransT r0 (a) = T ransT r (a)
– MT r0 (s) = MT r (s) + P ost(., t) − P re(., t)
62
3.3. Les treillis de Galois
Definition 3.7 (Transitions abstraites) Soit t ∈ Tabs . L’exécution de t de s ∈ S en-

gendre le nouvel arbre T r0 avec le nouveau marqueur MT r0 de s tel que :
– ST r0 = ST r ∪ {ns} où ns représente un RPN initialisé produit par les méchanismes
d’initialisation de la méthode associée avec t.
– AT r0 = AT r ∪ {a} où a =< s, ns > et T ransT r0 (a) = t
– MT r0 (s) = MT r (s) − P re(., t)
Definition 3.8 Soit T r(s) un arbre avec un nœud s comme racine. La fonction P RU NE(T r, s)
permet à l’arbre T r d’être coupé du nœud s comme suit : P rune(T r, s) 7−→ T r0 tel que
T r0 = T r\T r(s)
Remarque T r0 = ∅ si le nœud s est la racine de T r.
Definition 3.9 (Transition fin) Soit t ∈ Tend . L’exécution det de s ∈ S engendre le

nouvel arbre T r0 avec le nouveau marqueur MT r0 de s tel que :
– T r0 = P RINE(T r, s). Soit s0 le prédécesseur immédiat de s dans l’arbre T r et
a =< s, s0 > l’arc nommé t alors :
– ∀a ∈ AT r0 , T ransT r0 (a) = T ransT r (a)
– ∀s00 ∈ (ST r0 \ {s0 }), MT r0 (s00 ) = MT r (s)
– MT r0 (s0 ) = MT r (s0 ) + P ost(., T ransT r (a))
Normalement les réseaux de Petri récursifs ont été conçus pour pouvoir résoudre des
problèmes de planification et de coordination dynamique. Ici, nous les utilisons dans un
but qui peut paraître diamétralement opposé : l’analyse au préalable des différentes tâches
qu’une application doit réaliser pour arrive à son but. En fait les deux buts sont assez
semblables en ce que nous cherchons à garder le plus haut niveau d’abstraction possible
quand à la description de l’application (de façon à ce que l’encapsulation des différentes
sous tâches dans les agents soit simple) tout en vérifiant la coordination des différents
agents lors de toutes les tâches qui exigent un travail commun. De cette façon, les réseaux
de Petri récursifs sont tout à fait adaptés à notre problème puisque il ne diffère pas tant de
leur utilisation première. En effet la planification est dans notre cas “centralisée” puisque
nous distribuons les tâches entre les agents mais le niveau d’abstraction récursif permet
de considérer le problème à différents niveaux de complexité ce qui est une propriété très
enviable lorsque l’on doit construire un système.
3.3 Les treillis de Galois

Les réseaux de Petri sont rarement considérés comme des réseaux sémantiques, consi-
dérer ainsi les treillis de Galois est encore moins courant. Cependant, de notre point de
vue, ce n’est pas nécessairement très différent. Il existe néanmoins des spécificités impor-
tante des treillis de Galois. Si on peut effectivement les représenter comme des nœuds
reliés par des axes, par exemple, en construisant leur diagramme de Hasse, cette ressem-
blance est surtout esthétique. En effet, les nœuds et les liens du diagramme de Hasse
sont régis par des règles beaucoup plus strictes que celles qui régissent tous les modèles
ci-dessus. Les treillis de Galois se fondent sur la relation entre les concepts et les objets,
63
les liens du treillis sont l’inclusion pour les concepts (ou l’inclusion dans l’autre sens pour
les objets). En effet en considérant simplement que les concepts sont des descriptions, si
une description en inclut une autre alors tous les objets répondant au premier concept
répondent au deuxième.
3.3.1 Description des treillis de Galois (Concept lattices) tels

qu’ils sont utilisés pour la représentation de connaissances
L’idée fondatrice des treillis de concepts est l’intuition selon laquelle, un concept est
l’union de deux choses : une description et l’ensemble des objets qui y répondent. On
appelle extension d’une description l’ensemble des objets qui y répondent et intention
d’un ensemble d’élément la plus petite description qui les englobe. Si l’on s’intéresse à un
univers de concept, on est donc devant un triplet (O, A, I) où O est l’ensemble des objets
du monde, A, l’ensembles des attributs utilisables pour construire une description et I la
relation binaire entre les deux qui associe à un élément de O sa description (qui est un
ensemble d’éléments de A). On peut construire des fonctions (nous les appellerons f (resp.
g) dans la suite) qui associent un ensemble d’objets associent la plus complète description
globale permettant de les inclure tous et à une description, l’ensemble des éléments qui y
répondent.
Il faut cependant noter plusieurs caractéristiques intuitives de ces relations (pour pou-
voir plus facilement les formaliser ensuite). La fonction f (resp. g) est nécessairement
décroissante pour l’inclusion (pour l’inverse de l’inclusion). En effet, si l’on a un ensemble
d’objets O1 en incluant un autre O2, la description la plus complète permettant d’inclure
O2 décrit toutes les caractéristiques communes des éléments de O2, donc a fortiori toutes
celles communes aux éléments de O1 puisque tous les éléments de O2 appartiennent aussi
à O. Il en va de même pour la fonction g puisque si une description D0 est incluse dans une
autre D1, cela veut dire alors que tous les objets qui répondent à D1 répondent à D0 donc
la fonction est croissante pour l’inclusion (donc décroissante pour l’inclusion inversée).
La deuxième propriété intuitive est l’extensivité de gof et fog. En effet, appliquer gof à
un ensemble O d’objets, consiste à prendre la description la plus précise qui inclue tous les
éléments de O, puis à chercher l’extension de cette description dans l’ensemble des objets :
On comprend que O appartient à gof(O), puisque tous les éléments de O répondent à la
description f(O).
Ces deux caractéristiques nous permettent de poser formellement la définition des
treillis de Galois :
Soit I un ensemble fini de n objets. Soit J un ensemble fini de p éléments représentant
un ensemble de propriétés. Considérons la relation binaire iRj ssi l’objet i ∈ I a la
propriété j ∈ J .
Soit E = P(I) (resp. F = P(J ) la powerset de I (resp. de J ) avec la structure usuelle
de treillis pour la relation d’ordre ⊆ et les deux opérations union ∪ et intersection ∩.
Pour tout ensemble non vide A ∈ E = P(I), soit f (A) = {j ∈ J : iRj pour tout i ∈ A}
l’ensemble des propriétés satisfaites par tous les objets de A, et soit f (∅) = J . L’ensemble
f (A) est appelée intention (ou description) de A.
Pour tout ensemble non vide B ∈ F = P(J ), soit g(B) = {i ∈ I : iRj pour tout j ∈ B}
64
3.3. Les treillis de Galois
l’ensemble des objets satisfaisant toutes les propriétés données par B, et soit g(∅) = I.
L’ensemble g(B) est l’ensemble des objets satisfaisant toutes les propriétés données dans
B. on pose g(∅) = I. L’ensemble g(B) est appelé extension de B.
f : E → F et g : F → E sont décroissantes (3.1)

h = g ◦ f : E → E et k = f ◦ g : F → F sont extensives (3.2)
i.e.A ⊆ h(A) pour tout A ∈ E resp. B ⊆ k(B) pour tout B ∈ F).

La connexion de Galois a été introduite par Ore [Ore44] [14 de larticle].
Soit Ih = {A ∈ E : h(A) = A} (resp. Ik = {B ∈ F : k(B) = B}) l’ensemble des élé-
ments fermés (ou invariants) de E (resp. de F ).
Alors, le treillis de Galois (GL) défini par la connexion de Galois (f, g) est l’ensemble
des nœuds {(A, f (A)), A ∈ Ih } lequel a une structure de treillis si :
≤ est défini par (A, f (A)) ≤ (A0 , f (A0 )) ssi A ⊆ A0 (et f (A0 ) ⊆ f (A))
∨ est défini par (A, f (A)) ∨ (A0 , f (A0 )) = (h(A ∪ A0 ), f (A) ∩ f (A0 ))
∧ est défini par (A, f (A)) ∧ (A0 , f (A0 )) = (A ∩ A0 , k(f (A) ∪ f (A0 )))
Exemple :
Pout traiter des treillis plus générauX que les treillis binaires, on utilise toujours
E = P(I) comme précédemment, mais F est maintenant un treillis général avec un plus
petit élément appelé 0F (resp. un plus grand élément 1F ).
Etant donné deux treillis < E, ≤, ∨, ∧ > et < F , ≤, ∨, ∧ >, avec ≤, ∨, ∧ respectivement
la relatiopn d’ordre, le supremum et l’infimum, une connexion de Galois entre E et F est
une paire de fonctions (f, g) qui vérifie les propriétés (3.1) et (3.2). Il faut noter que la
propriété (3.2) peut s’écrire :
x ≤ h(x) et y ≤ k(y), ∀x ∈ E, ∀y ∈ F
Ces définitions impliquent : f ◦ h = f, h ◦ h = h, k ◦ g = g, k ◦ k = k
La restriction de f à Ih est un isomorphisme dans Ik , son inverse est la restriction de
g à Ik .
Le treillis de Galois peut donc se définir par la connexion de Galois (f, g) comme
l’ensemble des nœuds du type {(x, f (x)), x ∈ Ih } qui forme une struture de treillis si
≤ est défini par (x, f (x)) ≤ (x0 , f (x0 )) ssi x ≤ x0 (et f (x0 ) ⊆ f (x))
∨ est défini par (x, f (x)) ∨ (x0 , f (x0 )) = (h(x ∨ x0 ), f (x) ∧ f (x0 ))
∧ est défini par (x, f (x)) ∧ (x0 , f (x0 )) = (x ∧ x0 , k(f (x) ∨ f (x0 )))
Dès lors, on a {(x, f (x)), x ∈ Ih } = {(g(y), y), y ∈ Ik }

On peut donc observer que :
∀E ∈ E, h(E) est le plus petit ensemble fermé contenant E. (3.3)

∀y ∈ E, k(y) est le plus petit élément fermé supérieur à y. (3.4)
65
La représentation des treillis de Galois

Pour pouvoir représenter les connaissances incluses dans un treillis de Galois, on utilise
diverses méthodes de représentations, comme les graphes bipartite ou plus couramment
les diagrammes de Hasse. Nous allons présenter ici les diagrammes de Hasse. Dans un
diagramme de Hasse, les ensembles stables par k et h (c’est-à-dire tels que A=k(A))
forment les nœuds du réseau, les liens entre les nœuds représentent les inclusions entre les
ensembles d’éléments (ou l’inclusion inverse entre les descriptions puisque les ensembles
de la forme fok(A) sont stables par h). le diagramme de Hasse peut être vu comme un
“réseau sémantique” si on le considère comme un diagramme de descriptions (voir plus
haut).
3.3.2 Notre utilisation des treillis de Galois

Les treillis que nous utilisons pour définir nos préférences sont très classiques, ils
utilisent l’ensemble des ordinateurs comme extension et les descriptions d’ordinateurs
comme intention. L’utilisation de treillis de Galois pour définir des préférences n’est pas
courante, les treillis servent plutôt d’outils pour la classification. Cependant, nous utilisons
nos treillis de préférences comme des outils de classification : nos classes pourraient se
résumer en disant qu’il y a les mauvais ordinateurs, les ordinateurs moyens, les bons
ordinateurs . . . Ainsi au lieu de faire de la classification automatique à partir des instances,
nous construisons les classes a priori et y plaçons les instances rencontrées. Les différences
sont donc assez faibles, il était donc logique d’utiliser des treillis de Galois pour représenter
nos préférences. Les treillis de Galois permettent une classification assez simple puisque
nos treillis de description sont construits au préalable (les préférences des agents sont
définis avant l’exécution de l’application partagée), leur complexité peut donc être limitée.
En effet un treillis de Galois devient très vite très important en fonction du nombre
de variables dans la description (2n puisque nous sommes devant la somme des Cnk k
appartenant à 1, n). Cependant, chaque agent migrant aura des exigences assez précises
ce qui empêchera la taille de dériver.
L’isomorphisme entre le treillis des classes et celui des groupes d’ordinateur nous per-
met de plus d’utiliser le code du treillis comme un outil de placement et de recherche dans
la base de connaissance des agents.
66
Troisième partie
Méthodologie de conception de
systèmes multiagents orientée vers une
répartition efficace des charges :
HAMAC et ASMAA
67
Chapitre 1
Pourquoi une nouvelle méthode de

conception de systèmes multiagents ?
La programmation de logiciels peut être extrêmement difficile. Nombre de problèmes

sont algorithmiquement si difficiles que les résoudre peut être une réelle épreuve. Comme
les utilisateurs exigent que le code produit soit à la fois toujours plus sûr et réutilisable,
la programmation d’application devient toujours plus exigeante. Les paradigmes de pro-
grammation ont été inventés pour aider les concepteurs de programmes à répondre à ce
niveau très élevé d’exigence. Chacun de ces paradigmes, de la programmation fonctionnelle
à la programmation orientée composants tendent à satisfaire ces critères. Nous ne justifie-
rons pas ici la modélisation de la construction de systèmes informatiques, nous conseillons
au lecteur intéressé par ce sujet de se reporter à l’introduction des spécifications d’UML
[sitc].
Nous allons présenter une méthode de conception de logiciels basée sur la program-
mation orientée agents. Comme toutes les structures, les agents ne sont pas une approche
universelle des problèmes de programmation, il est donc nécessaire de commencer par
répondre à la question : “quand utiliser des systèmes multiagents ?” Une fois que l’on a
décidé de concevoir une application sous la forme d’un SMA, de nouvelles questions se
posent, il y a, en effet, de nombreux types d’agents différents, ils peuvent être réactifs
ou cognitifs (si l’on accepte cette classification), la dernière catégorie pouvant se séparer
elle-même en de nombreuses sous catégories. Le concepteur doit donc encore choisir les
types d’agents les plus adaptés aux tâches à réaliser, ainsi que les interactions qui les
relieront.
Le point de vue le plus consensuel sur les agents utilisés pour résoudre des problèmes
distribués (DSP) est le suivant : les agents sont des entités coopérantes travaillant ensemble
pour atteindre un but commun. Un système multiagent est alors une société constituée
d’agents de ce type. En partant de ce point de vue, nous pouvons considérer que le para-
digme agents se trouve à l’intersection entre l’intelligence artificielle à cause de l’autonomie
et du niveau de cognition des agents, de l’informatique distribuée et de la programma-
tion orientée objets car les différentes fonctions du SMA sont encapsulées dans les agents
lesquels sont aussi des processus coopérants, distribués et fonctionnent en parallèle.
En tant que paradigme de programmation, les systèmes multiagents ont plusieurs
avantages sur les autres méthodologies de conception d’applications informatiques, mais
69
Chapitre 1. Pourquoi une nouvelle méthode de conception de systèmes multiagents ?
ils présentent aussi quelques défauts, lesquels sont souvent l’autre face de leurs avantages.
La première des qualités des agents est le très haut niveau d’abstraction et donc d’encap-
sulation associé à l’indépendance de chaque agent. Ce haut niveau d’encapsulation peut
permettre de construire un code plus facilement recyclable car il devient assez simple de
réutiliser des agents construits pour d’autres applications. Le second avantage de SMA
tient dans le fait que les agents ne sont pas seulement parallèles, ils sont aussi extrêmement
indépendants en ce qu’ils ne partagent aucune mémoire. Ils sont donc, comparativement
aux structures de la plupart des autres paradigmes, plus faciles à répartir sur un système
distribué.
Mais les systèmes multiagents, à cause du niveau d’indépendance des agents qui les
composent, peuvent être relativement lents. Il faut donc impérativement tenter de les
optimiser. Idéalement, la meilleure façon de construire un système multiagent est de com-
mencer de rien ou alors de composants formés eux-mêmes d’agents. Il est en effet plus
simple d’incorporer des agents extérieurs dans un SMA que d’adapter du code écrit selon
un autre paradigme pour l’inclure dans le SMA sans en détruire la cohérence. Pourtant,
recycler du code préalable peut rendre la construction d’une application non seulement
plus simple mais aussi beaucoup moins coûteuse, cela peut donc être extrêmement im-
portant pour un projet informatique industriel. Adapter à un système multiagent le code
de versions antérieures construites avec un autre paradigme que la programmation agent
peut être difficile. Le projet ARCHON, par exemple, a montré les difficultés posées par
la simple association de deux systèmes experts [JZA+ 93], problème pourtant beaucoup
plus simple que de casser le code d’une application antérieure en petits blocs et de le
réorganiser en une large communauté d’agents indépendants et physiquement distribués.
Pour promouvoir l’utilisation des systèmes multiagents, les avantages que nous avons
cités plus haut doivent être correctement mis en valeur, d’autant que le paradigme agent
est desservi par sa jeunesse par rapport à la programmation orientée objet, par exemple.
Ainsi, comme les systèmes multiagents sont relativement jeunes, il est nécessaire de conce-
voir des modèles suffisamment simples de programmation orientée agent pour pouvoir être
utilisés par des concepteurs non spécialistes du domaine. Ces méthodes doivent mettre
en avant non seulement les étapes nécessaires au développement d’un système multiagent
mais aussi prendre en considération les façons d’optimiser son fonctionnement.
Dans cette section, nous allons présenter rapidement DOGS multiagent, qui a été la
base d’expérimentation de notre méthode de conception. Après cela nous rappellerons
rapidement les différents travaux liés à la conception de systèmes multiagents. Nous pour-
rons ensuite présenter notre méthode de conception en commençant par délimiter son
domaine de validité puis en suivant le processus de conception étape par étape.
70
Chapitre 2
Notre méthode de conception de SMA

et ses hypothèses d’application
2.1 Une présentation rapide de notre méthode de concep-

tion de SMA
2.1.1 Une méthode de conception globale
De la même façon qu’UML qui permet la représentation d’un projet informatique du
niveau de la conception à celui du déploiement, notre méthode de conception de sys-
tème tente de prendre en compte toutes les étapes de la construction d’une application
agents. En cela, elle est radicalement différente de Gaia (la méthode Gaia a été décrite
précédemment). Cette différence nous apparaît capitale. En effet, dans la plupart des
cas, les consommateurs d’applications informatiques sont plus intéressés par l’efficacité
de l’application que par l’esthétique de la conception (elle n’est cependant pas à négli-
ger puisqu’elle simplifie l’évolution potentielle de l’application), on doit donc prendre en
compte l’implantation et le déploiement de l’application. En fait, nous considérons que
l’implantation devrait être prise en considération dès la conception du système de façon
à ce que toutes les étapes de la conception se focalisent sur l’efficacité de l’application.
Notre méthodologie est entièrement orientée procédure (par opposition aux méthodes
orientées objets), dès lors nos représentations se concentrent sur les processus, leur or-
donnancement, les relations entre ces processus (d’abord dans l’absolu puis retranscrit
sous la forme de relations entre agents). Seuls les transferts de données sont représentés
dans les diagrammes, les données elles-mêmes ne nous concernaient pas, les utilisateurs
peuvent utiliser n’importe quelle représentation de données pour construire leur système
d’information (nous préconisons une représentation objet comme celle des diagrammes
d’UML . . . ).
2.1.2 Présentation des différentes étapes

Notre méthode de conception et d’implémentation de systèmes multiagents se compose
de cinq étapes essentielles (figure 2.1) réparties dans deux grandes parties, une statique
71
Chapitre 2. Notre méthode de conception de SMA et ses hypothèses d’application
(HAMAC [KFST02]), l’autre dynamique (ASMAA [NGA02]) :
Analyse
Composants Communication
réutilisables Tâche Client externe
Conception
Communications Agents
Implémentation des interactions et communications
Interactions Communications
Placement statique des agents Offline
Online
Redistribution dynamique des charges
Fig. 2.1 – Méthode de conception et implémentation de SMA
– Les phases d’analyse, de conception, l’implantation des interactions et des commu-

nications, ainsi que le placement statique des agents sont réunis dans HAMAC
– La redistribution des agents en cours d’exécution est spécifique d’ASMAA.
Pendant la phase d’analyse, les concepteurs doivent réunir les informations nécessaires
à la création du système proprement dit et les analyser. Elle peut être répartie en deux
grandes catégories :
– la collecte d’informations qui comprend la recherche de code utilisable dans le pro-
gramme, l’analyse des besoins et des moyens du client, ainsi qu’une analyse de
l’utilisation du programme, donc de ses liens avec l’extérieur (utilisateurs, autres
programmes. . . )
– l’analyse de la tâche à réaliser, pendant laquelle, il faut “découper” la tâche à réaliser
par le programme en sous-tâches qui seront résolues par les agents.
Après la phase d’analyse, pendant la phase de conception, on construit les agents
eux-mêmes. Les agents conçus, on construit leurs modes d’interaction puis de communi-
cations (jusqu’au plus bas niveau), pendant cette phase, on entre dans l’implémentation
du système stricto sensu.
72
2.2. Domaine d’application
Les deux dernières étapes concernent la position des agents car comme nous considé-
rons que notre système est a priori implanté sur un système multi-processeurs (un cluster
de PCs par exemple), il faut placer les agents mais surtout les déplacer de façon à corriger
des erreurs ou à s’adapter à une évolution du système.
2.2 Domaine d’application

Avant de présenter une méthode de construction de systèmes multiagents, on doit
commencer par définir le terme système multiagent. Même si ce ne sera pas fait ici, il
est est quand même nécessaire de délimiter le domaine de ce travail. La méthode en
présence a été appliquée au projet de THALES DOGS multiagent. Dont le but était
de transformer un système monolithique de diagnostic en un système multiagent. Cette
application limite le champ de cette étude. Les agents que nous avons finalement utilisés
dans DOGS sont très “humains” en ce qu’ils sont très indépendants à la fois les uns des
autres et du systèmes dans son ensemble mais aussi en ce qu’ils sont supposés réaliser
des tâches algorithmiquement complexes. Ils doivent aussi être complètement parallèles
et potentiellement distribués sur un système multiprocesseur non défini à l’origine.
Il faut aussi noter que les différents algorithmes et les différentes étapes du cycle de
fonctionnement du programme étaient déjà bien connus avant même la conception du
système (de part l’expérience des versions précédentes). A cause de toutes ces spécificités,
il est nécessaire de définir les limites de ce travail.
Après avoir pris tout cela en considération, nous avons résumé les hypothèses de notre
méthode comme suit :
– Le but de cette méthode est la construction d’applications de résolution de problèmes
distribuée.
– Le système conçu devrait pouvoir être physiquement distribué, cela implique que
nous prenons en compte le coût des communications.
– Nous ne prenons pas en compte les contraintes de temps réel.
– S’il n’y a pas de maximum théorique au niveau de complexité ou au nombre final
d’agents, le niveau d’abstraction considéré étant relativement bas et la méthode
étant récursive, l’analyse peut devenir extrêmement lourde si la complexité augmente
trop. Par contre, elle devrait être très adaptée aux problèmes de “reengineering”
d’applications et ce quelle que soit leur complexité. Nous conseillons l’usage d’une
méthode récursive (comme les réseaux de Petri récursifs [ESA96]) lors de l’analyse
des tâches, ce qui permettra de l’affiner jusqu’au moment où elle deviendra trop
complexe pour être poussée plus avant.
– La version présentée ici ne fonctionne que dans le cas d’organisations et de com-
munications entre agents statiques. Cela signifie que les buts des agents ainsi que
leurs interactions sont définies au cours de l’implantation du système et ne peuvent
pas évoluer dynamiquement. Nous élargirons la portée de notre méthode dans la
deuxième section de cette partie (ASMAA).
– Enfin, les agents peuvent être hétérogènes autant au niveau abstrait que du point
de vue de leur implantation (en fait, l’un de nos buts est d’aider à construire et à
gérer cette hétérogénéité).
73
DOGS, qui sera notre exemple directeur au cours de toute cette partie, correspond
assez bien au domaine que nous avons présenté ci-dessus. Il avait été décidé dès le com-
mencement du projet que les agents de DOGS seraient aussi coopératifs que possible et
ce parce qu’aux vus des buts de l’application, il n’y avait aucune raison justifiant la pré-
sence d’agents concurrents dans ce programme. L’analyse n’a pas été très difficile (nous
avons finalement obtenu une dizaine de types d’agents différents) et nous avons décidé
que les agents et leurs organisations seraient statiques. Enfin, comme DOGS était un
système déjà fonctionnel, l’un des principaux problèmes a tenu dans le fait qu’il fallait
que la réutilisation du code des versions précédentes soit maximale. La prééminence de
DOGS-multiagents dans l’élaboration de cette méthode de conception exige que l’applica-
tion, dans son fonctionnement soit présentée préalablement à la description de la méthode
proprement dite.
2.3 Une rapide présentation de DOGS multiagent

La méthode que nous présentons dans ce document a été utilisée pour construire la
version multiagent de DOGS qui est une application de diagnostic de circuits électroniques
développée par THALES Systèmes aéroportés. DOGS vérifie qu’un circuit électronique
donné fonctionne correctement en détectant les inconsistances au sein des résidus (pro-
priétés formelles liées aux valeurs mesurables sur le circuit) en se basant sur le “calcul des
intervalles” [DDTV99].
Comme nous allons le montrer dans le prochain paragraphe, DOGS était un excellent
sujet d’expérimentation pour notre méthode de conception.
Pour vérifier un circuit électronique, DOGS Multiagent commence par réduire la dif-
ficulté en partitionnant le circuit considéré de façon à minimiser la difficulté de la vérifi-
cation. Les circuits électroniques sont découpés selon leurs blocs fonctionnels qui sont en
quelques sorte des composants abstraits (additionneur, multiplicateur, intégrateur . . . ).
Ces blocs peuvent être traités par des processus parallèles parce qu’ils sont peu corré-
lés. Ces processus doivent cependant communiquer car les résidus peuvent prendre en
compte des composants placés dans différents blocs fonctionnels et de plus, on ne peut
repérer certains de problèmes que lorsque plusieurs blocs fonctionnels sont pris en compte
simultanément. Le problème considéré permet donc l’existence de processus parallèles
mais couplés. DOGS possède une seconde caractéristique qui nous pousse à utiliser un
système multiagent : la granularité des tâches à réaliser. Un circuit peut être considéré
selon différents niveaux d’abstraction, comme un ensemble de blocs fonctionnels (certains
circuits peuvent par exemple se voir comme des systèmes de protes logiques) plutôt que
comme des circuits électroniques réels (de résistances, de condensateurs, de bobines ou de
transistors). Il existe même d’ailleurs différents niveaux d’abstraction des blocs fonction-
nels selon la complexité des fonctions considérées. Etudier un circuit à un niveau élevé
d’abstraction (en le considérant comme un système de blocs fonctionnels) peut permettre
de détecter des composants défectueux et de les localiser mais c’est normalement insuf-
fisant pour déterminer quel composant est spécifiquement responsable des problèmes du
système puisqu’on peut rarement détecter d’anomalie d’une granularité inférieure à celle
de l’observation. Il est donc logique d’observer et d’analyser le comportement du système
74
2.3. Une rapide présentation de DOGS multiagent
à différents niveaux d’abstraction puisque cela peut permettre de détecter et de cerner

rapidement une anomalie puis de la localiser spécifiquement.
Le projet DOGS Multiagents présentait une autre qualité intéressante de notre point
de vue : il était nécessaire de réutiliser au maximum le code des versions précédentes
de DOGS puisque le programme existait déjà sous la forme d’un système monolithique.
Nous avons donc dû prendre en compte le fait qu’il fallait maximiser les possibilités de
recyclage du code de la version précédente écrite en utilisant le langage SIXTUS PROLOG.
Cela présentait un avantage supplémentaire du fait que nous allions devoir reconstruire le
système de façon à construire une version multiagent distribuée. Il fallait donc chercher
une méthode qui nous permette de paralléliser et de distribuer DOGS de la meilleure
façon possible.
75
76
Chapitre 3
La phase statique de notre méthode de

construction de systèmes multiagents :
HAMAC
3.1 Un résumé rapide de la partie statique de notre

méthode : HAMAC
Première étape : l’analyse
1. Analyse des tâches et des processus :
Cette première étape est récursive, du plus haut niveau d’abstraction, celui de l’ap-
plication jusqu’au plus bas. C’est pendant cette étape que l’on décide quel sera le
niveau de granularité minimal pris en compte dans la suite.
2. Analyse des moyens et besoins du client :
Cette étape doit fournir une image aussi précise que possible du système informa-
tique (logiciel et matériel) qui servira de support à l’application.
3. Analyse des composants potentiellement recyclables :
Au cours de cette étape du processus d’analyse, le concepteur doit tenter d’adapter
les composants logiciels déjà présents au sein du système multiagent.
4. analyse des communications externes de l’application :
Cette étape se concentre sur les communications entre le système multiagent en
construction et tous les programmes informatiques avec lesquels il pourrait être
connecté.
Seconde étape : processus de construction de la société des agents du SMA
Les deux étapes suivantes sont récursives, elles sont répétées jusqu’à ce que le résul-
tat soit satisfaisant. A chaque itération, on remonte d’un niveau d’abstraction dans la
description des tâches distribuées aux agents.
1. Conception des agents :
Dans cette partie, nous répondons à la question : “quel agent pour quelle tâche ?” :
faire ce choix consiste a répartir le travail à réaliser en plusieurs blocs qui serviront
de base à l’architecture du SMA.
77
Chapitre 3. La phase statique de notre méthode de construction de systèmes multiagents : HAMAC
2. Conception des communications :

Au cours de cette étape, on conçoit les communications engendrées par la distribu-
tion construite lors de l’étape précédente et on évalue leur coût pour pouvoir décider
si cette distribution est réaliste et fonctionnelle.
Troisième étape : implantation des interactions et des communications des agents
1. Le concepteur doit ensuite concevoir les protocoles d’interactions entre les agents.
2. Il doit ensuite choisir les moyens de communication les mieux adaptés aux inter-
actions, ainsi qu’aux logiciels et au matériel qui ont été décrits lors de la phase
d’analyse associée.
3.2 Le processus d’analyse

3.2.1 Analyse des tâches et des processus
Présentation
Lors de cette étape du processus d’analyse, le concepteur doit répondre à la question :
“comment dois-je répartir les tâches entre les agents ?”
Lorsqu’un projet de conception d’un logiciel commence, la première étape est normale-
ment l’analyse des tâches. Ce que l’on fait lors de cette étape dépend de deux paramètres :
l’application elle-même et le paradigme de programmation choisi pour concevoir le pro-
gramme. Si le cadre du projet est “orienté objets”, nous devons commencer par décrire les
différents objets composants le programme et les différentes relations entre ces objets, il est
préférable de les définir formellement ensuite (par exemple en utilisant le ς-calcul [AC96]).
Notre perspective sur les agents est très orientée tâches, nous proposons donc de décrire,
d’une façon similaire à celle décrite précédemment, les tâches qui composent le cycle de
fonctionnement du programme. Nous avons décidé de représenter les tâches formellement
en utilisant des réseaux de Petri récursifs (et/ou colorés) (figure 3.1) [ESA96, MEFSH02].
Cependant d’autres solutions pourraient être proposées (comme les graphes procédu-
raux d’UML malgré son orientation). La seule exigence, ici, est que l’on garantisse la
validité du “réseau de ressources”, c’est-à-dire les ressources nécessaires pour que chacune
des tâches commences toutes les ressources obtenues à la fin de chaque tâche. Le réseau
doit aussi inclure une représentation de toutes les relations entre les différentes tâches
ainsi que les relations entre celles-ci et les différents “objets” (ici, objet ne se réfère pas
à la programmation objet mais à tous les types de ressources, variables, structures de
données, objets réels (comme des robots. . . ) ou virtuels (comme des outils logiciels . . . )
dont les tâches nécessitent l’utilisation. Le but de cette analyse est de déterminer ce qui
pourra être parallèle et ce qui devra être séquentiel. Même si deux tâches sont potentiel-
lement parallélisables, il peut ne pas être rentable de les distribuer effectivement si elles
utilisent toujours les mêmes ressources localement statiques (puisque ces ressources ne se
déplaceront pas).
Théoriquement, plus la granularité de cette étude est fine, meilleure est l’analyse,
pourtant ce n’est pas nécessairement une bonne solution de mener le raffinement jusqu’à
un grain de type accès mémoire, d’abord parce que c’est extrêmement lourd et que, de
78
3.2. Le processus d’analyse
Mesures de
Modèle du tension
circuit électrique
Première tâche:
construire et raffiner les
équations
Equations obtenues à partir des

mesures et des modèles de circuits
Le circuit est partitionné en

plusieurs blocs fonctionnels
lesquels sont vérifiés en parallèle
Fig. 3.1 – Exemple d’analyse des tâches réalisée en utilisant des réseaux de Petri récursifs
toutes façons, les tâches obtenues ne seront pas réellement séparables et donc finiront
toujours dans le même agent. Lors des étapes de construction des agents, il faudra refaire
le même travail dans l’autre sens. Il n’est donc pas nécessaire de pousser l’analyse trop
avant.
Quelque soit la méthode finalement utilisée pour décrire les tâches, cette méthode doit
décrire les relations entre les tâches car ce sont ces relations qui formeront la base de la
construction des relations entre les agents. Il faut donc les avoir parfaitement définies, et
ce à tous les niveaux d’abstraction étudiés puisque l’on ne sait pas, pendant l’analyse à
quel niveau d’abstraction se construiront les agents.
Au cours du projet de DOGS, nous sommes restés à un assez haut niveau d’abstraction,
les tâches que nous avons construites étaient d’un haut niveau car comme nous comptions
réutiliser le code des versions précédentes de DOGS, les autres étapes de l’analyse ont
limité le besoin de pousser très profondément cette analyse.
79
Description
Nous avons utilisé les réseaux de Petri récursifs lors de l’analyse des tâches. Cependant,
il est absolument nécessaire de décrire complètement les tâches pour pouvoir raffiner le
réseau de Petri. Nous devons donc présenter les tâches de façon à ce que l’on puisse utiliser
le raffinement pour construire un système efficace.
Chaque tâche doit être décrite de façon suffisamment précise, nous avons donc opté
pour une description suivant les variables suivantes :
Les tâches telles que nous les utilisons lors de la décomposition des tâches doivent
aussi être décrites. Elles sont décrites lors de l’analyse des tâches en utilisant les variables
suivantes :
– NOM : chaque tâche a un identifiant unique qui permet de la reconnaître, cet iden-
tifiant est par extension utilisé pour représenter la capacité à remplir cette tâche.
– PARENT : le parent d’une tâche est la tâche du niveau d’abstraction immédiatement
supérieur qui a engendré cette tâche lors du raffinement.
– ENTREES/SORTIES : il est nécessaire de préciser la liste complète des entrées et
des sorties de chaque tâche ainsi que la tâche à qui sont destinées ces sorties.
– INFORMATIONS NECESSAIRES A L’EXECUTION : La description doit contenir
toutes les informations (données, objets etc. contenues dans l’environnement) né-
cessaires à son exécution. La description algorithmique de la tâche (voir ci-dessous)
fait appel à ces données. L’ensemble des entrées des fonctions de la description
algorithmique doit être égal à l’ensemble contenu ici.
Soit E l’ensemble des tâches et t ∈ E, on peut écrire : soit Env l’environnement
d’exécution du programme c’est-à-dire l’ensemble contenant toutes les variables
d’exécution de l’application. on appellera P REt l’ensemble des préconditions de
t. Il faut noter que P REt doit contenir le fait que toutes les variables d’environne-
ment nécessaires à l’exécution de la tâche doivent être instanciées et doivent avoir
une valeur valide. Dans le cas où la tâche t peut s’écrire comme le calcul d’une
fonction f , on a :
en écrivant f ,
f : E1 × E2 × . . . × En → F1 × F2 × . . . × Fn
f : x1 , . . . , xn 7−→ f (x1 , . . . , xn )
avec D1 . . . Dn les ensembles de définition de x1 . . . xn
∀i ∈ N , Pi = {xi ∈ Di } ∈ P REt
P REt contient donc toutes les préalables à l’exécution de t mais aussi toutes les
hypothèses nécessaires pour que la tâche s’exécute correctement.
– DONNEES SORTIES : sont décrites ici toutes les modifications à l’ensemble des
données et objets de l’environnement qui ont été réalisées lors de la tâche. L’en-
semble des sorties des fonctions de la description algorithmiques doit être égal à
l’ensemble contenu ici. De la même façon que pour les informations nécessaires à
l’exécution, l’ensemble des données sorties, que nous appellerons P OSTt est l’en-
semble des modifications dans l’environnement résultant directement de l’exécution
80
3.2. Le processus d’analyse
de t. C’est-à-dire l’ensemble des variables instanciées lors de l’exécution de la tâche

et l’ensemble des variables dont les valeurs ont pu avoir été modifiées lors de l’exé-
cution.
– DESCRIPTION : chaque tâche doit pouvoir être décrite de façon algorithmique de
façon à pouvoir être programmée ou le cas échéant raffinée de façon récursive.
3.2.2 Analyse des moyens de l’utilisateur

Quand le problème à résoudre a été correctement analysé, la deuxième étape est logi-
quement l’étude des moyens à la disposition du concepteur pour le résoudre, c’est-à-dire
l’analyse des moyens informatiques du destinataire de l’application. Partir du principe
que le même programme fonctionnera parfaitement sur un PC, un cluster de PCs, un
superordinateur, un système de type SETI@home [Set], scalable, ouvert et complètement
distribué ou un autre système de type grid est simplement parfaitement irréaliste. Le
raisonnement qui consiste à considérer que c’est au système d’exploitation de permettre
à l’application de fonctionner au mieux est erroné. Le type de système auquel se destine
l’application est d’une grande importance pour sa conception. Dans un système ouvert
comme SETI@home, il peut être une bonne solution d’utiliser de petits agents très simples
qui pourront facilement migrer vers leur destination par Internet d’un ordinateur à l’autre
et dont la granularité sera suffisamment fine pour qu’ils aient normalement le temps de
terminer leur tâche avant d’être forcés de quitter leur hôte. En contrepartie, cela deman-
derait une organisation complexe qui puisse gérer les entrées et les sorties, pas seulement
des agents mais aussi des ordinateurs et les variations d’adresses IP.
L’analyse des moyens de l’utilisateur pour DOGS a été assez difficile car nous ne sa-
vions pas vraiment à quel type de système informatique DOGS était destiné. Cependant,
l’application devait être portable car le système informatique considéré comprenait plu-
sieurs PCs et une SOLARIS. Nous avons finalement fixé que le système fonctionnerait sur
un petit réseau à 100 Mbits fermé (une douzaine de machines reliées par un switch) et
comprendrait des ordinateurs à technologie INTEL. Les ordinateurs considérés devraient
être assez puissants (pas d’ordinateurs de génération vraiment ancienne) et ne seraient
dédiés à DOGS que temporairement. Cependant, et pour des raisons de recherche et
développement, il fallait aussi que le système soit potentiellement distribuable sur des
ordinateurs distribués sur Internet dans le cas d’applications à des problèmes spécifiques.
3.2.3 Analyse des composants recyclables

Parmi les problèmes classiques de la construction de logiciels, l’un des plus classiques
est le recyclage des composants logiciels déjà existants. La programmation orientée agents
est assez éloignée des autres paradigmes de programmation, il peut donc être assez difficile
de réutiliser des composants construits au préalable. La réutilisation des composants logi-
ciels doit être prise en compte dès le début du processus de conception de façon à “ce que
les pièces du puzzle s’insèrent correctement”. Il faut donc concevoir le système en prenant
en considération les composants logiciels réutilisables à l’esprit de façon à minimiser les
difficultés liées à l’implantation ensuite.
81
Lorsque l’on utilise d’autres paradigmes de programmation, cette analyse est parfois
incluse dans le processus d’implantation. Mais comme la programmation agents est à la
fois assez spécifique dans ses besoins et peu courante, nous préconisons réellement que
cette étape se place directement dans l’analyse car nous le rappelons, il faudra sans doute
adapter du code non-agent à un système à agents. Lors de cette étape, il faut analyser en
profondeur le code déjà présent et le réduire en composants logiquement indissociables de
la plus petite granularité possible de façon à ce qu’ils soient aussi simples que possible à
intégrer à la nouvelle application. Il faut ensuite lier les composants logiciels réutilisables
avec les tâches de l’étape d’analyse des tâches. De cette façon, les concepteurs peuvent
savoir au plus tôt quelles tâches devront être données au même agent de façon à profiter
de composants logiciels antérieurs et quelles tâches peuvent être distribuées. Cela permet
aussi de savoir ce qui devra être programmé spécifiquement pour le système multiagent
et ce qui pourra être recyclé. Cela peut permettre de chiffrer plus précisément les coûts
de développement de l’application.
Il faut noter que toute cette étape peut être sautée dans le cas où les concepteurs
veulent construire leur application à partir de rien ou lorsque la lisibilité du nouveau code
prime sur les coûts d’implantation. Cependant, réduire les coûts (financiers et temporels)
de l’implantation est la plupart du temps une priorité majeure des projets informatiques.
Il faut aussi noter que si le code à recycler a été écrit en respectant les principes de
la programmation de composants, il sera sans doute beaucoup plus simple à réutiliser
que si ce code est une partie d’une ancienne application monolithique programmée en
suivant l’un (ou plusieurs) des paradigmes classiques de programmation. Ces derniers
nécessiteront probablement une étude beaucoup plus poussée.
Comme nous l’avons déjà rappelé, on pourrait considérer que ces problèmes sont pu-
rement des problèmes d’implantation. Cependant, si la conception des agents est réalisée
sans prendre le code à recycler en compte, les composants logiciels réutilisables risquent de
ne pas s’insérer bien dans la nouvelle architecture, ce qui peut entraîner des redondances
inutiles (mais coûteuses en terme de calcul et de mémoire) ou la réécriture complète
de fonctions déjà présentes dans les versions précédentes. C’est pour ces raisons, qu’il
est souhaitable que cette étude se fasse préalablement à l’implantation, lors de la phase
d’analyse.
Lors du projet de DOGS Multiagent, cette étape a été relativement simple, car il
existait une version séquentielle du même programme et que les concepteurs des versions
antérieures participaient pour la plupart à la conception de la nouvelle version. Il y avait
énormément de code réutilisable (en fait chacun des composants nécessaires existait déjà
et il avait été décidé que la réutilisation du code des versions précédentes serait maximale.
Cependant, les versions précédentes de DOGS avaient été construites en utilisant Sixtus
PROLOG, ce qui entraînait quelques considérations supplémentaires. La première de ces
considérations a été l’encapsulation du code PROLOG dans des agents JAVA ainsi que
la nécessité de concevoir une bonne interface entre les codes programmés dans les deux
langages. L’utilisation de PROLOG a aussi fait disparaître le besoin d’une analyse très
en profondeur du code puisque PROLOG étant un langage très abstrait, les composants
logiciels ont une granularité assez épaisse.
82
3.3. Processus de conception de la société du système multiagent
3.2.4 Analyse des communications externes

Cette phase de l’analyse est assez simple, elle doit cependant être suivie correctement.
Les concepteurs s’arrêtent ici sur les utilisations de l’application qu’ils construisent. Un
système indépendant ne doit pas être construit exactement comme un programme qui
ne serait que l’un des maillons d’une chaîne de processus (dans le second cas, il faudra
qu’il soit simple de construire les interfaces entre le programme et ses prédécesseurs et
ses successeurs dans la chaîne). Cette étape peut être sautée dans certains cas car il
est généralement possible de corriger les problèmes causés par son absence plus tard,
en utilisant par exemple des agents intermédiaires (wrapper agents [Kei01]), mais le
résultat obtenu sera sans doute moins efficace que si le programme avait été bien conçu
dès l’origine. Les effets de cette analyse se feront sentir lors des dernières étapes de la
conception, lorsqu’il faudra construire les communications des agents. Cela peut aussi
influer sur la conception des agents eux-mêmes puisque l’on peut, par exemple, décider
d’encapsuler les liens avec les autres applications au sein d’agents spécifiques.
En simplifiant à l’extrême, on peut considérer qu’il existe trois types d’applications :
– Les systèmes solitaires qui ne communiquent avec aucun autre programme informa-
tique en dehors du système d’exploitation de leurs plateformes. Dans ce cas, il n’y
a aucune restriction sur la nature des messages au sein du système multiagent.
– Les systèmes coopératifs qui sont des systèmes multiagents qui n’auront de liens
qu’avec d’autres systèmes multiagents. Nous pouvons les classer séparément car
il est possible dans ce cas de les concevoir comme un seul système et il peut être
possible de construire les agents de façon à ce que les agents des divers SMA puissent
communiquer directement (la FIPA, par exemple, définit des protocoles génériques
pour permettre les communications entre systèmes multiagents).
– Les systèmes intégrés qui comprennent les systèmes multiagents intégrés dans une
structure dont les autres éléments ne sont pas des SMA. Pour ces derniers, il devient
nécessaire de construire des interfaces entre les différents systèmes et de construire
des agents spécifiques qui pourront représenter les éléments de la structure en rela-
tion avec le SMA au sein du SMA.
DOGS a été conçu comme un système solitaire, nous n’avions donc pas à prendre
en compte la façon dont les agents pourraient potentiellement interagir avec d’autres
systèmes informatiques. C’est notable puisque cela nous a laissé un large éventail de choix
quant aux formats des communications entre nos agents.
3.3 Processus de conception de la société du système

multiagent
Au cours de cette seconde partie de notre méthode de conception de SMA, nous allons
nous arrêter sur la conception des agents eux-mêmes ainsi que sur leurs relations. C’est
pour cette raison que nous appelons cette partie conception de “la société” des agents.
Cette étape utilise les résultats des analyses réalisées lors des étapes précédentes, aussi
bien lors de l’analyse des tâches que lors de l’analyse des composants recyclables.
La méthode de construction de la société des agents est un algorithme récursif, pendant
83
lequel nous créons des agents virtuels, nous leur distribuons les tâches à réaliser, puis nous
construisons les communications engendrées par cette distribution, que nous évaluons
ensuite. Si les résultats de l’évaluation ne sont pas satisfaisants, on recommence à la
première étape en diminuant le niveau d’abstraction et en associant les tâches dont les
communications étaient trop coûteuses.
Algorithme d’allocation des tâches Entrée : ensemble des tâches à assigner et

ensemble des ressources partagées
Etape 1 : création des agents et distribution des charges en suivant les lignes définies dans
la figure 3.2
Fig. 3.2 – Comment distribuer les tâches en fonction du réseau de Petri
Etape 2 : vérifier que les ressources communes sont bien gérées en suivant le tableau (il
faut vérifier que le nombre d’agents pouvant accéder aux ressources simultané-
ment est inférieur ou égal au nombre de points d’accès de la ressource).
Etape 3 : évaluation du coût de la distribution en terme de communications (taille des
messages et fréquence des communications)
84
Etape 4 : amélioration récursive de la distribution des tâches : si la troisième étape conclut

à un coût trop élevé des communications, les tâches sont associées de façon à
réduire le coût et l’algorithme est répété avec le nouveau diagramme des tâches.
Sortie : les agents sont conçus et les tâches distribuées
3.3.1 Conception des agents

Lors de la première étape de la conception du système à proprement parler, les concep-
teurs doivent répartir les tâches entre les agents potentiels (Fig. 3.2). Les tâches sont
distribuées de façon à ce que si deux tâches ne peuvent pas être concurrentes, elles sont
données au même agent (il n’y a pas de raison de les distribuer puisque elles seront né-
cessairement séquentielles). Lorsque deux tâches sont mutuellement exclusives, elles sont
aussi données au même agent (cela ne nuit pas aux performances car elles n’auront jamais
lieu en même temps) pour simplifier la lisibilité du code de l’application. Dans les autres
cas, on tente de donner chaque tâche à un agent différent. Ainsi les tâches sont distribuées
de façon maximale ce qui simplifie la distribution physique des charges.
Si les développeurs de l’application décident de recycler du code (voir dans la troisième
partie de la phase d’analyse), ils doivent considérer, lors de cette étape, comme granularité
la plus fine celle du code à recycler. De cette façon, ils considèrent deux tâches qui sont
traitées par le même composant recyclé comme une seule tâche.
A cause des composants logiciels datant des versions précédentes, la granularité de
DOGS multiagent était assez épaisse, ce qui a considérablement simplifié cette étape de la
conception. Lors de cette étape, nous avons spécifié plusieurs types d’agents associés avec
les processus majeurs du programme. La première catégorie d’agent a été conçue dans le
but de construire les équations théoriques associées au circuit électronique. Elle se divisait
naturellement en sous catégories capables de reconnaître les équations caractéristiques
des différents niveaux d’abstraction du système (en effet les équations obtenues sont très
différentes selon que le système est observé au niveau des blocs très abstraits (intégrateurs,
diviseurs . . . ), au niveau des portes logiques ou au niveau des composants. Un agent
unique sert d’intermédiaire entre l’opérateur et le système (il n’y a pas besoin d’en avoir
plusieurs tant qu’il n’y a qu’un seul opérateur). Il faut noter que tout portait à penser
que l’opérateur serait le “maillon faible” en terme de rapidité d’exécution de l’application
dans son ensemble, il fallait donc tenter d’optimiser ses interactions avec le système, c’est
le but de cet agent. Un agent de calcul et de résolution d’équations était aussi absolument
nécessaire. Dans la première version de DOGS multiagent, il était unique, l’analyse des
moyens mis à notre disposition, nous a cependant permis de constater qu’ils pouvaient
être plus nombreux, l’analyse des tâches nous ayant montré que les calculs pouvaient
généralement être exécutés en parallèle, nous avons donc décidé de remplacer l’agent
unique par plusieurs agents plus spécialisés. DOGS multiagent comprend d’autres agents
aux tâches assez spécifiques ou assez éloignées des buts de l’application elle-même (agents
de surveillance destiné à traquer les erreurs et à remonter leur piste, agent de gestion
système qui vérifie le bon état de l’application et de son support informatique . . . ), les
agents cités ici sont les plus importants.
85
3.3.2 Description des interactions

La seconde étape du processus de conception de la société du système est l’évaluation
des communications. D’une certaine façon, après avoir conçu les individus du système
multiagent, nous construisons la société qui les englobe. De façon plus pratique, il faut,
lors de cette étape, réussir à différentier les tâches qui sont théoriquement parallélisables
mais qui partagent tellement de ressources (qu’elles soient matérielles, données ou autre)
que le coût du parallélisme sera supérieur au gain des tâches qui seront facilement phy-
siquement distribuées. Théoriquement, il faudrait que cette étape et la précédente soient
menées en parallèle. Comme cela augmenterait grandement la complexité de la conception,
nous simulons cette simultanéité en tentant d’atteindre récursivement une bonne solution.
Ainsi, une fois les agents conçus, il faut construire théoriquement leurs communications
et comparer le coût de ces communications avec les gains de “l’agentification”.
Il faut prendre en compte différents types de gains et de coûts :

– Les gains et les coûts de très bas niveau peuvent s’obtenir en comparant le coût
estimé des communications pour le ou les ordinateurs et pour le réseau (si le système
est physiquement distribué) et le gain du parallélisme sous forme de temps de calcul
et de décharge des sites.
– Il faut, ensuite, comparer les gains et coûts en termes de programmation pour vérifier
si les contraintes liées au parallélisme (contraintes sur les variables, construction
de sémaphores, etc.) et les difficultés liés à la programmation dépassent les gains
d’efficacité et d’encapsulation.
– Enfin, il peut être important pour certaines applications que le code soit relativement
simple à lire. Il faut dès lors tenter d’associer les tâches de façon “logique”. Cette
cause de modifications dans la conception des agents devrait être invoquée le moins
souvent possible car elle introduit de la subjectivité dans le processus de conception.
Il faut noter que cela peut nuire aux performances alors que ce qui paraît logique à
certains ne le paraît pas nécessairement pour d’autres.
3.3.3 Modélisation des agents

Une fois les agents construits, il est nécessaire de les décrire formellement, pour cela
nous utilisons plusieurs caractéristiques et l’agent est décrit en français courant. Il est
nécessaire de décrire les tâches telles que nous les obtenons lors de la phase d’analyse de
façon à pouvoir les utiliser pour construire le système multiagent. Les tâches sont regrou-
pées au sein d’agents. Cependant certains agents partagent la même tâche ou les mêmes
compétences. Pour des raisons de lisibilité de structure, nous ne considérons pas chaque
agent individuellement, nous utilisons donc des types d’agents ce qui permet de réunir
dans une même catégorie les agents ayant les mêmes capacités. Dans certains cas, des
agents du même type peuvent avoir des fonctions complètement différentes, c’est-à-dire
ne pas servir à résoudre les mêmes tâches. En effet, certaines tâches peuvent avoir été
associées au sein du même type lors de la phase d’analyse non pas pour des raisons de
coordination ou d’association logique mais parce qu’elles sont semblables sur le plan de
la résolution et qu’il aurait donc été redondant de créer un agent spécifique réalisant la
86
première et un réalisant la deuxième (leur code aurait été quasiment identique). Ainsi
l’existence de types d’agents semblables aux classes de l’objet nous apparaît une caracté-
ristique extrêmement souhaitable. Nous définissons donc les types puis enfin les agents.
Il faut noter que le travail présent ne participe qu’à la construction d’agents, or un SMA
peut ne pas être entièrement constitué d’agents. Les entités informatiques non-agents au
sein d’un SMA seront sans doute des “objets” dès lors, nous conseillons aux concepteurs
de systèmes de se référer aux méthodes objets pour concevoir ces entités.
Importance de la modélisation des agents
Lors de la troisième étape de la conception de la société des agents, les concepteurs

doivent modéliser le contenu des agents eux-mêmes. Ils doivent maintenant prendre en
compte ce qu’ils savent de leurs tâches (3.2.1) et des composants à recycler qu’ils devront
intégrer dans ces agents (3.2.3), il devient dès lors possible de construire un modèle de
chaque agent adapté aux tâches qu’il va devoir réaliser. Il faut noter que des agents BDI
[RGI92] (agents dotés de croyances, de désires et d’intentions) ne s’utiliseront pas dans
le même cadre que des agents de type “fourmis” (qui sont des agents très simples n’ayant
pas d’indépendance). Il ne faut pas non plus encapsuler des tâches très simples dans des
agents très complexes car le fonctionnement des agents ne doit pas consommer toutes
les ressources (elles sont réservées dans la mesure du possible aux tâches elles-mêmes).
Si plusieurs tâches assez différentes sont réalisées par le même agent, elles peuvent être
assimilées à des rôles, lesquels peuvent être très indépendants les uns des autres. Figure
3.3, une tâche est donnée à une catégorie d’agents B alors que les deux autres sont donnés
à des agents parallèles de type A. On constate ensuite que la tâche donnée à B pourrait
être “ ‘coupée” en plusieurs tâches parallèles.
Lorsque les agents ont été conçus dans leur intégralité, il peut devenir apparent que
certaines tâches ont été séparées, alors qu’elles auraient du être associées (ou inversement),
on reprend donc le processus à la première étape pour les agents litigieux, de façon à
corriger les défauts en repartant sur de nouvelles bases. Il faut répéter le processus jusqu’à
ce que le résultat soit satisfaisant. S’il apparaît que la méthode de construction récursive
ne tend pas vers une bonne solution, il faut reprendre les étapes d’analyse et améliorer la
granularité de cette dernière.
Description des types d’agents
Lors de la première partie de la construction du système multiagent à proprement

parler, nous devons décrire les types d’agents.
Les types d’agents sont naturellement liés aux tâches qu’ils sont censés réaliser. C’est
naturel puisqu’ils ont été définis lors du découpage de l’application. Les types sont décrits
suivant différentes caractéristiques, la plupart sont décrites en langage naturel (ici le
français), les autres sont explicitées dans le texte.
– NOM : chaque type a une dénomination unique (semblable au nom des classes en
programmation objet). Il permet de connaître les caractéristiques et les compétences
d’un agent spécifique.
87
– CAPACITES : les capacités d’un type d’agent regroupent les descriptions de toutes
les compétences rattachées à un type d’agent. Elles sont tirées des tâches de la phase
analyse et leur description a donc la même granularité que cette dernière. Elles sont
représentées par les noms des tâches auxquelles elles sont associées.
– FONCTIONS POTENTIELLES : cette caractéristique permet de déterminer quel
type d’agents peut réaliser telle ou telle tâche. Certains types n’ont qu’une seule
fonction potentielle alors que certains types d’agents très puissants pourraient po-
tentiellement tout faire.
Une fois la description des types d’agents terminée, il est nécessaire de construire la
description des agents eux-mêmes de façon individuelle. Il faut noter que chaque agent
n’est pas nécessairement décrit individuellement (cela impliquerait que le nombre d’agent
est une donnée statique alors qu’elle dépend généralement des spécificités de chaque uti-
Tâches
données à
deux agents
de type B
Communications des
agents de type B vers
les agents de type A
Tâches
données à
deux agents
de type A
Fig. 3.3 – Exemple de distribution de tâches entre deux types d’agents
88
lisation de l’application construite. Les différents agents ayant exactement les mêmes
caractéristiques sont réunis sous la même description type.
Les agents ont plusieurs caractéristiques que nous allons citer et expliciter maintenant :
– NOM : le nom est l’identifiant de l’agent, il est unique et permet d’identifier un
interlocuteur.
– PARENT : le parent d’un agent est l’agent qui a commencé son exécution. Si tous
les agents sont créés par un système central, c’est ce système qui est le parent de
chacun des agents. Dans le cas contraire le parent permet de suivre la hiérarchie
de construction des agents et potentiellement de vérifier si certains d’entre eux ne
travaillent pas dans le vide (par exemple parce que leur parent qui attendait d’eux
un résultat a été arrêté).
– TYPE : chaque agent a un type. Les types forment une pyramide de l’ensemble des
agents assez semblable aux classes de l’objet. L’héritage est possible sur les types,
cependant le type d’un agent est dès lors le type le plus restrictif tel que l’agent y
réponde. (Par exemple, Titi est un canari même si canari hérite de oiseau qui hérite
d’ovipare etc.). Chaque type est lui-même décrit (voir plus loin). Ici nous utilisons
le nom du type de l’agent (il est unique) pour reconnaître le type de cet agent.
– FONCTION : la fonction de l’agent est une description textuelle de son rôle au sein
du système multiagent. En général, elle recoupe le type de l’agent car une fonction
est souvent assignée à tous les éléments d’un même type. Cependant, si les agents
pour une raison quelconque sont “généralistes”, il est possible que plusieurs agents
du même type n’aient pas la même fonction.
– MIGRATEUR/SEDENTAIRE : un agent migrateur peut potentiellement se dépla-
cer d’un ordinateur vers un autre alors que qu’un sédentaire reste toujours sur le
même site (par exemple les agents gérant un ordinateur sont probablement séden-
taires alors que la plupart des agents serait plutôt migrateurs (même s’ils ne migrent
pas dans les faits).
– COOPERATIFS/PARTIELLEMENT COOPERATIFS/TOTALEMENT COMPE-
TITIFS : un agent coopératif répond toujours positivement aux requêtes d’aide, les
agents compétitifs exigent toujours une contrepartie. La plupart des agents devrait
appartenir à la catégorie intermédiaire des agents qui accepte les requêtes d’aide
plus ou moins régulièrement. Cette classification est nécessaire pour que les autres
agents puissent construire leurs requêtes en conséquences. Nous ne plaçons pas cette
information dans le type des agents puisque certains agents peuvent être plus ou
moins coopératifs non pas en fonction de leur rôle mais des ressources qui leur sont
allouées.
Nous ne décrivons pas les messages de données potentiels puisqu’ils peuvent être de
toute nature (aussi bien des objets que des données typées ou des chaînes de caractères).
Ils doivent cependant être décrits lors de la construction des agents. Il faut alors spécifier
leur nature, leurs valeurs potentielles (c’est-à-dire l’ensemble de définition de la fonction
de l’agent destinataire lorsqu’il les réceptionne).
La construction des interactions dans DOGS a été relativement simple et comme le
grain était assez important, nous n’avons pas eu à faire beaucoup d’ajustements lors
de la phase récursive de la méthode de conception. Il nous est cependant apparu que
certaines interactions pouvaient être difficiles à concevoir ou à vérifier (essentiellement les
89
interactions liées aux corrections d’erreurs faites précédemment).
3.3.4 Construction du modèle du système multiagent et descrip-

tion des interactions entre les agents
Dans l’étape précédente, nous avons distribué les différentes tâches entre les agents,
cependant cela ne suffit pas à définir les agents. Nous allons donc maintenant présenter la
méthode de construction du modèle des agents. Pour cela, nous considérons qu’un agent
est constitué d’un module de travail, d’une mémoire et d’un module de communication
qui sera décrit plus loin. Dans ce qui suit, aucune règle de construction du module de
travail et de la mémoire n’est décrite, elle ne pourrait pas prendre en compte tous les cas
de figure. Le module de travail (MT) sera donc représenté par un ensemble de réseaux de
Petri et la mémoire (MEM) sera l’environnement local de ces réseaux.
Les MT de chaque agent sont différents des réseaux de Petri des tâches qui leur ont
été allouées. La différence est due à l’indépendance des agents, les MT baignent dans la
MEM des agents alors que les tâches originelles baignaient dans l’environnement global
du programme.
Deux choses doivent donc pouvoir se transmettre d’un agent à l’autre, les jetons et
les informations qui sont des transmissions de données entre les MEM des agents. Il
faut donc modifier les réseaux de Petri MT pour prendre en compte les communications
entre agents. On doit pouvoir vérifier la validité du programme, en prenant en compte les
messages transmis entre les agents.
Dans le cas décrit dans la figure 3.4, le réseau de Petri originel était un choix, on l’a
séparé en deux agents. On définit donc deux types de communications, les communications
d’information (de type b) et les communications de jetons (type a sur la figure). On ajoute
de nouvelles transitions pour gérer les communications (en gris sur la figure).
Fig. 3.4 – Un modèle de communication entre agents à base de réseaux de Petri
90
Le modèle ainsi obtenu prend en compte les communications.
La figure 3.4 présente rapidement notre modélisation du système multiagent (les com-
munications permettent à la fois le transfert d’informations et la synchronisation entre les
agents.
Notre mode de représentation des communications entre agents utilise deux types
différents de messages, les messages de données et les messages jetons. On pourrait penser
que cette représentation est donc très pauvre au vu des possibilités d’interactions entre
agents. Cependant, cela nous parait suffisant, en ce que les ordres, les autorisations peuvent
facilement être représentés comme des messages jetons, alors que les messages informatifs,
les conseils, les avis sont constitués d’un message jeton et d’un message informatif. La
différence entre ces différents messages est dans les processus qui précèdent et suivent
l’envoi et la réception du message. Ainsi, un ordre est un message jeton immédiatement
suivi de l’action auquel il se rapporte (c’est donc un message jeton lié à un état n’acceptant
qu’un seul jeton et suivi d’une transition n’acceptant qu’un seul jeton, une autorisation
est un message jeton lié à un état qui peut recevoir plusieurs jetons suivi d’une transition
en attendant elle aussi plusieurs. Ainsi, cette architecture de message peut paraître très
simple, cependant elle est très générique, ce qui peut permettre d’écrire une vaste gamme
de messages et donc de protocoles de communication et d’interaction.
De la même façon, cette méthode de description d’un message permet de représen-

ter indifféremment les communications synchrones et asynchrones puisqu’il suffit de dire
qu’une communication asynchrone voit son jeton placé dans un état suivi d’une transi-
tion qui exige un autre jeton pour être exécutée (ce jeton pouvant être générée de façon
cyclique ou lorsque la “boîte aux lettres” est pleine).
Ci-dessous, nous proposons une description en logique du premier ordre de notre re-
présentation destinée à permettre la vérification logique du système construit.
(∃A : Agent) (∃B : Agent) (∃a : Inf oMessage) (∃b : tokenMessage)
tq(∃α1 : State(A)) (∃α2 : State(A))
(∃KA : context(A)) (∃β : State(B)) (∃taA : token(A)) (∃tbA : token(A))
(∃KB : context(B)) (∃tbB : token(B))
tq(Senda (A, taA , α1 , KA )∧(receivea (a, B, KB ))∧(Sendb (A, tbA , α2 , b)∧(receiveb (B, tbB , β))
91
Avec Senda (X, x, y, z, t) pour X : Agent

x : token(X)
y : State(X)
z : inf o(X)
t : Inf oMessage
Sendb (X, x, y, t) pour X : Agent
x : token(X)
y : State(X)
t : tokenMessage
Receivea (t, X, z) pour X : Agent
t : Inf oMessage
z : inf o(X)
Receiveb (t, X, y) pour X : Agent
t : tokenMessage
y : State(X)
Nous utilisons une représentation spécifique pour décrire les relations macroscopiques
(entre les agents). Nous aurions pu nous contenter de représenter les tâches en utilisant
les réseaux de Petri récursifs, cependant cela pose un problème de contexte distribué. En
effet, les différentes tâches n’ont connaissance que des données incluses dans la mémoire
locale (celle de l’agent), alors que chaque transition du réseau de Petri d’origine baigne
dans l’environnement global. Notre représentation qui est inspirée des graphes conceptuels
nous permet de placer chaque tâche dans son environnement contextuel. L’utilisation de
deux types de messages différents permet de prendre en compte les questions de transferts
de données entre agents mais aussi de planification. Chaque message de données devrait
être accompagné d’un message jeton, en effet, il faut que l’agent, en tant que processus
sache qu’il vient de recevoir un nouveau message, cependant un message de type jeton peut
arriver seul puisqu’il peut simplement avoir été envoyé pour des raisons de planification
(par exemple par un agent gérant la puissance de calcul de l’ordinateur qui héberge
l’agent). Il était donc logique de construire une représentation qui se concentre sur les
communications entre agents, puisque l’environnement distribué et la communication par
envoi de message est une des spécificités des systèmes agents.
Comment vérifier la validité du SMA

Dans cette partie, nous allons montrer comment l’on peut vérifier la validité d’un SMA.
Pour cela, il faut montrer que son exécution est équivalente à celle d’un réseau de Petri
représentant la tâche à réaliser. Il faut donc montrer que toutes les exécutions possibles
du réseau de Petri sont réalisées dans le SMA et inversement.
Nous préconisons de montrer ceci en deux étapes : d’abord comment montrer que
toute exécution du SMA est incluse dans le réseau de Petri puis que toute exécution du
réseau de Petri est incluse dans le SMA.
Notations
On appelle :
92
– RdP le réseau de Petri de l’application déplié jusqu’au niveau désiré.
– pour R un réseau de Petri :

– E(R) l’ensemble des exécutions possibles de R,
– T (R) l’ensemble de ses transitions,
– S(R) l’ensemble de ses états.
Définition 1
On appelle T 0 (R) l’ensemble des classes de transition de R. Une classe de transition est
définie par le fait que chaque élément de la classe a le même nom et la même garde.
∀(t1 , t2 ) ∈ T (R)2 , ∃t ∈ T 0 (R)2 tel que :
(t1 , t2 ) ∈ t ⇔ (garde(t1 ) = garde(t2 ))Λ(nom(t1 ) = nom(t2 ))
Si les réseaux de Petri considérés sont colorés, la garde est remplacée par la couleur du
jeton. En effet, si les jetons sont colorés, on peut différencier les différentes classes de
transition par la couleur du jeton qui peut les franchir, On n’a donc plus besoin de la
garde.
Il faut noter que T 0 (R) forme une partition sur T (R).
Définition 2
On appelle sous-réseau R0 d’un réseau de Petri R une sous-partie “continue” de ce
réseau. C’est-à-dire une séquence d’états et de transitions représentant une action (∀e ∈
S(R0 ), ∃x ∈ E(R0 ) telle que e est accessible à partir des états initiaux de R0 par x.
Une sous-partie constitue elle-même un réseau.
Définition 3
Pour une transition x appartenant à T (R), on appelle pre(x) (resp. post(x)) l’état (ou
un état) qui précède (resp. suit) x et pren (x) (resp. postn (x)) est un sous-réseau conte-
nant n composants (états et transitions) et terminant (resp. commençant) par pre(x)
(resp. post(x).
Définition 4
On appelle A l’ensemble des classes d’agents (une classe d’agent étant un ensemble
d’agents ayant la même représentation, c’est-à-dire le même réseau de Petri, les mêmes
variables locales et les mêmes entrées et sorties).
Définition 5
On appelle SM A l’ensemble de tous les agents et P le réseau de Petri de l’exécution
de l’application telle qu’elle est envisagée (selon les cas il faut vérifier que l’exécution du
93
SMA construit colle bien à celle décrite par le réseau de Petri ou l’inverse).
∀a ∈ A, on appelle I(a) les instances de a, on a CardI(a) ≥ 1
∀ag ∈ SMA (resp. ∀a ∈ A), on appelle RdP (ag ) (resp. RdP (a)) le réseau de Petri local
inclus dans cet agent (resp. cette classe d’agents).
Définition 6
Deux exécutions sont équivalentes si les mêmes actions sont déclenchées dans le même
ordre ou dans un ordre équivalent (c’est-à-dire si elles ont le même graphe de marquage).
Propriété (premier sens)

En utilisant ces notations, il faut montrer que toute exécution du réseau de Petri re-
présentant les exécutions possibles de l’application est une exécution possible du système
multiagent. Pour cela, on doit montrer que tout sous-réseau du réseau de Petri global se
retrouve dans le SMA, c’est-à-dire que soit il est inclus dans le réseau de Petri de l’un des
agents (1) soit il existe un ensemble d’agents qui l’exécutent ensemble en communicant(2).
Donc cela revient à :
Pour q un sous-réseau de RdP ,
soit (1) ∃! ag ∈ SM A tel que ∃!q 0 ∈ RdP (ag ) tel que q 0 = q,
soit (2) ∃! (a1 . . . an ) ∈ SM An tel que :
∀x ∈ T (q), ∃! i ∈ {1, . . . , n} , tel que ∃! x0 ∈ T (RdP (ai )) tel que : Classe(x) =
Classe(x0 ) et soit (z1 , z2 ) = (pre(x), post(x)),
on a Classe(pre(x0 )) = Classe(z1 ) et Classe(post(x0 )) = Classe(z2 ),
tels que :
soit Classe(post(post(x0 ))) = Classe(post(z2 )), (3.1)
soit post(x0 ) est terminale et entraîne l’envoi d’un message. (3.2)
d’une part, et :
soit Classe(pre(pre(x0 ))) = Classe(pre(z2 )), (3.3)
soit pre(x0 ) est initiale et reçoit un token d’un message. (3.4)
Si on a 3.2, cela signifie qu’il y a un unique agent qui reçoit ce message et continue
l’exécution (il est du type 3.4), on peut donc écrire dans ce cas : ∃j ∈ Card(T (RdP (ai )),
j ≥ 1 tel que :
– ∃k = postj (x0 ) et ∃q ⊂ RdP (ai )

– et q = k avec Classe(initial(q)) = Class(post(x))
– et ∃!t ∈ T (SM A) tel que t(post(x0 )) = initial(q).
94
propriété (second sens)

On a vérifié que les exécutions de l’application sont réalisées par le système muultiagent
construit. Il faut donc encore montrer que toutes les exécutions du SMA sont des exécu-
tions de l’application telle qu’elle est décrite par le réseau de Petri global. Il faut donc
montrer que :
∀a ∈ SM A, ∀x ⊆ RdP (a),
tel que le premier état de x est initial et la dernière transition est terminale,
∃!x0 ∈ RdP , tel que x = x0 .
∀a0 ∈ SM A tel que ∃s un état initial de RdP (a0 ),
∃t un message de type token, tels que t(terminal(x)) = s.
et
∀i ∈ N tel que posti (s) ∈ RdP (a0 ), ∃posti (x0 ) = posti (s).
Comment considérer les transferts de données

Il est aussi nécessaire de prendre en compte les transferts de données entre les environne-
ments des RdPs de chacun des agents. En effet, les agents ne partagent pas leur mémoire,
alors que le RdP de l’application, lui, baigne dans un environnement global. C’est pour
cette raison que les agents interagissent grâce à deux types de messages : les messages
de token et les messages de données. Les premiers ont montré leur utilité précédemment,
mais il faut encore montrer l’utilisation des seconds.
Soit a ∈ SM A,
∀tr ∈ T (RdP ),
∀d une donnée telle que ∃c ∈ Garde(tr) telle que c dépend de d,
∀a0 ∈ SM A, tel que ∃x ∈ T (RdP (a0 ))
telle que le passage de x change la valeur de d,

alors l’exécution de x doit entraîner l’envoi d’un message de a0 vers a contenant les
modifications sur d.
reconnaissance des jetons

Enfin, il faut noter que si les réseaux de Petri utilisés pour décrire le système ne sont pas
colorés, un message de jeton (token) doit être accompagné d’un message de données per-
mettant le déblocage de la garde de la première transition du réseau de Petri “destinataire”
du jeton dans l’agent recevant ce message.
Cependant, il est simple de considérer qu’un jeton transmis par un message arrive
toujours jusque dans l’état auquel il est destiné.
95
3.4 La distribution physique des agents

3.4.1 Placement des agents
Placer les agents sur un réseau de façon à optimiser l’utilisation de la puissance de
calcul et minimiser le poids des communications est difficile. Pour le résoudre, il est souvent
nécessaire d’émettre des hypothèses simplificatrices. La plus utilisée de ces hypothèses est
la nullité du poids des communications qui est inacceptable dans notre cas. Il faut donc
modéliser le système informatique sur lequel le SMA doit être implanté et appliquer les
méthodes de recherche opérationnelle (on peut utiliser des méthodes allant du TABU à
la génération de colonne [Dea98] selon la complexité du problème).
3.4.2 L’expérience de DOGS

La troisième étape de notre méthode de conception de systèmes multiagents n’existe
en général pas dans les autres méthodes (lesquelles se limitent souvent à la “conception”
du SMA). L’un des plus grands avantages, en termes de performances des SMA est qu’il
est relativement simple de distribuer physiquement les agents sur un système multiproces-
seurs. Cependant, pour être efficace, cette distribution doit être réalisée suivant certaines
règles. Si deux agents interagissent énormément, il est préférable qu’ils soient “proches”
l’un de l’autre (c’est-à-dire que leurs communications soient les moins coûteuses possibles).
Il est donc nécessaire de distribuer les agents de façon réfléchie. Il est souvent impossible
de savoir combien d’agents seront nécessaires à la résolution d’un problème (dans DOGS
par exemple, le nombre d’agents blocs nécessaires à la vérification et au diagnostic d’un
circuit électronique n’était pas connu à l’avance car les agents blocs abstraits instancient
des agents capables de vérifier des blocs de moindre abstraction quand un problème appa-
raît). On doit donc avoir un outil permettant de distribuer correctement les agents entre
les sites en cours d’action. La solution la plus simple pour obtenir ce résultat [Cyb89] est
de comparer régulièrement l’encombrement des sites et de placer les agents sur le site le
moins encombré. Cependant cela pose un problème car cela ne prend pas en compte les
communications des agents (voir plus haut).
Les utilisateurs doivent donc choisir un outil de distribution d’agents sur leur système
informatique qui puisse minimiser le coût des communications. Nous proposons une solu-
tion partielle dans le chapitre suivant. Cependant, les solutions envisagées doivent suivre
les deux principes suivants qui sont assez contradictoires, il faut donc tenter de trouver
des compromis acceptables.
– Les agents doivent toujours avoir assez de puissance de calcul pour fonctionner
correctement, il faut donc que les agents soient placés de façon à ce que la puissance
de calcul disponible soit partagée proportionnellement aux besoins de chacun des
agents.
– Des agents qui interagissent beaucoup devraient être placés de façon à ce que le
coût de leurs communications soit minimal, ce qui signifie que dans une situation
optimale, ils devraient être placés sur le même ordinateur.
La qualité de la distribution dépend de ces deux principes. Il faudrait aussi prendre en
considération les qualités et les défauts de chacun des sites disponibles dans le cas d’un
96
3.5. Conception et implantation des protocoles d’interaction et de communication
système hétérogène. Les systèmes Windows et UNIX ne gèrent pas les tâches parallèles de
la même façon, certains agents peuvent profiter plus de l’un des modes de gestion que de
l’autre. Le disfonctionnement d’une seule des machines peut nuire à la distribution dans
son ensemble. La distribution de charge peut améliorer la stabilité du système dans son
ensemble mais elle exige aussi une gestion avancée des pannes car on peut avoir des pannes
difficilement détectables, des problèmes sur l’un des sites alors que les autres fonctionnent
normalement, etc.
Dans DOGS, nous avons décidé de placer un seul agent calculateur sur chaque site, car
ils exigent énormément de puissance de calcul et peu d’entrées sorties. Etant donné que
ces agents sont spécialisés il faut tenter de placer les agents blocs qui leurs sont associés
au plus près d’eux.
Dans le cas très probable où il est difficile de prévoir quels agents interagiront préfé-
rentiellement, il peut être possible de construire la distribution en fonction des résultats
des tentatives précédentes. Nous avons envisagé de proposer une solution récursive pour
construire cette répartition. Si la distribution réalisée ne s’avère pas satisfaisante lors d’une
utilisation du programme, on devrait tenter de la corriger pour la prochaine utilisation
(on construirait une méthode récursive de construction de la distribution des charges).
Cela présente deux problèmes :
– D’abord cela ne peut fonctionner que si la qualité d’une distribution ne dépend pas
trop des caractéristiques spécifiques du problème traité par le programme (dans le
cas de DOGS du circuit électronique considéré). Car si c’est le cas, la suite des
distributions construites ne peut pas converger, on ne pourrait donc pas améliorer
les résultats à venir en se basant sur les expériences précédentes. Il faudrait donc
vérifier la validité de ces hypothèses, si leur véracité ne dépend pas de l’application
elle-même.
– La seconde raison est que si la distribution de charge est nécessaire, c’est que l’appli-
cation est sans doute très lourde, lancer des utilisations tests destinées à valider ou
à améliorer la qualité de la distribution peut être très coûteux. De plus la validité de
toute distribution statique est limitée au système physique qui lui sert de support,
il faudrait donc reprendre le processus s’il le système informatique est mis à jour.
3.5 Conception et implantation des protocoles d’inter-

action et de communication
La plupart des systèmes multiagents ne laissent pas un choix très large en terme
de moyens de communication. Nous considérons qu’étant donné que l’un des principaux
avantages des SMA est leur distribution potentielle, les communications doivent être op-
timisées. La quatrième partie de notre méthode de conception de systèmes multiagents se
focalise sur les communications et les interactions. Les deux sous-parties de ce chapitre
traitent respectivement des interactions entre les agents pour la première partie et des
moyens de communications qui serviront de support à ces interactions.
Pour ces deux raisons, nous n’avons pas creusé plus avant cette idée au cours de cette
thèse, et nous nous sommes contentés de proposer une solution qui permette la redistri-
97
bution des charges au cours de l’exécution. Cela ne permet sans doute pas de corriger
une erreur lourde de conception lors des étapes précédentes, mais cela peut permettre de
compenser une légère erreur lors de la distribution statique.
3.5.1 Les interactions

Les protocoles d’interaction entre les agents doivent être construits sans dogmatisme.
Il est préférable de prendre en compte les résultats de la phase d’analyse lors de cette
étape. La question à laquelle il faut répondre ici est la suivante : “avec qui chaque agent
va-t-il interagir ?”
Si le SMA n’est qu’une partie d’une plus grande société d’agents, ce qui signifie qu’il est
possible que les agents aient à interagir avec des agents des autres SMA, il est important
de savoir quel agent interagit avec les agents des autres systèmes de façon à pouvoir
construire des protocoles communs aux deux systèmes. Pour simplifier ces situations, il
est possible d’utiliser les protocoles standards (comme ceux de la FIPA) mais ils faut bien
sûr que les concepteurs des autres systèmes les aient implantés eux aussi. Si le système
est isolé, les interactions peuvent être beaucoup plus proches de l’ingénierie logicielle,
et utiliser simplement des envois de messages typés. Les interactions ne sont alors pas
aussi esthétiques que lors de l’utilisation d’actes de langages mais sont beaucoup plus
rapides puisqu’aucune étape de typage des données n’est nécessaire avant que les agents
ne puissent traiter les messages. C’est aussi plus solide et plus simple à réaliser, par
exemple simplement en construisant des sous classes d’une classe message spécifiques aux
différents types de message (en utilisant un langage orienté objet et typé).
3.5.2 Les communications

Une fois que les interactions entre les agents ont été correctement définies, les concep-
teurs du système multiagent doivent encore choisir les moyens de communication des
agents. Cela signifie qu’il faut choisir les protocoles de communication au sein de la pla-
teforme et la façon dont les agents accèdent aux communications. Par exemple, F. G. Mc
Cabe et K. L. Clark ont utilisé des sockets TCP/IP dans leur langage de programmation
d’agents APRIL “simplement parce que tout le monde le fait” [MCC94]. Les communi-
cations auront une incidence majeure sur les performances du SMA dans son ensemble,
il faut donc s’y intéresser sérieusement. Les communications à longue distance peuvent
très fortement ralentir le système dans son ensemble, l’envoi de message par une mémoire
distribuée prend au plus quelques microsecondes alors qu’un message TCP/IP met au
minimum quelques dizaines de microsecondes à atteindre sa cible (avec le système à notre
disposition chez THALES, nous obtenions des temps de 400 microsecondes au mieux sur
un système LAN 10 classique pour transmettre des objets JAVA entre une SUN-SOLARIS
et un PC). Mais TCP/IP n’est pas le seul protocole à la disposition des concepteurs. Sur
un réseau fermé sur lequel le pourcentage de messages perdus est négligeable, UDP/IP
peut être beaucoup plus efficace que TCP, il est aussi plus simple d’utilisation puisqu’il
permet de toucher tous les utilisateurs simultanément (broadcast). D’autres protocoles
sont aussi potentiellement utilisables comme IPX qui présente quelques avantages spéci-
fiques. Il faut noter que même si l’on a choisi TCP/IP, il reste de nombreux choix quant
98
3.5. Conception et implantation des protocoles d’interaction et de communication
au protocole utilisé.
Pour DOGS multiagent, nous avons choisi de baser notre système de communication
sur des datagrammes UDP/IP car cette solution fonctionnait bien sur un réseau local,
nous avons cependant permis des modifications à cette base en permettant à chaque
agent d’avoir un ou plusieurs modules de communication indépendants lui permettant
potentiellement de communiquer suivant d’autres protocoles si le besoin s’en faisait sentir.
Il existe de nombreux protocoles de communication lesquels ont des caractéristiques
spécifiques qui les rendent particulièrement adaptés à certaines utilisations, du transfert
de données lourdes (FTP) au transfert de vidéo en temps réel (RTP par exemple). Les
concepteurs devraient penser à ces protocoles spécifiques si les agents doivent se trans-
mettre certains types particuliers de données. Il existe aussi des protocoles spécifiques
conçus pour permettre l’utilisation de “broadcast” et de “multicast” (message envoyés à
un sous-ensemble de la population des recepteurs potentiels) [AW98], ces protocoles de-
vraient être envisagés lors de la construction d’un système multiagent. Les agents peuvent
même avoir plusieurs modules de communications et choisir selon la nature des messages à
transmettre, de la même façon que les humains n’utilisent pas les mêmes media lorsqu’ils
parlent du match de football de la veille avec leur voisin de bureau et lorsqu’ils envoient
un message ultra confidentiel à un destinataire aux antipodes. UDP n’est pas un protocole
sûr, cependant c’est suffisant lorsque les agents se trouvent sur un réseau local, ce ne le
sera pas si les agents doivent communiquer au travers de l’Internet.
Il y a une autre question que doivent se poser les concepteurs d’un système multiagent :
“qui doit communiquer ?” la réponse la plus simple est “les agents”, ce qui signifie que
chaque agent doit avoir son propre système de communication (dans DOGS, les agents
avaient tous un serveur et un client de socket UDP) chaque agent est alors complètement
indépendant du système dans son ensemble. Si cela peut paraître souhaitable du point
de vue de l’encapsulation spécifique du paradigme agent, les serveurs de communications
sont coûteux en temps du processeur et en entrées/sorties, cette indépendance a donc un
prix. Certains concepteurs préfèrent donc centraliser les communications distantes, par
exemple en construisant un agent “routeur” pour les communications distantes [MAD]. Il
faut pourtant noter que cet agent devient dès lors un goulot d’étranglement, ce qui peut
exiger certains efforts de logistique. Cela peut devenir assez lourd puisque même si un
seul agent est présent sur un site, la plateforme dans son ensemble doit être instanciée
(puisqu’elle inclut les communications).
Les agents totalement indépendants ont un avantage, ils n’ont pas besoin de tous les
protocoles utilisés au sein du système, seulement de ceux qu’ils utilisent eux-mêmes. Ils
peuvent aussi utiliser leurs modules de communication avec “intelligence” en choisissant le
media de la communication en fonction des paramètres du contenu du message, on pourrait
même utiliser des techniques d’apprentissage pour améliorer le choix des protocoles de
communication. Cependant un agent qui centraliserait les communications peut prétendre
à tous les avantages ci-dessus. L’existence de communications directes entre les agents
simplifie pourtant l’architecture du système dans son ensemble et peut aussi simplifier les
relations entre les agents du système et d’éventuelles applications extérieures en offrant
une alternative aux communications centralisées vers l’extérieur.
La meilleure solution se trouve sans doute entre ces deux possibilités (complète indé-
pendance ou centralisation) : seuls les agents qui ont le plus besoin des communications
99
externes pouvant envoyer et recevoir des messages distants. Il faut réfléchir au niveau
d’indépendance des agents, car cette indépendance est synonyme de redondance et peut
donc être à la fois une qualité et un défaut pour le système.
Dans DOGS, nous avons commencé à implanter des modules de communication utili-
sant des sockets TCP/IP mais ce n’était pas assez rapide car les communications bidirec-
tionnelles de TCP exigeaient que nous ouvrions et fermions continuellement les canaux
alors que les agents changeaient d’interlocuteurs, ce qui prenait quelques dizaines de mi-
crosecondes au moins. Nous avons donc opté pour l’utilisation de datagrammes UDP/IP
car ils permettent le broadcast, sont efficaces et simples à implanter puisque nous étions
sur un réseau fermé et qu’il n’y avait aucun problème de sécurité ni de perte de messages.
Comme nous l’avons écrit plus haut, la limite de la distribution est atteinte lorsque le
prix des communications dépasse le gain de la répartition. Il faut donc que les communi-
cations soient une préoccupation majeure des concepteurs de système multiagent.
100
Chapitre 4
La phase de redistribution dynamique

de la répartition : ASMAA
La troisième difficulté associée aux systèmes répartis, c’est la distribution des charges.
On peut montrer qu’une distribution a priori des charges, même théoriquement optimale,
ne permet pas toujours d’obtenir l’efficacité maximale, et ce parce que les modèles de fonc-
tionnement de réseau ne sont pas parfaits [ESHH01]. Il faut donc pouvoir redistribuer
les tâches pendant l’exécution. Pour ce faire, nous avons conçu un système de redistribu-
tion dynamique des charges utilisant des agents mobiles en nous basant sur le standard
MASIF. Comme nous l’avons dit, les agents, de par leur indépendance, sont relativement
faciles à distribuer sur un réseau, ils sont donc très adaptés à la résolution de problèmes
de distribution de charges. Cependant leur indépendance peut compliquer la situation,
car aucun agent n’a de connaissance globale du système, or la distribution de charge a
pour but l’amélioration des performances, non pas d’un agent, mais du SMA dans sa
globalité. Nous avons donc décidé d’utiliser un système d’agrégation de préférences basé
sur la négociation [VEFS01] pour décider de la façon de redistribuer les tâches durant
l’exécution.
4.1 Redistribution dynamique des charges : introduc-

tion de la mobilité
Dans l’étude précédente nous avons proposé une méthode de conception d’agents puis
leur affectation aux machines en tenant compte du poids de leurs communications et
de l’importance de leurs tâches. Cette distribution statique est faite a priori avant de
lancer l’exécution du système. Or, les agents sont autonomes et peuvent faire des choix
non déterministes ce qui peut engendrer des problèmes pendant l’exécution. Dans cette
section, nous allons présenter ces problèmes et proposer une solution basée sur les agents
mobiles.
101
Chapitre 4. La phase de redistribution dynamique de la répartition : ASMAA
4.1.1 La distribution physique des agents

Une des étapes importantes et déterminantes dans la méthode de conception du SMA
présentée est la distribution physique des agents dans un environnement ouvert. En effet,
cette distribution doit être faite de façon à avoir le minimum d’interactions coûteuses et
doit suivre deux principes :
– Les agents doivent toujours avoir la puissance de calcul nécessaire pour fonctionner
correctement. Ils doivent par ailleurs être assignés à des machines où la puissance
de calcul peut être partagée entre eux proportionnellement à leurs besoins.
– Les agents qui doivent communiquer ensemble fréquemment doivent être placés de
façon à ce que le coût de leur communication soit minimal. La solution optimale
serait de les placer sur la même machine.
Ces principes peuvent être contradictoires ce qui peut obliger le concepteur à chercher
le meilleur compromis. Or, pendant l’exécution, quelques problèmes (défaillance d’une
connexion réseau ou d’une machine, etc.) peuvent avoir lieu et donc dégrader les perfor-
mances du système. De plus, le système étant ouvert, le nombre des agents nécessaires à
la résolution du problème peut être inconnu dès le départ et peut varier durant l’exécution
aussi bien que le volume de leurs communications. C’est pourquoi il s’avère avantageux
d’opter pour une distribution dynamique qui s’adapte à tout changement survenant pen-
dant le temps d’exécution du système.
Pour atteindre cet objectif, nous proposons d’utiliser la technologie des agents mobiles.
Les agents mobiles sont capables de migrer d’une machine à une autre pour atteindre
une meilleure distribution qui minimise le coût des communications, réduit le besoin de
disponibilité de toutes les connexions du réseau et permet la tolérance aux fautes. En
revanche, pour migrer, les agents doivent avoir l’information “quand et vers où se déplacer”.
Pour prendre cette décision, l’état de tout le système doit être pris en compte (par exemple,
le nombre de messages échangés, la charge sur chaque machine, etc.). Pour cela, nous
avons besoin d’une vue globale du système tout en évitant les solutions centralisées qui ne
s’adaptent pas à l’aspect ouvert et distribué de notre problème. Nous devons également
écarter la possibilité où chaque agent est responsable à lui seul de sa décision de migration
puisqu’il aura à négocier avec tout les autres agents ce qui accroîtra de plus en plus le
nombre des communications. Par conséquent, la décision de migration ne doit être prise,
ni par les agents ni par un composant central, mais par un niveau intermédiaire entre les
deux qu’on présentera dans la section suivante.
4.1.2 La décision de migration

Besoin d’un cadre architectural
Pour pouvoir se déplacer correctement, les agents mobiles ont besoin tout d’abord
d’une structure commune présente sur chaque système pour leur accueil et leur gestion.
En effet, les plates-formes d’agents mobiles doivent fournir plusieurs services tels que la
gestion du cycle de vie, la localisation, la migration, la communication et le contrôle de
sécurité. Un autre service fondamental est l’interopérabilité pour permettre aux agents
de se déplacer entre plates-formes hétérogènes. Un standard en la matière a été mis en
place par le Object Management Group (OMG) sous le nom de MASIF : Mobile Agent
102
4.1. Redistribution dynamique des charges : introduction de la mobilité
System Interoperability Facility [MAS, MBB+ 98, MBB+ 99]. MASIF est basé sur les
concepts systèmes d’agents (agence), places et régions. Une place regroupe les fonction-
nalités à l’intérieur d’une agence encapsulant certaines capacités et restrictions pour ses
agents. Chaque agence comprend au moins une place dans laquelle des agents s’exécutent.
Une région facilite la gestion de la plate-forme en regroupant des agences appartenant à
la même autorité. Le noyau de MASIF est formé par deux interfaces : l’interface MA-
FAgentSystem associée à chaque agence et fournit des opérations pour la gestion et le
transfert des agents, et l’interface MAFFinder associée à chaque région pour supporter la
localisation des agents, places et agences (voir figure 4.1).
Fig. 4.1 – Architecture de plate-forme conforme à MASIF [MAS]
Les acteurs de la migration

L’envoi des agents dont le fonctionnement devient trop encombrant (surcharge d’une
machine, communications intenses avec un partenaire distant, etc.) vers d’autres sites a
pour but de ramener le système à un état équilibré le plus possible. Dans le paragraphe
4.1, nous avons montré que la décision de migration doit être prise ni par les agents ni par
un composant central mais par un composant intermédiaire qui pourra avoir une vision
globale de l’état du système. Dans ce travail, nous proposons de munir chaque agence d’un
agent stationnaire spécifique, le manager, qui aura la tâche d’observer le fonctionnement
des agents résidants dans l’agence et gérer les migrations éventuelles (voir figure 4.2).
Dans la phase statique (décrite dans le paragraphe 3.4, une fois les agents assignés aux
machines chacun d’entre eux aura connaissances des agents avec qui il va communiquer.
103
Fig. 4.2 – Prise de décision de migration
Pendant l’exécution, notre idée consiste à permettre à chaque agent de garder une trace
locale de la fréquence, l’intensité et les partenaires de ses communications. Le besoin de
migration peut être déclenché de deux façons :
1. Puisque chaque agent conserve une trace locale de ses communications, il peut re-
pérer celles qui sont les plus fréquentes et les plus coûteuses. Il contacte alors le
manager de son agence et lui émet son souhait de se rapprocher de l’agent distant
avec qui il a des communications importantes. Ce manager contacte à son tour le
manager de l’agence où se trouve l’autre agent et négocie avec lui le meilleur scénario
pour rapprocher les deux agents. Ce déplacement des agents doit prendre en compte
certaines contraintes telles que la capacité de la machine sur laquelle ils vont mi-
grer et ne doit pas aussi condamner les autres communications. En effet, rapprocher
deux agents pour faciliter leurs communications ne doit pas empirer l’état d’autres
communications. La décision de migration est basée sur un consensus que doivent
atteindre les deux managers selon un processus qu’on présentera plus tard dans ce
document.
2. Périodiquement, les agents envoient la trace locale de leurs communications aux
managers de leurs agences qui peuvent ainsi former une trace globale des communi-
cations de l’agence. Ils font l’analyse de ces communications et négocient entre eux
pour décider quels agents déplacer afin d’améliorer l’état du système. L’atteinte de
consensus entre managers se fera selon le processus signalé dans 1.
Dans les deux cas, les managers doivent être en liaison avec l’interface du MAFFinder
104
4.2. Conclusion
qui permet de retrouver l’emplacement de chaque composant de la région. En fait, le

MAFFinder est le composant d’enregistrement dans lequel est noté l’emplacement de
chaque agent, place et agence. Par exemple, lorsque le manager d’une agence reçoit une
demande d’un agent pour se rapprocher d’un autre spécifié par son nom, il consulte le
MAFFinder qui lui retourne l’adresse de l’emplacement où se trouve l’agent indiqué.
Réalisation
Pour l’implémentation de ce travail, nous avons commencé par le module de migra-
tion. Dans la littérature, deux types de mobilité existent : mobilité forte et mobilité faible
[MBB+ 98]. La première permet la transmission des données et l’état d’exécution d’un
agent, la seconde ne permet que la transmission des données d’un agent. Pour la réali-
sation de nos agents, nous avons choisi d’utiliser Java puisque c’est un langage qui les
avantages de portabilité, polymorphisme, mobilité du code, etc. Mais la machine virtuelle
de Java (JVM) ne permet pas de capturer l’état d’exécution des threads qui permettent
la programmation des agents. Nous avons alors implémenté une migration faible. Les
managers sont des processus qui tournent continuellement à l’écoute des requêtes de mi-
gration. Ces processus sont basés sur des threads qui communiquent par des trames TCP.
Les agents qui souhaitent migrer ainsi que les managers utilisent des sockets pour leurs
connections. En effet, lorsque un agent se connecte à un numéro de port sur lequel tourne
un manager, un nouvel objet socket est alloué à l’agent pour servir à sa communication
puis le manager reprend son écoute.
4.2 Conclusion
Dans cette partie, nous avons présenté une méthode de conception et d’implémentation
de systèmes multi-agents pour la résolution de problèmes distribuée. Notre but était que
les avantages des SMA en matière de distribution physique des tâches soient, autant que
possible, mis en valeur.
Ici, les agents sont entièrement coopératifs puisqu’ils fournissent aux managers toutes
informations concernant leurs communications. Mais, notre but est de pouvoir appliquer
la même base au partage de ressources informatiques par plusieurs utilisateurs. Cela pose
de nombreuses difficultés puisque les agents ne seront plus coopératifs mais compétitifs
puisqu’ils devront optimiser leur propre fonctionnement même au dépends de tous les
autres.
Nous nous intéressons, de plus, aux modifications à apporter pour pouvoir faire adap-
ter notre méthode à l’implémentation de SMA sur des systèmes ouverts (comme une
association de possesseurs d’ordinateurs reliés par Internet). Cette dernière perspective
pause de nombreux problèmes, à la fois à cause de potentielles failles de sécurité et des
difficultés liées aux systèmes ouverts mais aussi à cause de l’hétérogénéité des machines
ainsi reliées. Ce dernier problème pourrait être facilement résolu grâce à l’utilisation de
JAVA.
105
106
Chapitre 5
Un modèle d’agent centré autour de la

distribution des charges et des
communications
Notre conception, très utilitaire, des agents nous pousse à avoir une vision très concrète
de ces derniers. C’est cette idée de l’agent que nous allons décrire ici. D’une certaine façon,
les définitions habituelles des agents sont souvent très abstraites et ne correspondent donc
pas à notre vision plus pratique des agents. Nous proposons donc ici un modèle d’agent
qui corresponde mieux à nos besoins, d’autant plus qu’il est suffisamment générique pour
prendre en compte les différents types d’agents qui peuvent être considérés lors de la
conception d’un système multiagent (voir les sections précédentes).
On pourrait considérer que cela n’a pas d’importance, pourtant, un modèle logiciel est
destiné à simplifier la programmation en posant clairement tout ce qui doit être pris en
compte lors de la conception d’un système. En ce sens, un modèle d’agent doit prioritai-
rement rappeler les caractéristiques des agents que les concepteurs peuvent avoir survolé
trop rapidement, et leur contenu intelligent ne fait pas partie de celles-là.
Sur de nombreux plans, l’agent que nous allons décrire dans la suite est extrêmement
anthropomorphe (comme le montre notre schéma), il ne se définit pas par ses entrées et
ses sorties mais plutôt par ses différentes interactions avec le monde extérieur. Ainsi, nous
ne présumons en rien, ni de forme finale implémentée (du nombre de processus etc.) ni
de la représentation de la partie “intelligente” ou réactive de l’agent. D’une certaine façon
notre modèle d’agent est uniquement physionomique.
L’agent se répartis en plusieurs “modules” (Figure 5.1)(c’est le terme que nous uti-
liserons pour décrire les différentes caractéristiques qui font d’un objet informatique un
agent) :
– Il possède un module de réflexion et d’action, c’est lui qui agit sur l’environne-
ment mais aussi qui analyse les connaissances sur l’environnement décide des actions
à réaliser en fonction de ses connaissances. C’est dans ce module que l’on construit
la représentation (cognitive ou non) de l’agent, qu’il soit BDI, réseau de neurones
ou objet construit en programmation logique.
– Il est construit autour d’un module central, lequel sert simplement de lien entre
les autres modules. Ce module n’est pas nécessaire mais il permet de construire des
107
Chapitre 5. Un modèle d’agent centré autour de la distribution des charges et des communications
Module de réflexion
Interface Messages et de travail. (à
système mono construire en fonction
de de chaque utilisation)
gestion
Module central
Module
d’interaction
Modules de
communication
spécifique ou de
mouvements…
Client Serveur
Fig. 5.1 – Notre modèle d’agent “le danseur de Maccarena”
agents dont les composants sont interchangeables ce qui peut présenter un important
gain de temps lors des phases d’implantation.
– L’agent peut être doté d’une interface de contrôle (les agents que nous avons
conçus pour DOGS en étaient dotés). Cela permet de surveiller le bon fonctionne-
ment du système et en cas de problème de tenter de régler la situation (en “tuant” des
agents, en relançant des tâches . . . ). L’interface de contrôle n’est pas normalement
destinée à l’utilisateur de l’application mais aux concepteurs et aux administra-
teurs du système qui doivent pouvoir corriger les erreurs potentielles. Nous avions
de plus doté nos agents d’un système de “log” qui note dans un fichier toutes les
actions réalisées. Il faut cependant noter que les accès disques étant extrêmement
longs comparés aux autres actions, cela ralentit énormément le système dans son
ensemble.
– Les agents sont des entités “sociales” en ce qu’elles communiquent non seulement
avec l’utilisateur mais aussi ensemble. La dernière fonctionnalité essentielle des
agents réunit ses différents moyens de communications. Elle est décrite sous l’ap-
pellation “module d’interaction”. ce module peut être séparé en différents sous
108
modules comme par exemple les modules de communication ou les modules de
déplacement. Les modules de communications peuvent être nombreux pour un seul
agent car les agents, comme les humains, doivent pouvoir utiliser différents media
en fonction de leurs interlocuteurs. Par exemple, il est normalement très préférable
de communiquer par partage de mémoire lorsque c’est possible (quand les deux in-
terlocuteurs sont deux “threads” placés sur le même processeur, etc.). même lorsque
les communications sont distantes, il faut choisir son protocole de communication
en fonction de ses besoins. Il peut donc être préférable que les agents aient plusieurs
media de communication à leur disposition. On peut imaginer de construire des
communications centralisées (au moins pour les communications distantes), dans
ce cas chacun des modules de communication est alors l’interface entre les autres
modules de l’agent et les outils de communication centralisés. Les modules de
mouvement sont une abstraction représentant les différents outils nécessaires à la
migration dans le cas où les agents sont mobiles. Ils contiennent les différentes fonc-
tions nécessaires au transfert des agents (migration forte ou faible . . . ) mais aussi
les différentes fonctions nécessaires aux autres étapes d’une migration (demande de
migration . . . ). Le schéma présente un agent ayant un module de communication
lui-même constitué d’un client pour les envois de messages et d’un serveur pour les
réceptions (utilisant des datagrammes UDP par exemple).
109
Chapitre 5. Un modèle d’agent centré autour de la distribution des charges et des communications
110
Chapitre 6
Résultats obtenus
6.1 L’architecture des premières versions d’Arès

Dans cette partie, nous allons décrire les différents agents de l’application distribuée de
diagnostic de circuits électroniques. Etant donné que d’autres versions ont succédé à celle-
là, il se peut que l’architecture de la version actuelle de l’application diffère sensiblement
de celle que nous allons décrire ici. Il faut déjà noter que les modèles de communications
que nous avions réalisés lors de la conception de cette version préalable se sont avérés
finalement inapplicables car SICS la société qui produit SIXTUS PROLOG [SIC03],
(pour PROLOG en Général [SS86]) n’avait pas vraiment respecté le cahier des charges
annoncé. Il a donc été nécessaire de refondre complètement les communications pour
répondre aux caractéristiques des nouvelles versions de SICstus Prolog. Dans ce qui suit,
nous allons décrire les différents agents tels qu’ils ont été définis lors des premières études.
Nous décrirons aussi le format des agents, et leur répartition sur un système informatique
générique.
6.2 Le réseau de bibliothèques virtuelles

6.2.1 Notre application : un réseau de bibliothèques virtuelles
Pour illustrer notre méthode de conception et ses caractéristiques, nous allons pré-
senter une application que nous avons appelé “réseau de bibliothèques virtuelles”. Cette
application est en fait l’association d’un ensemble de bibliothèques électroniques partiel-
lement coopératives. Les abonnés de chacune d’elles peuvent envoyer des requêtes sur les
sites informatiques de la bibliothèque à laquelle ils sont abonnés. Ils peuvent effectuer
des recherches (par catégories, auteurs, titres, sujets, mots clés . . . ) et emprunter des
livres virtuels. Le système informatique de la bibliothèque tente de leur fournir le meilleur
service possible et donc de répondre le plus vite possible. Chaque bibliothèque doit réfé-
rencer autant de livres que possibles de façon à ce que si elle ne peut donner satisfaction,
elle puisse au moins orienter l’abonné vers une bibliothèque plus apte à répondre à ses
demandes.
Le but de chaque bibliothèque est de donner satisfaction à ses abonnés même si envoyer
111
Chapitre 6. Résultats obtenus
un abonné vers une autre bibliothèque entraîne le risque de voir ce client rompre son
abonnement pour s’inscrire à une bibliothèque plus performante.
Chaque bibliothèque doit remplir les fonctions suivantes :
– Elle doit gérer un catalogue de différents types de livres (il existe des fichiers “libres”
(c’est-à-dire gratuits et libres à la diffusion que les abonnés peuvent donc copier à
volonté) et des fichiers “qui s’appellent revient” et dont un nombre fixé de copies peut
exister à un instant donné). Pour cette seconde catégorie, les abonnés ne peuvent lire
le fichier, lequel est crypté, qu’en utilisant une interface fournie à cet effet pendant la
durée de l’emprunt. Après quoi le fichier doit être détruit de façon à ce qu’un autre
abonné puisse à son tour emprunter le livre virtuel. L’existence de ces fichiers à durée
de vie limitée complexifie grandement l’application. Il existe différentes technologies
qui permettent l’existence de ces fichiers avec une sécurité plus ou moins grande
(des fichiers Acrobats non reproductibles à durée de vie limitée aux cartes à puce).
Ces différentes solutions sont plus ou moins sûres mais elles rendent malgré tout la
copie des fichiers assez complexes pour que la plupart des clients ne la trouvent pas
rentable (la sécurité est semblable à celle des livres réels qui peuvent être copiés avec
une photocopieuse à condition d’avoir assez de temps et de papier). Cependant ces
problèmes de sécurité ne sont pas vraiment le sujet de notre travail donc la relative
sécurité de ces fichiers sera posée en hypothèse.
– Chaque bibliothèque doit pouvoir gérer des informations sur ses clients, de façon à
pouvoir identifier leurs requêtes, connaître leur situation (le nombre de livres qu’ils
ont empruntés, leurs retards de paiement d’abonnement . . . ) mais aussi de façon
à pouvoir permettre leur identification par les autres bibliothèques lorsqu’elle les
redirige vers ces dernières.
– Pour pouvoir diriger efficacement les clients vers les autres bibliothèques, il est
nécessaire que chaque bibliothèque indexe (au moins partiellement) le catalogue des
autres. Il faut de plus qu’elle juge de la capacité de chacune à donner de bons conseils
dans chacun des domaines spécialisés (littérature classique, scientifique, anticipation
...)
– Chaque bibliothèque doit, de plus, être dotée de fonctions “d’intelligence du bi-
bliothécaire” de façon à pouvoir répondre à des requêtes complexes du type : “je
cherche une aventure médiévale fantastique en un seul volume et je n’aime pas les
auteurs suivants . . . ”. Pour réussir cela, elles peuvent se baser sur les opinions de
leurs abonnés ayant déjà emprunté le volume, sur les critiques littéraires . . .
– Enfin, elle doit permettre les interactions entre ses abonnées de façon à ce qu’ils
puissent se transmettre des informations, des avis, des critiques . . .
6.2.2 Conception de cette application

Lorsque les hypothèses qui servent de base à cette application ont été correctement
formalisées, que le rôle de chacun des protagonistes, que ce soit les bibliothèques ou
les abonnés, ainsi que les interactions entre ces protagonistes ; il devient nécessaire de
représenter formellement les tâches de chacun de ces acteurs. Dans ce but, nous utilisons
des Réseaux de Petri Récursifs. Ces réseaux sont raffinés de façon récursive jusqu’à ce que
la granularité obtenue réponde aux attentes des commanditaires.
112
6.2. Le réseau de bibliothèques virtuelles
Nous montrons, par exemple, l’un des réseaux de Petri obtenus lors de la phase de
décomposition. Les tâches ont ensuite été partagées entre les agents en fonction de la
décomposition (figure 6.1) mais aussi de l’analyse client. En effet, comme plusieurs pro-
tagonistes coopèrent dans cette application, il était nécessaire de prendre tout en compte
dans le système.
Requête client
Demande de
conseil Recherche dans l’index
Trouvé
Non Oui
Procédure
d’emprunt
Envoi
Procédure de
conseil
Réponse Livre(s) Nouvelle requête

envoyés
Sélection
Autre
locale
sélection
début
Choix du
client
gestion conseil
Procédure
Envoi d’une requête
d’emprunt
Envoi
Livre(s) fin
Fin
envoyés
New request
Fig. 6.1 – Représentation du processus de recherche et d’emprunt d’un ouvrage et de la

gestion de la bibliothèque dans son ensemble
Nous nous sommes concentrés sur les tâches incombant aux bibliothèques.
Elles se séparent en deux catégories largement parallèles, le conseil et la gestion. Le
conseil pouvant lui-même être parallèle sous certaines conditions. En effet, ces processus
utilisent a priori les mêmes données (caractéristiques objectives des ouvrages, mais aussi
critiques, avis etc.) et le même code. Il faut donc partager les informations pour minimiser
le poids de la redondance. Pour cela, la seule solution satisfaisante était de créer des
113
agents bibliothécaires conseils spécialisés. Cela présente des avantages annexes : il devient
impossible qu’un bibliothécaire conseille fortement un livre qui n’est plus en rayon car un
autre bibliothécaire l’a déjà fortement conseillé à un client. En ayant un seul conseiller,
on peut construire une stratégie cohérente de conseil qui permette d’éviter que certains
ouvrages soient très largement conseillés tout en étant perpétuellement inaccessibles.
Il nous est donc apparu que les processus de conseil étaient réellement parallèles aussi
longtemps qu’ils ne concernent pas les mêmes livres. Nous avons décidé de suivre une
classification classique de façon à ce que les différences entre les conseillers soient simples
à assimiler par les clients. Nous avons donc réparti les connaissances sur les ouvrages et les
processus de conseil selon des catégories standards (il y a une section et un conseiller en
littérature française du XIX eme siècle, la même chose pour l’anticipation, l’informatique
. . . ).
Les processus de décision et de sélection d’ouvrages dépendent des abonnés et doivent
pouvoir être envoyés sur une autre bibliothèque si les utilisateurs sont redirigés vers cette
dernière pour pouvoir répondre à une requête. Il est donc raisonnable de placer ces proces-
sus dans un agent mobile qui “naît” sur l’ordinateur de l’abonné puis migre de bibliothèque
en bibliothèque avant de revenir avec les ouvrages recherchés. Ces agents seront des en-
tités standard divergeant uniquement par leur contenu “intelligent” destiné à la prise de
décision (comment choisir un ouvrage, emprunter ou seulement proposer une solution à
l’abonné etc.).
Ils peuvent donc permettre d’intégrer la sécurité des fichiers à durée de vie limitée en
servant d’interface de lecture.
Notre architecture s’articule finalement autour de trois types d’agents :
– Les Libraires Généraux qui gèrent le catalogue et les fichiers clients de la bi-
bliothèque car les deux sont liés par les procédures d’emprunt. Ils gèrent aussi les
commandes de la bibliothèque qui sont difficilement séparables du catalogue.
– Les libraires spécialistes dits Libraires de Section qui gèrent une section de la
bibliothèque (ce sont eux par exemple qui proposent l’achat de nouveaux ouvrages
à leur section de la bibliothèque ou le retrait d’ouvrages peu appréciés). Ils doivent
aussi conseiller les clients dans la limite de leur domaine et les diriger vers un autre
domaine en cas d’erreur d’orientation. Enfin ils doivent indexer la partie du catalogue
des autres bibliothèques qui est lié à leur spécialité et évaluer la capacité de conseil
de ces dernières dans leur domaine de façon à pouvoir rediriger les clients aux cas
où ils ne puissent donner satisfaction à ces derniers.
– Les agents Clients, qui migrent vers les différentes bibliothèques, empruntent et
“rendent” les ouvrages (en prouvant que les copies ont été détruites). Ils doivent
aussi demander des conseils aux Libraires de sections et échanger des informations
(essentiellement des critiques d’ouvrages ou de services de chaque bibliothèque) avec
les autres abonnés. Ils doivent posséder des informations sur les livres (comme par
exemple, l’opinion des abonnés qu’ils représentent ou celles des différents libraires
de sections rencontrés au cours de leurs migrations). Ces informations sont en effet
cruciales dans le choix d’ouvrages à emprunter.
Lorsque ces agents on été délimités, il était nécessaire de les implanter de façon à
tester l’efficacité du système conçu. Pour construire ce prototype, nous avons utilisé le
langage CLAIM et la plateforme distribuée SyMPA [FSS03b, FSS03a, SFS03, KSFS04]
114
dont l’architecture est présentée dans la figure 6.2.
Fig. 6.2 – Architecture de la plateforme SyMPA
6.2.3 L’architecture CLAIM de notre application

Les différentes classes d’agents ont été développées en utilisant CLAIM. Sur chacun
des ordinateurs participant à notre réseau, on trouve un agent SiteManager. Ce dernier
héberge soit des bibliothèques soit des sections de bibliothèque. Chaque Bibliothèque est
lancée sur un site distinct et reçoit un index contenant les livres présents dans cette
bibliothèque, chaque entrée de l’index contient les données suivantes :
– Auteur,
– Titre,
– Catégorie,
– Plusieurs mots clés,
– Disponibilité,
– Appréciation générale.
Les agents Libraires ont non seulement une connaissance complète de l’état de leur
bibliothèque mais aussi certaines connaissances sur la situation et le catalogue des autres
bibliothèques.
Chaque catégorie de livres est gérée par un bibliothécaire spécialisé (voir plus haut) que
l’on appelle Bibliothécaire de Section. Ce Bibliothécaire de Section héberge les agents des
abonnés. Il possède aussi des connaissances plus approfondies sur la qualité des ouvrages
de sa section mais aussi sur ceux des sections similaires d’autres bibliothèques.
115
Les agents Clients migrent depuis leur site d’origine (l’ordinateur de l’abonné vers
les bibliothèques auxquelles leur propriétaire est abonné pour y chercher des ouvrages en
suivant des requêtes multi-critères. Les agents Clients doivent commencer par s’inscrire,
après quoi, ils peuvent accéder à l’index de la bibliothèque. S’ils trouvent un ouvrage qui
satisfait les différents critères, ils empruntent le livre s’il est toujours disponible. S’ils en
trouvent plusieurs, et ne peuvent décider seuls lequel choisir, ils migrent vers la section
correspondante et demandent conseil au bibliothécaire de section ou aux autres clients
présents dans cette section. S’ils ne trouvent aucun livre correspondant à leurs critères, ils
demandent au bibliothécaire de section s’il a connaissance de bibliothèques qui pourraient
répondre à ses attentes.
L’un des aspects les plus intéressants de la distribution dynamique des sections sur
le réseau au cours de l’exécution se rapporte aux questions de distribution de charges :
lorsque l’une des sections est surchargée de clients, les autres sections avec lesquelles
elle partage son site peuvent migrer. Ainsi le site se décharge vers d’autres sites moins
encombrés ce qui accélère non seulement la section restée sur le site surchargé mais aussi
les autres sections qui se sont déplacées. On représente, figure 6.3, la migration de deux
sections de la bibliothèque avec leurs clients causée par une surcharge du système lors de
l’arrivée d’un nouveau client.
Une version simplifiée de notre architecture a été déployée en utilisant SyMPA que
nous présentons rapidement ultérieurement.
6.2.4 Les tests et les résultats obtenus

Pour pouvoir valider notre architecture, nous l’avons testée en comparant son efficacité
à celles d’autres architectures plus simples devant des vagues de clients. Ces vagues se
caractérisent par une surabondance de certains types de demandes sur un certain intervalle
de temps, après quoi les tendances s’inversent. Il y a donc toujours des sections “favorisées”
mais ce ne sont pas toujours les mêmes. Cette hypothèse nous a semblé valide parce
que, selon l’heure de connexion, la population d’abonnés présents n’aura pas les mêmes
caractéristiques (âge, profession, recherche professionnelle ou personnelle . . . ) il parait
donc logique de présumer que l’orientation des requêtes divergera.
Pour prouver l’efficacité de la redistribution dynamique des sections entre les sites
accessibles, nous avons réalisé trois types de tests. Dans le premier scénario, il y a une
bibliothèque seule composée de quatre sections correspondant aux catégories des critères
de recherche toutes placées sur le même site. Dans ce cas, les agents clients se dirigent
vers la section qui correspond aux catégories précisées dans leurs critères de choix. Dans le
second scénario, nous avons ajouté un ordinateur, sur lesquels nous plaçons automatique-
ment deux sections. Une fois cette distribution réalisée, le système est statique. Dans ce
cas les agents s’exécutent sur le site hébergeant la section correspondant à leurs critères.
Enfin, dans le troisième scénario, nous autorisons la migration des sections. Nos résultats
montrent que les sections préférées sont surchargées, ce qui entraîne un ralentissement
ferme du site qui les héberge. Comme nous le montrons dans la figure 6.4, (sur laquelle
sont comparés les temps d’attente des clients faisant une recherche dans la première sec-
tion, pour nos trois séries de tests), les meilleurs résultats sont obtenus lorsque la mobilité
est autorisée car les sections surchargées peuvent donc s’exécuter seules ou couplées à
116
INDEX
Manager de site
Bibliothécaire
Bibliothécaire de
section
Client
Fig. 6.3 – Architecture d’une bibliothèque distribuée
une section quasiment vide. Cependant, la validité des résultats dépend de la longueur
des périodes de population et bien sûr du nombre d’agents clients lancés sur la biblio-
thèque. La figure 6.5 qui présente les temps d’attente moyens dans les différentes sections
montrent que la redistribution des sections réduit le temps d’attente pour tous les agents
quelle que soit la section qui les concerne. Nous devons noter que les délais introduits
par la plateforme lors des phases de migration sont assez importants de façon à pouvoir
observer le comportement des agents. Les caractéristiques de la plateforme introduisent
aussi des délais de l’ordre de 30 secondes pour la migration d’une section.
117
Résultats des agents de la première section
180
160
Te m ps d'a tte nte -
1 ordinateur - 4
sections
140
2 ordinateurs, 2
120 sections statiques
2 ordinateurs - 4
100 sections dynamiques
80
60
C1S1 C2S1 C3S1 C4S1 C5S1 C6S1
Agents
Fig. 6.4 – Temps d’attente des agents dans la première section de la bibliothèque en
fonction de l’architecture (différentes courbes) et du nombre d’agents présents
6.2.5 Conclusion et perspectives

Nous avons montré qu’une application adaptive et distribuée dans un milieu assez ou-
vert (du fait de l’existence des clients) basée sur des agents mobiles peut être très efficace
à condition que la distribution des agents ait été prise en compte dès la phase de concep-
tion et non lors du prototypage. Notre réseau de bibliothèques virtuelles est un exemple
d’organisation coopérant sur Internet. Nous utilisons des agents mobiles pour permettre
la coopération (par transfert de clients d’un site à l’autre pour répondre à leurs attentes).
Nous tentons, maintenant, d’étendre ce type de coopération vers d’autres applications
(comme la conception d’entreprises virtuelles dont notre réseau est un exemple simple).
Pour pouvoir étendre notre méthodologie de façon à pouvoir l’adapter à ces nouveaux
défis, nous espérons réussir à la croiser avec notre solution de partage de ressources.
118
Satisfaction des agents
150
T e m p s d 'a tte n te -
140
130
Agents Section 1
120
Agents Section 2
110
Agents Section 3
100
Agents Section 4
90
80
1 2 3
Categorie du test
Fig. 6.5 – Temps d’attente dans les différentes sections selon le type de test réalisé
119
120
Quatrième partie
Notre système de partage de ressources
121
Chapitre 1
Introduction
1.1 De ASMAA vers un outil de partage de ressources

informatiques
Dans la partie suivante, nous décrivons notre outil de partage de ressources.
Au terme de la construction d’ASMAA, il nous est apparu que l’un des intérêts d’un
système partagé est qu’il peut être distribué sur un grand système. Cependant, les clus-
ters et les superordinateurs ne sont pas à la portée de tous les utilisateurs. C’est pour
cette raison que nous avons envisagé de modifier l’architecture d’ASMAA pour pouvoir
permettre le partage de ressources distribuées entre plusieurs utilisateurs (des utilisateurs
qui partagent leurs ressources ont d’une certaine façon accès au “cluster” composé de tous
leurs ordinateurs).
Cependant la structure hiérarchique de ASMAA pose quelques problèmes : en effet, la
hiérarchie dépend des machines du système distribué mais aussi de l’application (puisque
la répartition tente de prendre en compte les besoins spécifiques à chaque agent), elle
est aussi très sensibles aux entrées et aux sorties de sites (c’est l’une des raisons pour
lesquelles les systèmes peer-to-peer ne sont généralement pas hiérarchiques). En fait, il
nous est apparu qu’il faudrait, si l’on voulait utiliser ASMAA dans le cadre d’un partage de
ressources entre de multiples utilisateurs, avoir une hiérarchie par application, c’est-à-dire
par utilisateur. Cela nous paraissant extrêmement lourd et inefficace, nous avons décidé
de construire un outil de partage de ressources génériques (essentiellement de la puissance
de calcul). Cet outil pourrait servir pour permettre l’utilisation de SMA distribués sur
un “cluster” constitué d’ordinateurs partagés semblable à un système peeer-to-peer plutôt
qu’à une grille de calcul.
Dès lors, nous avons cherché comment faire coexister plusieurs SMA distribués sur
une plateforme peer-to-peer. Pour cela nous avons été obligés de concevoir une nouvelle
architecture sans la hiérarchie caractéristique d’ASMAA. Pour que l”architecture décrite
plus loin puisse servir à distribuer un SMA construit suivant ASMAA, il faut distribuer
les agents Managers d’agence comme les autres agents et leur permettre ensuite de gérer
leur “système dédié virtuel” comme un cluster construit sur une grille. Il faut donc noter
que dans ce qui suit, les Managers ne sont pas des managers d’agence mais des managers
de site (puisqu’il n’y a plus de hiérarchie, les sites sont tous égaux).
123
Il faut aussi noter que l’architecture et l’outil présenté ne sont pas des outils de grid-
computing mais des outils de partage de ressources qui peuvent permettre de déployer une
grille (ou simplement des tâches isolées) sur un ensemble d’ordinateurs partagés par leurs
utilisateurs, ASMAA n’étant, d’une certaine façon qu’une architecture de grille parmi
d’autres. Cependant, puisque ce système a été conçu dans le but de permettre la distribu-
tion d’outils basés sur ASMAA sur un parc d’ordinateurs partagés, on peut le considérer
comme une évolution d’ASMAA pour la gestion de systèmes partagés.
1.2 Un outil de partage de ressources informatiques

Comme nous l’avons dit précédemment, l’un des principaux avantages des agents est
qu’ils sont facilement encapsulables et donc adaptés aux besoins de la distribution sur
un système multiprocesseurs. Les agents étant autonomes, ils peuvent de plus continuer
à fonctionner dans un système ouvert et donc très dynamique. L’un des problèmes des
systèmes utilisant des composants mobiles est qu’il doit être possible à deux processus
mobiles de communiquer malgré leurs déplacements. Ces problèmes ont été amplement
traités (même si les solutions considérées ne sont pas toujours adaptées à notre problème).
Il nous est donc apparu logique d’utiliser des agents mobiles pour gérer des systèmes dyna-
miques. Serge Fenet, dans sa thèse [Fen01], a proposé un modèle de gestion d’application
distribuée sur un système multiprocesseur ouvert. Nous nous intéressons ici à la gestion
du système lui-même. En effet, un système ouvert basé sur le partage des ressources infor-
matiques de différents utilisateurs est difficilement gérable de façon centralisée et ce pour
plusieurs raisons :
– La raison la plus importante est le coût en communication et en puissance machine
pour les serveurs. Si nous prenons pour exemple Morpheus, le programme de partage
de données basé sur Gnutella a déjà été téléchargé par 110 millions d’utilisateurs
(01/11/02), certes on compte là des installations multiples et d’autres problèmes
mais le nombre d’utilisateurs connectés est malgré tout très important. Bien sûr, ce
problème se pose en un moindre terme dans le cas d’une entreprise internationale
voulant optimiser son parc informatique. Cependant, même dans ce cas un service
centralisé risquerait d’être surchargé surtout au niveau des communications. Un
serveur central devrait vérifier régulièrement le bon fonctionnement de toutes les
machines partagées, ce qui peut malgré tout être très coûteux.
– La deuxième raison est que les communications au sein d’un système distribué de
cette nature peuvent être rédhibitoires. Or chaque utilisateur ne désire sans doute
pas expliquer au serveur centralisateur ce que font ses processus et les besoins qu’ils
auront de communiquer entre eux. Les agents sont autonomes par nature, il se-
rait donc logique qu’ils se placent eux-mêmes en fonction de leurs besoins et des
communications qu’ils peuvent avoir entre eux.
– La troisième raison est un problème évident de sécurité : comment un serveur cen-
tralisé peut-il connaître les besoins d’une tâche ? La solution la plus simple serait
que chaque hôte puisse juger la pile d’instructions spécifique à chaque agent : cette
solution interdirait aux agents quelque confidentialité que ce soit. Or même au sein
d’une unique société, les informations sont compartimentées. Le système ne pour-
124
1.2. Un outil de partage de ressources informatiques
rait donc servir qu’à des travaux d’importance minime, mais dans ce cas, il n’a plus
vraiment de raison d’être. Les tâches doivent donc être capables de choisir de migrer
ou non en fonction de leurs connaissances de leurs propres besoins.
– La quatrième raison est aussi basée sur un problème de sécurité : le serveur central
(ou les serveurs intermédiaires selon le modèle de construction du système) devrait
être accessible de toutes les machines hôtes pour permettre le transfert d’informa-
tions entre les hôtes et le distributeur de charges. Or le serveur est une ressource
vitale car il est le centre du système, toutes les migrations nécessitant son interven-
tion. Il est donc à la fois une cible évidente pour toute agression contre le système et
une victime naturelle difficile à défendre car ouverte aux quatre vents. Pour éviter
l’apparition d’une telle faille de sécurité, il était impossible d’utiliser un système
même partiellement centralisé.
Nous avons donc décidé de tenter de construire une architecture entièrement distribuée
constituée uniquement d’utilisateurs. Une solution de ce type présente des limites. La
première d’entre elles est qu’il est pratiquement impossible que tous les hôtes du réseau
aient des informations à jour sur les autres hôtes du réseau, car cela entraînerait une
saturation complète du réseau. En fait, le simple fait que chaque hôte puisse conserver
des informations sur tous les autres, même si elles ne sont pas à jour risque de surcharger
le système inutilement. En effet, le nombre d’hôte potentiel n’est pas limité. De plus ces
informations seraient pour la plupart inutiles car les ordinateurs concernés ne sont pas
toujours connectés au système de partage.
Cette solution présente de plus une limite importante d’utilisation, l’utilisation d’agents
mobile et l’absence de serveurs entraîne la distribution du poids du système sur tous les
hôtes. Donc si ces derniers sont très chargés, l’utilisation du système n’aura comme seul
effet que de les surcharger encore plus sans rapporter le moindre gain. Ce système ne
devrait donc être utilisé que dans le cas où les ressources ne sont pas déjà saturées.
Il faut donc accepter que les connaissances de chaque processeur seront partielles et
datées car il sera très difficile de les remettre à jour en temps réel. A partir de ces limites,
nous avons décidé de concevoir le système que nous allons décrire dans ce qui suit.
Nous avons fixé plusieurs hypothèses sur notre travail [KSFS04], nous allons les rap-
peler ici.
– Le système multiprocesseur considéré est distribué (soit sur Internet soit au moins
sur un réseau fermé mais important, à la fois en nombre de machine et en surface
réelle (le but de notre système est de permettre l’utilisation de machines en dehors
de leurs horaires normaux).
– Le système informatique considéré est ouvert, les hôtes peuvent se connecter et se
déconnecter au système de partage.
– Le système doit pouvoir être hétérogène : les ordinateurs connectés peuvent être de
type différent (processeurs, OS . . . ).
– Le système n’utilise pas de serveur centralisé (pour les raisons citées précédemment),
chaque hôte a une connaissance partielle du système et les processus migrent sur le
réseau en fonction des connaissances de leur hôte d’accueil.
– Nous ne tenterons pas de garantir la connexité du système partagé (nous proposons
des solutions pour l’obtenir) car ce n’est pas une nécessité dans notre cas. Nous ne
pouvons que garantir l’effort maximal pour obtenir un système suffisant aux besoins
125
des différents utilisateurs.

– Nous voulons que les utilisateurs puissent partager des ressources matérielles, mais
il serait intéressant qu’ils puissent aussi partager des ressources logicielles ou des
données, dans une certaine mesure. Un exemple : un utilisateur pourrait rédiger un
texte dans un éditeur de texte, donner les caractéristiques de la mise en page qu’il
désire puis transférer le fichier à un hôte ayant un Ms Word partagé. La mise en
page serait réalisée sur cette machine qui générerait un fichier Word ou Acrobat et
le renverrait à l’auteur.
– La connaissance de chaque machine sur les autres doit être minimale et on doit
garantir l’intégrité des processus ainsi que des machines (au moins pour éviter qu’un
processus migrant puisse devenir le vecteur (involontaire ou non) de propagation de
code hostile.
126
Chapitre 2
Quelle clientèle pour un système de

partage
2.1 Les communautés d’utilisateurs

Comme nous l’avons rappelé précédemment, la plupart des ordinateurs sont sous-
utilisés à chaque instant et pourtant, les ordinateurs de tous les utilisateurs sont réguliè-
rement surchargés. Cette considération est valable pour tous les types d’utilisateurs. Nous
proposons donc une solution de partage de ressources entre utilisateurs au sein d’une com-
munauté : les utilisateurs ayant besoin de ressources informatiques pourront utiliser celles
qui sont sous-utilisées par d’autres membres de la communauté.
Ces communautés peuvent être de plusieurs types. Le plus évident est l’ensemble des
employés d’une société. Dans ce cas, le parc informatique considéré est l’ensemble des
ordinateurs de la société reliés à Internet ou à l’intranet du groupe. Cependant, d’autres
types de communautés sont tout aussi envisageables : des communautés de joueurs de
jeux vidéos (par exemple des groupes de joueurs de Neverwinter Night désirant rendre
permanent leur univers de jeu) ou des communautés dont les membres seraient des abonnés
payant . . .
Il est absolument nécessaire qu’il y ait un certain niveau de confiance de chaque utili-
sateur envers tous les autres. En effet, le partage de ressources impliquant l’exécution de
code étranger sur son ordinateur, les risques d’une utilisation malveillante (comme la pro-
pagation de virus informatiques ou l’utilisation des ordinateurs partagés pour commettre
des crimes informatiques) sont très importants. Une communauté relativement homogène
d’utilisateurs dont les membres seraient forcés de s’inscrire auprès d’un service central et
de donner un certain nombre d’informations personnelles permettant de les poursuivre
en cas d’infraction à la charte d’utilisation apporte une plus grande sécurité d’utilisation
qu’un groupe auquel on peut adhérer simplement en téléchargeant la plateforme sur In-
ternet. Les systèmes de partage de données (comme ceux cités dans la première partie de
ce document) se basent sur des communautés de la seconde catégorie mais le partage de
fichiers est beaucoup moins risqué que l’exécution de processus distants.
Pour conclure, théoriquement, n’importe quel ensemble d’utilisateurs d’ordinateurs
reliés par un réseau quelconque est éligible comme communauté de partage de ressources
127
Chapitre 2. Quelle clientèle pour un système de partage
informatiques, cependant, nous considérons qu’il n’est ni réaliste ni souhaitable de ne pas

restreindre cette définition de la communauté de façon à réduire les risques pour chaque
utilisateurs. Il faut de plus noter que beaucoup de gens répondront “je ne prête pas mon
ordinateur à n’importe qui, je ne laisse donc pas non plus n’importe qui exécuter n’importe
quel code dessus !”. On doit donc considérer que la définition de communauté doit être
réduite de façon à permettre le partage dans des conditions acceptables de sécurité. Il
n’est pas nécessaire que chaque membre de la communauté connaisse personnellement
chacun des autres, il est néanmoins souhaitable qu’il ait un moyen de découvrir l’identité
d’un membre particulier (par exemple en cas de dégradations faites par une tâche sur son
ordinateur).
Les communautés informatiques ont été décrites dans la première partie.
Cependant, nous utiliserons la définition ci-dessous comme hypothèse de notre travail.
Cette définition est une restriction utilitaire de la définition classique ci-dessus, elle ne
remplace cette dernière que dans le cadre de la construction d’un outil de partage de
ressources.
Définition : Une communauté d’utilisateurs est un ensemble d’utilisateurs qui peuvent
se faire suffisamment confiance pour pouvoir partager leurs ressources informatiques, du
fait, soit de leurs intérêts convergents, soit à cause de l’existence d’un moyen de coerci-
tion détenu par une tierce entité (qui peut être la direction dans le cas d’une société, un
organisme de contrôle pouvant ou non être une émanation de la communauté elle-même,
etc.).
Il faut noter que cette définition n’exclut nullement la possibilité que l’un des membres
cause des problèmes (volontairement ou non), elle implique seulement que les membres
de la communauté peuvent a priori se faire confiance. Il faut donc construire des outils
pour garantir la sécurité des membres. Il faut seulement comprendre qu’en dehors de cette
définition, les risques seraient tels que le système n’est absolument pas viable.
2.2 Les différents types de communautés et leurs spé-

cificités
Les différentes sous catégories de communautés d’utilisateurs n’ont pas toutes les
mêmes caractéristiques. Certaines d’entre elles garantissent une meilleure sécurité des
utilisateurs du système de partage, d’autres au contraire sont très lâches. Le niveau de sé-
curité qu’offre la communauté influe sur le niveau de sécurité que doit offrir la plateforme.
Ainsi, supposons que la communauté soit constituée des utilisateurs des ordinateurs d’une
société, il est sans doute beaucoup moins probable que certains membres s’attaquent à
d’autres, car les communications réseaux des utilisateurs sont sans doute surveillées et
que la sanction peut être très sévère. A contrario, une communauté d’utilisateurs privés
ayant un intérêt commun peut exiger que la plateforme soit beaucoup plus protégée. Il
faut aussi noter que les tâches distribuées peuvent différer grandement selon la commu-
nauté d’utilisateurs : ainsi, au sein d’une société, n’importe quel programme utilisé par
un employé dans le cadre de son travail peut potentiellement devenir une tâche distante,
alors que si la communauté est liée par un intérêt commun, les tâches partagées seront
128
2.2. Les différents types de communautés et leurs spécificités
nécessairement liées à cet intérêt.

Nous allons maintenant tenter de décrire les hypothèses de fonctionnement de certaines
communautés d’utilisateurs. Cette liste des types de communautés n’est certainement pas
exhaustive, mais elle peut donner une idée des utilisations potentielles de notre travail.
2.2.1 Utilisation au sein d’une société

– Hypothèses de fonctionnement
Ne peuvent se connecter au réseau de partage que les utilisateurs connectés au
réseau (intranet ou extranet) de la société. Les tâches distantes peuvent recevoir
une priorité en fonction de leur importance pour la société dans son ensemble.
– Sécurité
La sécurité est bonne, les risques d’attaque interne sont très faibles et les risques
d’attaques externes sont également faibles puisque pour utiliser l’application de
partage de ressources, il faut se connecter au réseau de la société. Le réseau est
assez sûr puisqu’il est physiquement restreint, les risques de coupures du réseau sont
limités et géographiquement prévisibles (connexions entre les différents intranets
locaux).
– Utilisation
Dans cet exemple, tous les utilisateurs peuvent lancer des tâches, cependant ils
ne sont pas égaux, certains utilisateurs peuvent avoir une plus grande priorité en
fonction de leur importance pour la société et ainsi voir leurs tâches recevoir un
meilleur service que celles des autres utilisateurs.
Il n’y a pas de contrôle des tâches qui peuvent donc être de tous les types et peuvent
être directement en langage machine. Les tâches peuvent communiquer entre elles et
peuvent créer de nouvelles tâches. Les tâches sont en général des calculs complexes
ou d’autres activités lourdes et limités dans le temps mais il est envisageable de
gérer de cette façon une base de données répartie.
2.2.2 Utilisation au sein d’une communauté d’abonnés

Les abonnés se connectent au service de partage par l’intermédiaire d’Internet. Les
abonnés sont tous identifiés parfaitement, paient un abonnement à une institution
qui gère le système (et qui peut être un fournisseur de services ou une association
d’utilisateurs) et utilisent la puissance de calcul partagée pour satisfaire leurs inté-
rêts propres. Les membres peuvent être des particuliers ou des groupes d’individus
(des PME par exemple). On peut penser que la facture mensuelle est inversement
proportionnelle au rapport de la puissance utilisée sur la puissance partagée. Dans
la formule suivante, ce sont les propriétaires des sites qui sont partagés, on peut
envisager d’autres solutions qui permettraient de suivre un utilisateur mobile.
P
j∈I\{i} Pi/j
Mensualitéi = K P
j∈I\{i} Pj/i
129
Avec K une constante réelle positive,

Pk/n est la puissance consommée par tous les agents originaires de l’utilisateur k sur
le nième site.
Mensualitéi représente la facture du ième client du système.
Dans cet exemple, les utilisateurs sont tous égaux, cependant on peut imaginer
un système ou seul certains utilisateurs pourraient lancer des tâches, les autres
utilisateurs seraient payés en fonction de la puissance qu’ils prêtent.
Pour un bon fonctionnement, il faut que les abonnés n’utilisent pas la puissance
partagée aux mêmes heures. On peut obtenir cela en sélectionnant différents types
d’abonnés, des utilisateurs privés et institutionnels (car ils n’ont pas les mêmes
horaires) ou en ayant une certaine répartition géographique (sur plusieurs fuseaux
horaires).
– Sécurité
La sécurité interne est bonne (en effet, le gestionnaire se réserve le droit de refuser
l’inscription de potentiels clients à risque). De plus, il peut facilement se retourner
contre les utilisateurs qui auraient commis des actes répréhensibles puisqu’il pos-
sède suffisamment d’informations sur chacun d’entre eux. Il faut noter que si les
inscriptions sont laxistes, le système de partage pour être utilisé dans des buts illé-
gaux (par exemple pour lancer des attaques groupées sur d’autres sites) puisque
les domaines d’utilisation sont très libres. Cependant, l’expérience des services pour
abonnés sur Internet a montré que les risques d’agressions extérieures sont assez
élevés. Cependant, comme le système de partage est lui-même complètement dis-
tribué, la cible privilégiée des attaques extérieures serait sans doute le serveur de
l’institution gérant les abonnements. Cela peut interdire la connexion des utilisa-
teurs mais sans doute pas l’utilisation par les membres déjà connectés. Le principal
risque est qu’une attaque du serveur des abonnements permette aux agresseurs de
récupérer les données sur les différents clients. Cependant, cette menace n’est pas
spécifiquement liée au service de partage mais à tous les services pour abonnés par
Internet.
– Utilisation
Comme nous l’avons montré, ici les utilisations sont diverses, cependant le principe
de facturation pousse les membres à utiliser le système pour réaliser des tâches de
courte durée, essentiellement pour pouvoir surmonter des périodes de surcharge.
Dans notre exemple, tous les utilisateurs sont égaux et peuvent lancer des tâches.
Pour minimiser les risques d’utilisation maligne, les tâches ne devraient pas pouvoir
communiquer à distance vers d’autres sites que leur site d’origine et les agents ne
devraient pas pouvoir se reproduire.
2.2.3 Utilisation au sein d’une communauté liée par un intérêt

scientifique
Il existe déjà des communautés partageant des ressources informatiques par intérêt
scientifique. La plus importante est SETI@HOME. Cette dernière peut, dans une
130
2.2. Les différents types de communautés et leurs spécificités
certaine mesure, nous servir de modèle. Les membres sont des particuliers ou des
équipes de recherche liés par un intérêt scientifique spécifique qui s’inscrivent lors-
qu’ils téléchargent la plateforme de partage. Ils utilisent Internet pour mettre en
commun des ressources informatiques. Il existe deux types d’utilisateurs, les cher-
cheurs du domaine sont des utilisateurs actifs, ils lancent des tâches distantes, alors
que les utilisateurs particuliers se bornent à prêter leur puissance de calcul.
– Sécurité
La sécurité au sein du groupe n’est pas garantie. En effet les membres sont sans
doutes recensés lors de leur téléchargement de la plateforme mais ils ne sont sé-
lectionnés que sur leur bonne fois (puisque la plupart d’entre eux sont seulement
prêteurs de puissance). La nature non commerciale de l’opération ne la met pas
à l’abri d’attaques informatiques spécifiques. Il est donc nécessaire de protéger les
sites de recherche. Cependant, la nature exclusive des tâches transférées diminue les
risques pour les utilisateurs.
– Utilisation
Les tâches distantes sont des calculs répartis lancés par certains utilisateurs spéci-
fiques (les chercheurs). Les processus perpétuels sont en général exclusivement réali-
sés par les ordinateurs de contrôle des senseurs. Les “expéditeurs” de tâches sont peu
nombreux et donc facilement identifiables. Les tâches peuvent communiquer entre
elles mais ne peuvent pas produire d’autres tâches. Si des calculs supplémentaires
sont nécessaires, elles doivent rapporter leurs résultats sur leur site d’origine qui
lancera les nouvelles tâches.
2.2.4 Utilisation au sein d’un groupe d’utilisateurs d’un jeu vidéo

multi joueurs
Ce cadre peut servir d’exemple à tout groupe d’utilisateurs liés par l’utilisation
d’une application distribuée et coûteuse. Ici, les utilisateurs sont des abonnés (ils
sont inscrits et relativement identifiables), bien que les inscriptions puissent être
moins sûres que celles du partage entre abonnés (voir plus haut). Le but de ce
partage est de permettre à l’application distribuée de tourner sans encombrer les
ordinateurs des utilisateurs. Les sites sont partagés en utilisant Internet et les utili-
sateurs peuvent être physiquement complètement répartis (comme c’est aujourd’hui
le cas des joueurs des jeux massivement multi joueurs.
– Sécurité
La sécurité est a priori faible puisque les utilisateurs peuvent être relativement mal
connus. Le système est accessible de partout. Les attaques internes devraient être
rares, cependant, dans le cas d’un jeu, elles sont envisageables (de la part d’un
joueur déçu ou alors dans l’intention de tricher). Les attaques extérieures sont aussi
probables bien que les sites de jeu en ligne aient été proportionnellement peu touchés
par les attaques jusqu’ici.
– Utilisation
Les tâches distribuées ne sont que d’un seul type, lié au jeu (essentiellement destinées
131
au maintient de l’univers du jeu). Ce sont des tâches perpétuelles et redondantes.

Elles peuvent normalement lancer d’autres tâches, bien que cela devrait être très
rare (essentiellement pour remplacer une autre tâche arrêtée). Les utilisateurs ne
peuvent normalement pas lancer de tâche (en dehors de quelques utilisateurs insti-
tutionnels officiellement désignés pour gérer le monde). Le principal intérêt , ici, est
que les tâches distribuées peuvent être redondantes et communicantes sans entraîner
l’encombrement caractéristique d’un serveur centralisé.
132
Chapitre 3
Dans cette section, nous allons décrire notre système de partage. Cela exige une des-
cription de l’architecture logicielle de notre application mais aussi du système informatique
qui lui est sous-jacent. Nous pourrons ainsi formaliser toutes les hypothèses de fonction-
nement de notre système dans son ensemble.
3.1 Description du système physique

3.1.1 Les ressources informatiques
Pour pouvoir décrire notre outil de partage, il est nécessaire de décrire au préalable,
les ressources à partager. Aucune hypothèse n’est faite sur les ressources informatiques
partagées, en dehors de celles qui servent de base aux descriptions des ordinateurs utilisées
par les différents agents constituant l’application. Cependant, comme nous le verrons dans
les sections suivantes, théoriquement, les variables utilisées pour décrire un ordinateur
peuvent avoir n’importe quelle forme du moment que l’on peut construire une fonction
qui leur attribue une note numérique. Lors nos simulations (et des tests réels des agents),
nous avons utilisés les variables suivantes :
– Système d’exploitation,
– Qualité de l’unité de calcul,
– Taille de la mémoire,
– Qualité des outils gestionnaires du son et de l’image,
– Qualité de la connexion au réseau,
– Type de la connexion réseau (statique ou dynamique) (voir la raison de cette dis-
tinction dans la section suivante),
– Occupation et prévisions d’occupation sur la période fixe (pour nous 24 heures par
plages d’une demi-heure).
Notre modélisation des ordinateurs comporte normalement d’autres informations comme
la présence du site décrit au cours des périodes passées, ces différentes informations, ainsi
que leur format seront décrites ultérieurement. Cependant, elles n’ont pas été prises en
compte lors des différentes simulations du système.
133
Chapitre 3. Description des ressources partagées
Il faut de plus ajouter que la description que nous avons utilisée impose quelques res-
trictions, par exemple, comme nous nous basons sur une estimation de la qualité de l’unité
de calcul, les ordinateurs multiprocesseurs ne peuvent pas être jugés correctement, cepen-
dant, il suffirait de construire une application test destinée à juger de la puissance de calcul
de l’ordinateur en prenant en compte les caractéristiques d’une machine multiprocesseur
(parallélisme . . . ).
Il faudrait cependant approfondir nettement le mode de représentation des sites pour
pouvoir prendre en compte les architectures basées sur des processeurs spécifiques (comme
les processeurs vectoriels). Cependant, il suffirait de plus donner une note générique à
l’unité de calcul mais plusieurs notes selon le type de calcul à effectuer. Spécifier les
caractéristiques de l’unité de calcul de cette façon nous est apparue superflue dans le
travail suivant puisque nous envisagions l’utilisation de notre application dans le cadre
d’un parc de micro ou de mini ordinateurs (PC, Mac, stations SUN . . . ).
3.1.2 Le réseau de communications
Notre système de partage de ressources est destiné à permettre le partage des res-
sources informatiques entre plusieurs utilisateurs connectés par un réseau. Nous ne fai-
sons pas d’hypothèses spécifiques sur la nature physique du réseau considéré, cependant,
l’application a été conçue pour être utilisée sur un réseau IP câblé.
Les caractéristiques des réseaux IP actuels (utilisant le protocole IP v4) compliquent
la construction d’une architecture distribuée dynamique. En effet, pour compenser la pe-
titesse du nombre d’adresses IP utilisable avec IP v4, les fournisseurs de service Internet
(aussi bien Wanadoo que la plupart des laboratoires de recherche) ont recours à l’uti-
lisation d’adresses dynamiques. Cela engendre une difficulté supplémentaire puisque ces
ordinateurs s’ils s’éteignent perdent leur adresse et sont donc très difficiles à retrouver.
Cette difficulté disparaît avec IP v6 car le nombre d’adresses IP v6 est suffisant pour que
tous les ordinateurs aient une adresse spécifique. Cependant, nous ne pouvons pas nous
baser sur les spécifications d’IP v6 puisque le protocole en est toujours à sa phase de test
et qu’on ne peut pas être sûr qu’il sera jamais massivement utilisé.
L’application peut être transposée sans difficultés réelles sur un réseau sans fils.
En effet, les bornes de connexion à distance n’étant fondamentalement différentes des
routeurs d’un réseau filière, la principale différence entre les deux architectures provient
plutôt de la capacité de mouvement des utilisateurs de réseaux sans fils, ce qui induit la
possibilité que les utilisateurs soient momentanément déconnectés du réseau. Cependant
cette possibilité s’apparente pour ce qui est des effets à des coupures de réseaux filières,
même si en général, les coupures de réseaux filières touchent une plus large échelle. Les
architectures dites “ad hoc” pourraient être traitées de la même façon que les architectures
sans fil basées sur des bornes, cependant il se peut que leurs spécificités entraînent des
simplifications des hypothèses à la base de notre système et qu’il soit dès lors plus rentable
d’utiliser le réseau de relations réseaux de chaque ordinateur plutôt que d’en construire
un nouveau, applicatif.
134
3.2. Description du système logiciel
Fig. 3.1 – Un exemple de “réseau câblé routé”
3.2 Description du système logiciel

Comme nous l’avons expliqué précédemment, on peut imaginer de multiples appli-
cations pour un système de partage de ressources informatiques entre des utilisateurs
distants et potentiellement concurrents. Chacune de ces applications entraîne des exi-
gences spécifiques en matière de sécurité, mais aussi de fonctionnement. C’est pour cette
raison que nous avons opté pour une architecture aussi modulaire que possible. Le système
de partage doit répondre à plusieurs exigences antagonistes, on doit assurer la sécurité
des utilisateurs, ainsi que leur confidentialité, ces deux exigences, simplement, posent déjà
de nombreux problèmes. Mais il faut en plus permettre l’exécution de tâches diverses et
potentiellement en interaction les unes avec les autres. Il faut que l’architecture permette
l’existence de tâches aussi bien “éternelles” que temporaires.
Nous voulions de plus que l’application puisse s’exécuter sur des configurations très
différentes. En effet, cela peut permettre de profiter de certaines configurations très spé-
cialisées ou au contraire de dépasser les limites de sa propre configuration. Dans ce but,
il nous est apparu qu’il était préférable que l’application puisse tourner sur la plus vaste
gamme d’ordinateurs, mais aussi de systèmes d’exploitation possibles. Dans ce but, nous
avons considéré qu’il était préférable que l’application tourne sur la Machine Virtuelle
135
Java (JVM) qui par sa très large distribution permettait l’exécution de la plateforme de
partage sur un vaste éventail de configurations tout en conservant certains des avantages
de ces dernières. Il nous est donc apparu que si les tâches peuvent être compilées pour un
type d’ordinateur (par exemple pour un PC sous Windows), la plateforme elle-même doit
pouvoir fonctionner sur toutes les configurations.
Il faut cependant se rappeler que notre but est de construire un outil qui permette de
partager des ressources, pas de construire un système distribué ou un substitut de grille
complet. Nous proposons une solution qui permette d’exécuter des tâches en les distribuant
sur un parc informatique sans avoir à utiliser de systèmes de “load-balancing” qui exigerait
pour fonctionner une certaine centralisation ainsi que des connaissances sur l’occupation
des sites qui non seulement sont assez incompatibles avec la confidentialité recherchée
mais supporte assez mal le passage à l’échelle ainsi que l’apparition et la disparition des
différents sites en fonction de l’utilisation qu’en a leur propriétaire.
Pour résumer, l’existence d’un système comme celui que nous voulons construire exige
que plusieurs fonctions très différentes soient remplies :
– Les tâches doivent pouvoir se déplacer d’un site à l’autre et s’exécuter sur le plus
grand nombre de sites possibles. Elles doivent de plus être protégées des agressions
et aussi anonymes que possible.
– Il faut minimiser la centralisation du système et donc éviter les serveurs ou les autres
formes de centralisation car ils représentent des failles de sécurité naturelles mais
aussi parce qu’ils rendent difficile le passage à l’échelle.
– Le système doit être maintenu, il faut conserver suffisamment d’informations sur les
différents sites pour que le système puisse fonctionner, mais il faut aussi prendre en
compte les sites présents et absents, permettre le déchargement des sites surchargés.
– La sécurité des utilisateurs doit être assurée . . . autant que faire se peut.
– Chaque utilisateur doit pouvoir avoir accès aux sites qui correspondent le mieux à
ses besoins.
Pour répondre à ces quatre exigences, nous avons imaginé une architecture à base
d’agents. En effet, ils présentent plusieurs intérêts évidents dans notre situation : en
premier lieu, ils permettent de gérer des intérêts plus ou moins conflictuels (chaque agent
tentant de répondre aux exigences de son propriétaire, la première desquelles est sans
doute sa propre sécurité, exigences qui ne sont pas nécessairement compatibles avec celles
des autres utilisateurs). En second lieu, ils offrent un très haut d’encapsulation, permettant
par exemple d’associer les tâches et l’outil qui les dirige vers un site adapté à leurs besoins,
ce qui permettrait de minimiser le besoin de centralisation. Enfin, l’utilisation d’agents
mobiles parcourant le réseau peuvent être un outil de propagation des remises-à-jour des
informations locales d’autant plus que si les mêmes agents transportent les processus et
répandent les informations, le poids pour le système dans son ensemble ne devrait pas
être important.
Nous avons donc conçu notre architecture autour de trois classes d’agents différents.
Une classe de d’agents Managers, une classe d’agents Sniffers et une classe d’agents Tasks.
Les trois types d’agents (dont nous décrirons les prérogatives plus loin dans cette section
et le contenu algorithmique dans la section suivante) se partagent les différentes fonctions
citées précédemment :
– Les agents Managers conservent les connaissances sur le système, chaque site est géré
136
3.3. Description des prérogatives des différents agents
par un Manager qui connaît son état mais possède aussi une base de connaissances
sur certains autres sites du système. Ils gèrent aussi la sécurité de leur site et les
intérêts du propriétaire du site.
– Les agents Sniffers se déplacent de site en site en remettant à jour les connaissances
des Managers sur les différents sites. Ils gèrent aussi les intérêts de leur utilisateur en
cherchant des sites correspondant aux besoins de ce dernier (ils ramènent ensuite ces
informations sur leur site d’origine). Ils proposent, de plus, aux Managers d’indexer
des sites correspondant à leurs exigences (ce qui rend ces derniers plus accessibles).
– Les agents Tasks transportent les tâches à réaliser de site en site. Ils vérifient si
le site sur lequel ils se trouvent propose un service suffisant pour la tâche qu’ils
transportent et si ce n’est pas le cas choisissent une bonne destination (à partir des
connaissances du Manager local et de leurs connaissances propres) et migrent vers
cette destination puis reprennent l’exécution de leur tâche.
3.3 Description des prérogatives des différents agents

3.3.1 Le Manager de machine
Le Manager de machine est un agent très particulier au sens où il est le seul agent
physiquement statique, il ne migre pas. Cet agent a pour but de gérer la plateforme sur
laquelle il s’exécute et d’assurer son bon fonctionnement. Ses rôles sont les suivants :
– Gestion des entrées et des sorties d’agents, il assure non seulement leur bonne mi-
gration mais peut aussi forcer un agent à migrer pour diverses raisons comme la
surcharge du système. Cependant, si le Manager n’est pas obligé de justifier son
acte, devrait être incité à le faire car sa façon de sélectionner les agents Tâches
autorisées sur son site peut être une information intéressante.
– Gestion du réseau d’accointances de la machine concernée, avec l’aide des Sniffers,
et des retours des agents ayant suivi ces liens. Il compte les agents ayant traversé ce
lien pour revenir aussitôt, et prend en compte les commentaires des usagers.
– Gestion des informations fournies par les Sniffers, il gère non seulement les pro-
positions de modifications de la base d’accointances originaires des agents Sniffers,
mais il assure aussi la confidentialité des messages des agents Sniffers vers les agents
Tâches de même origine, grâce à un système de cryptage. Pour vérifier la validité
du message, le Manager décrypte les messages reçus grâce à la clé que l’agent Tâche
lui donne, vérifie qu’il est syntaxiquement valable, puis s’il est valable, il l’envoie
à l’agent Tâche à la fois dans une version cryptée et dans une version décryptée
(pour que l’agent puisse valider la transcription du message). Après quoi il rend le
message public (c’est pour cette raison qu’il le décrypte lui-même).
– Gestion des droits et des accès des agents.
– Gestion des priorités valides sur la plateforme concernée (en effet, il peut y avoir
des priorités sans qu’elles soient universelles).
– Le Manager peut-être en mesure d’exiger des garanties ou des informations de la
part des agents qu’il abrite (but, estimation du temps de calcul, propriétaire . . . ).
– Doivent-ils pouvoir communiquer entre eux et se transmettre des infor-
137
mations (sur les mauvais payeurs ou les menteurs par exemple) ?

Le Manager d’agence a toujours le dernier mot quand il s’agit de refuser ou d’accepter
l’accès à son hôte à un agent, Sniffer ou Tâche. Cependant si un hôte refuse trop d’agents,
les hôtes de sa liste d’accointances devraient se mettre à refuser les agents originaires
de l’hôte trop difficile. Cela devrait suffire à pousser les utilisateurs à laisser un accès
raisonnable à leur ordinateur (ce qui est nécessaire à l’existence du système dans son
ensemble) puisqu’ils seront ainsi remboursés de leur tendance à partager par un accès
augmenté aux autres hôtes.
Il ne doit être possible aux agents que de communiquer par messages avec les agents
Managers. En effet, ils sont la cible la plus naturelle en cas de comportement malin de
certains agents Tâches.
En contrepartie, comme on ne peut pas garantir les bonnes intentions des Managers
envers les agents tournant sur la plateforme, il faut assurer que ces derniers n’abusent pas
de leurs différents pouvoirs. Il est de plus nécessaire de protéger le contenu des agents
Tâches d’un potentiel espionnage des Managers qui sont dans une position privilégiée
pour espionner les agents présents et tenter de découvrir leurs fonctions et attributs.
3.3.2 Les agents Tâches

Les agents Tâches transportent le code à exécuter jusqu’à une machine satisfaisante
puis migrent à nouveau dans le cas où leur hôte actuel ne serait plus en état de fournir
les ressources nécessaires (soit parce que les besoins de l’agent ont changé soit parce que
l’état de l’hôte a évolué et qu’il est maintenant inapte à fournir les ressources nécessaires
(changement de priorités, surcharge processeur . . . ).
Les agents Tâches ont plusieurs caractéristiques :
– Ils s’exécutent sur la machine virtuelle Java (cela leur permet de tourner sur n’im-
porte quel hôte).
– Ils doivent respecter toutes les limitations que leur impose le Manager.
– Ils sont autonomes dans leurs migrations (normalement, ils basent leurs choix sur
les connaissances locales, mais ce n’est pas obligatoire).
– Ils rapportent leur évaluation des hôtes connus par une machine s’ils
repassent sur elle.
– Cela permet de remettre certains liens à jour sans que la présence de Sniffers soit
nécessaire.
– Ils ne doivent pas communiquer directement avec les Sniffers (pour empêcher que
les Sniffers n’aient trop intérêt à nuire au système dans son ensemble).
– Ils sont accueillis par les hôtes après examen par les agents Managers des hôtes
concernés, ils doivent donc posséder certaines informations s’ils veulent pouvoir ac-
céder à certains hôtes exigeant certaines informations pour accueillir un agent.
– Ils possèdent la clé de décryptage qui leur permet de décrypter les messages que
leurs laissent les agents Sniffers. Ils peuvent être capables de décrypter les messages
laissés par les Sniffers, dans le cas où les Managers pourraient être considérés comme
malhonnêtes.
Les agents Tâches doivent normalement être autonomes, mais on peut imaginer un
agent dont la tâche soit de trouver une machine spécifique puis d’appeler un agent Tâche
138
important qui serait dès lors bloqué sur cet hôte jusqu’à ce qu’il ait complété la tâche qui
lui a été assignée.
Cependant, nous devons assurer la sécurité des agents Tâches, ils doivent donc être
libres et on doit garantir que leur code repart inchangé.
Les agents Tâches doivent être protégés des malveillances. Il faut éviter qu’ils puissent
être noués de messages ou corrompus. Pour commencer il ne faut pas que n’importe quel
agent puisse entrer en communication avec eux, surtout s’ils sont sur la même machine.
Pour empêcher cela, il est nécessaire de s’assurer que les canaux de communication des
agents Tâches sont privés. Pourtant, il est aussi nécessaire que le Manager de plateforme
puisse retrouver l’identité de l’utilisateur de chacun de ses ports de communication. Pour
cela nous devons permettre aux agents Managers d’avoir accès à cette information par
exemple au moment de l’attribution des ports de communication aux agents (si nous déci-
dons que les agents peuvent avoir leur module de communication particulier). Cependant,
cette information doit être utilisée le moins possible. Il est donc logique de doter chaque
agent Tâche d’un module de communication spécifique destiné à ses communications
avec l’agent Manager. Ce mode de communication doit être suffisamment sûr pour qu’il
ne puisse pas être usurpé par d’autres agents tournant sur la plateforme. On doit aussi
assurer que les agents tournant sur une machine ne peuvent pas avoir accès au contenu des
autres agents, même s’ils connaissent le code de ces derniers. Cette protection doit être
étendue au Manager de plateforme qui ne doit pas avoir non plus accès aux variables et
méthodes de l’agent. Ainsi, il n’est pas possible de laisser les Managers protéger l’intégrité
logicielle des agents car on ne peut pas garantir leur bonne volonté.
Etant donné que ces agents doivent transporter les tâches à réaliser jusqu’à une ma-
chine efficace, il faut que ces agents soient mobiles, qu’ils soient capables de vérifier si
l’hôte qui les accueille répond à leurs besoins et aussi de choisir une machine vers laquelle
migrer. Ils doivent donc avoir les modules suivants :
– Encapsulation de la tâche à réaliser,
– Mobilité,
– Choix de la destination en cas de mobilité,
– Evaluation de la satisfaction procurée par l’hôte actuel,
– Clé de décryptage pour pouvoir lire les messages laissés par les agents Sniffers avant
de les rendre publics,
– Adresse de l’hôte d’origine pour pouvoir retourner sur leur hôte d’origine, une fois
leur tâche réalisée,
– Ils peuvent aussi avoir un module de communication (au cas où celles-ci sont per-
mises).
Les agents Tâches sont à peine plus complexes que les agents Sniffers. Les seules
différences avec l’agent Sniffer sont qu’ils migrent toujours vers le meilleur hôte possible
et qu’ils prennent en compte les messages laissés par les agents Sniffers sur le tableau de
l’hôte. L’algorithme de migration des agents Tâches est donc le suivant :
1. Si l’agent a fini sa tâche, il retourne sur son hôte d’origine ou communique son
résultat à qui de droit.
2. Evaluation de l’hôte actuel (en récupérant les données de l’agent Manager en “temps
réel”), cette action est faite à heure fixe (par exemple, par une gestion d’événements).
139
a. Si l’agent est satisfait, il continue à travailler et reboucle sur cette étape

b. Sinon il passe à l’étape suivante
3. Récupération de potentiels messages laissés par les Sniffers associés sur cet hôte
4. Récupération de la liste des connaissances de l’hôte et comparaison à sa propre liste
de connaissances
5. Sélection des solutions acceptables parmi celles récupérées pendant les deux étapes
précédentes
6. (pour l’instant) Migration vers l’hôte sélectionné (peut-être après avoir laissé un
message donnant sa destination pour ses éventuels partenaires).
Il sera nécessaire de rajouter les communications entre les agents locaux, de façon à
ce qu’ils ne migrent pas tous vers la même cible.
3.3.3 Les agents Sniffers

La raison d’être des agents Sniffers est d’explorer le système. Ils ont deux buts diffé-
rents (et potentiellement antagonistes) : ils cherchent des hôtes potentiellement adaptés
aux besoins des agents Tâches originaires du même hôte qu’eux, dans le même temps, ils
cherchent à construire les réseaux de connaissances des hôtes qu’ils traversent. Les agents
Sniffers ne se bornent pas à identifier les liens déficients, ils proposent aussi de nouveaux
liens potentiellement pertinents (chaque Sniffer a ses propres critères pour évaluer la qua-
lité d’un lien potentiel). Ils doivent ensuite convaincre le Manager des hôtes concernés de
la pertinence des liens qu’ils proposent. Les Sniffers sont donc l’un des points “faibles” du
système, en effet, ils migrent énormément ce qui fait d’eux des cibles privilégiées d’une
attaque, mais ils peuvent aussi poser des problèmes en eux-mêmes car les intérêts de
leurs propriétaires peuvent être antagonistes avec ceux du système en général (ils pour-
raient tenter de décharger un hôte très efficace pour pouvoir en faire profiter ensuite les
agents Tâches auxquels ils sont associés). Nous devons empêcher les utilisations nuisibles
des agents Sniffers, c’est pour cette raison que le Manager de chaque hôte a toujours le
dernier mot quant à la connaissance des autres hôtes.
Comme nous l’avons dit, il faut minimiser les accès des Sniffers ce qui assurera non
seulement la sécurité des hôtes mais aussi celle des Sniffers eux-mêmes (entre autres parce
que le jeu n’en vaudrait plus la chandelle).
Cependant les Sniffers doivent avoir accès aux informations nécessaires à leur travail.
Les interactions entre la plateforme et les Sniffers se font par l’intermédiaire de l’agent
Manager. Les interactions entre ces deux agents se font par échange de messages. En
résumé :
– Les Sniffers explorent et “cartographient” le système.
– Ils remettent à jour les connaissances de chaque plateforme sur les plateformes aux-
quelles elle est reliée (par la base d’accointance de chaque plateforme) en fonction de
leurs connaissances et de leur propre évaluation de la validité de leurs connaissances
(ils utilisent l’horloge de la machine concernée pour cela).
– Ils proposent de modifier les entrées de la base d’accointance (comme remplacer
des accointances inefficaces par d’autres plus efficaces) à l’agent Manager des pla-
teformes concernées.
140
– Ils doivent avoir la possibilité de revenir sur une machine spécifique et de laisser
un rapport de leurs explorations (comme par exemple revenir sur leur machine
d’origine et déposer là une carte de leurs explorations). Il doit cependant aussi être
possible de créer des agents Sniffers qui ne connaissent pas leur expéditeur. Cela
peut devenir nécessaire si l’utilisateur a des raisons de penser que quelqu’un peut
avoir des intentions malveillantes à son égard.
En effet, la sécurité des Sniffers pourrait ne pas paraître être une priorité mais les
Sniffers d’un utilisateur connu peuvent être attaqués (ou manipulés) de façon à réali-
ser une forme de déni de service en empêchant les Sniffers de cet utilisateur d’atteindre
des machines efficaces soit en les bloquant soit en les envoyant sur de mauvaises pistes.
D’autres attaques plus graves sont aussi possibles. Il doit donc être possible pour certains
utilisateurs d’utiliser des agents Sniffers anonymes pour garantir la sécurité de leurs ap-
plications, même si cela se fait au détriment de certains des services que peuvent fournir
les Sniffers à leurs propriétaires.
Comme nous l’avons dit précédemment, les Sniffers ont trois buts différents mais
complémentaires. Ils doivent à la fois explorer le réseau à la recherche d’hôtes adaptés
aux tâches que l’utilisateur désire lancer et en même temps ils participent à l’évolution
de la structure du système dans son ensemble en proposant des modifications de la liste
de connaissances des machines du système en fonction de leurs exploration du réseau
(cela permet de mettre à jour les liens défectueux ou de remplacer une connaissance
par une autre plus pertinente). Leur dernière raison d’être est qu’ils transportent des
informations sur les hôtes qu’ils ont traversés et les ramènent à leur hôte d’origine, pour
que celui-ci puisse se construire une modélisation du système dans son ensemble (car
on peut penser que certaines caractéristiques du système sont très stables, comme la
vitesse des communications à certaines heures, la qualité des machines en fonction de leur
emplacement géographique etc.).
Pour remplir ces deux tâches, les agents ont besoin de plusieurs fonctionnalités diffé-
rentes. Ils doivent être :
– Complètement mobiles,
– Capables de conserver un modèle de chacun des hôtes traversés,
– Capables de retourner sur leur machine d’origine,
– Capables de choisir leur prochaine destination en fonction des connaissances de
l’hôte sur lequel ils se trouvent,
– Capables de crypter et décrypter certains messages qui leur seraient destinés (il
devraient pouvoir lire sur le tableau l’emplacement d’un agent ayant migré, mais
aussi être capables de laisser sur le tableau l’identité d’un machine pour qu’un agent
présent puisse savoir où migrer après avoir terminé son opération en cours),
– Enfin, ils doivent être capables de juger la machine sur laquelle ils se trouvent.
Les agents Sniffers sont très simples, dès lors leur fonctionnement est en fait une
séquence de des tâches décrites précédemment.
Quand l’un d’eux arrive sur un hôte, il juge toutes les machines connues par cet hôte
mais qu’il n’a pas encore visitées grâce à son module de préférences (lesquelles sont repré-
sentées par un treillis de Galois), puis il choisit au hasard une destination (la probabilité
pour une destination d’être choisie est fonction de son emplacement dans le treillis de pré-
férences). Ainsi les chances d’être choisies doivent augmenter en fonction de la qualité de
141
l’hôte considéré et on ne revisite pas toujours les mêmes machines (ainsi, on peut montrer
facilement que si tous les hôtes sont éternellement connectés, ils seront tous visités par
les Sniffers, car tous les hôtes ont une probabilité non nulle d’être visités par chacun des
Sniffers).
Cette sélection d’une destination est réalisée en six phases :
1. Si sa mémoire est pleine, il migre immédiatement vers son hôte d’origine
2. Récupérer la liste des connaissances auprès de l’agent Manager
3. Eliminer les hôtes connus
4. “Passer la liste au treillis”
5. Lancer la fonction de détermination au hasard d’une destination
6. Migrer vers le nouvel hôte
Quand un Sniffer arrive sur un nouvel hôte, il commence par récupérer auprès de
l’agent Manager les données caractéristiques de l’hôte, puis il compare aux hôtes précé-
demment connus et aux descriptions des hôtes de la liste de connaissance de cette machine.
Il propose des modifications, puis entame son processus de migration.
1. Lecture des caractéristiques de l’hôte
2. Comparaison entre les caractéristiques de l’hôte et des machines connues
3. Comparaison des résultats et des connaissances actuelles de l’hôte
4. Proposition de nouvelles connaissances
142
Chapitre 4
Problèmes posés par un système de

partage
4.1 Capacité d’un agent à juger de la qualité des ser-

vices
Il n’est pas facile pour un agent de juger la qualité des services qui lui sont proposés ni
de l’encombrement des machines qu’il utilise. C’est d’autant plus difficile que les agents
n’ont pas de connaissance globale de l’état du réseau. Il faut cependant trouver une
solution qui permet aux agents de décider s’ils sont satisfaits par les services auxquels
ils ont accès sur leur site d’adoption. Il faudra prendre en compte le fait que la qualité
des services et l’encombrement général des sites peut varier dans le temps. Certaines
exigences peuvent remplies à certains moments et ne pas l’être à d’autre (et ce même sur
l’ensemble du système). Il faut que les agents jugent les services qui leurs sont fournis dans
la longueur. En effet, si un ordinateur n’arrive pas à répondre aux exigences des agents
pendant un laps de temps très court, il ne faut pas pour autant que les agents décident
de migrer. Nous avons donc opté pour un système de vérifications cyclique. Les agents
vérifient régulièrement si le niveau de service est satisfaisant, et ne décident de migrer que
si le niveau n’a pas été satisfaisant lors de plusieurs cycles consécutifs (lors de nos tests
nous attendions deux tests négatifs consécutifs avant de lancer les procédures préalables
à la migration). Les services sont aussi remis à jour régulièrement par le Manager du site
(voir plus loin). Nous utilisions la remise à jour des informations comme déclencheur de la
vérification du niveau de service par les agents. On pourrait considérer que c’est un bon
choix, cependant il faut noter que les agents risquent alors de tous migrer simultanément
puisque ils sont tous synchronisés par cet événement déclencheur. Il est donc plus logique
soit d’allonger (et de différencier les durée de tolérance) soit de décrocher la vérification
par les agents de l’état du système de leur publication par l’agent Manager, de façon
à désynchroniser les agents. Il faut noter que la deuxième solution est moins simple à
mettre en œuvre efficacement que la première puisque il faut un événement déclencheur
et que l’on préfère que les agents extérieurs n’aient accès à aucune fonction système du
site qui les accueille directement. Cela veut donc dire que la plateforme devrait produire
des événements déclencheurs pour tous les agents qu’elle héberge se qui nous paraît très
143
Chapitre 4. Problèmes posés par un système de partage
lourd. Il faut aussi’ à terme, qu’un agent “fasse avec ce qu’il a”, en effet un agent qui serait
trop exigent par rapport aux services fournis par les ordinateurs auquel il a accès risque de
ne faire que migrer. Il faudra donc qu’il soit capable de diminuer le niveau de ses exigences
dans les domaines les moins importants de façons à ne pas être pris d’une “folie migratrice”
qui encombrerait les sites (car les procédures de migration sont assez coûteuses) et les
réseaux de communication mais s’avérerait aussi extrêmement contreproductif pour les
commanditaires de l’agent puisque tant qu’il migre il ne fait pas avancer les tâches qu’il
doit réaliser.
4.2 Capacité d’un agent processus à évaluer et à prédire

ses besoins
Il y a plusieurs points à prendre en compte :
D’abord, calculer le temps de computation d’un programme est une tâche difficile,
(équivalent dans le pire des cas à faire tourner le programme), il faut donc trouver une
façon d’estimer ce temps de computation de façon rapide.
Il faut ensuite s’assurer que l’on minimise le travail en ne refaisant pas une estima-
tion qui s’est avérée satisfaisante. Il faut donc que le système soit capable de conserver
une projection des besoins de chaque processus susceptible de migrer. On pourrait uti-
liser comme estimation, l’exécution précédente mais cela ne résout pas le problème des
nouveaux agents.
4.3 Capacité des hôtes à juger de la pertinence des ac-

cointances qui lui sont proposées (ou qu’elle ap-
plique en ce moment).
Il nous faut un critère de jugement pour la qualité des liens, on peut mesurer la
pertinence d’un lien en comptant le nombre d’agents qui le suivent et le nombre d’agents
qui en reviennent avant de s’être exécutés.
Pour juger de la qualité d’un Sniffer dans sa quête d’un hôte capable d’accueillir les
processus de son hôte d’origine, la situation est à la fois plus simple et plus compliquée :
l’utilisateur peut juger de la qualité du service que son Sniffer lui a proposé. Cela pose des
problèmes car ce service dépend de nombreux paramètres comme le temps d’exécution de
référence du processus (qu’il peut théoriquement connaître) mais aussi de la qualité des
services proposés par les hôtes actuellement connectés au réseau de partage. Ces dernières
données ne sont pas facilement accessibles. Pour y accéder, même dans une certaine mesure
il faut récupérer la trace de cet agent et comparer la machine sélectionnée aux autres par
lequel il a transité.
144
4.4. Gestion de l’hétérogénéité des hôtes
4.4 Gestion de l’hétérogénéité des hôtes

On peut utiliser une machine virtuelle comme celle de JAVA pour concevoir le système
et permettre aux hôtes de choisir s’ils laissent des agents compilés tourner en leur sein
ou non. Il faudra garantir autant que possible la sécurité de ceux qui laissent un accès
très important à leur ordinateur mais aussi assurer la réciprocité (si tu veux pouvoir
faire migrer des applications compilées, il faut que tu laisses les autres le faire aussi). Le
système ne devrait toutefois pas séparer les machines différentes (si les Sniffers préfèrent
toujours lier des machines homogènes, le système partagé se scinderait alors en plusieurs
systèmes distincts et homogènes). En effet, chaque machine offre des services logiciels
et matériels différents et il est probable que certaines applications gagneraient beaucoup
à migrer entre des machines hétérogènes. On pourrait décider de tout programmer en
JAVA et de ne laisser d’hétérogénéité qu’au niveau des services logiciels. Par exemple, un
agent en JAVA appellerait Ms World et construirait un document Word mis en page à
partir d’un fichier texte et de quelques instructions de base et renverrait à l’utilisateur un
document PDF représentant le résultat obtenu.
4.5 Gestion des priorités

Gérer les priorités demande un minimum de centralisation. En effet, chaque hôte a une
priorité évidente, placer ses tâches au mieux pour satisfaire son utilisateur. Cependant, les
priorités qui nous concernent ne sont pas celles des hôtes ou des utilisateurs mais celle de
la société qui possède le parc informatique. Il faut donc que les priorités soient fixées par
une autorité compétente et que chacun des hôtes les applique. Il faudra de plus garantir
un service minimal aux tâches qui ne seront pas prioritaires.
4.6 Les données réutilisables

Il faut aussi noter que le retour des Sniffers sur leur hôte d’origine peut servir plusieurs
desseins. Les Sniffers fourniront les informations nécessaires au placement des agents
Tâches mais ils ramènent aussi des informations qui peuvent s’avérer intéressantes à plus
long terme. Ainsi, il faudrait pouvoir extraire de la masse des données celles qui s’avèreront
suffisamment stables pour que l’on puisse les utiliser pour modéliser le système dans son
ensemble et ainsi améliorer les performances, par exemple, en envoyant automatiquement
les agents Sniffers dans une bonne zone partagée.
145
Chapitre 4. Problèmes posés par un système de partage
146
Chapitre 5
Description du fonctionnement de la
plateforme et état d’avancement du
prototypage
Dans cette partie, nous allons décrire les différents éléments de la plateforme, en étu-
diant leur description algorithmique actuelle et l’avancée du développement de leurs dif-
férents prototypes.
Les différents agents ont été testés séparément, il n’existe pas de prototype global de
la plateforme de partage. En effet, les résultats n’auraient pas été très probants puisque
le fonctionnement du prototype n’aurait pas pu être testé en situation réelle (pas assez
d’ordinateurs et de tâches différentes). Les tests et les simulations réalisés sont décrits
dans la dernière partie de ce document. La sécurité n’a jamais été implantée puisque
aucun prototype complet de la plateforme n’a été réalisé.
5.1 Les agents Managers

L’efficacité du réseau et de chacun de ses nœuds dépend de deux conditions, l’efficacité
des Sniffers qui remettent à jour les informations sur l’état du réseau de partage et
l’efficacité des agents Managers. En effet, ces derniers doivent pouvoir sélectionner parmi
les propositions de mise à jour des Sniffers celles qui sont pertinentes et celles qui ne le
sont pas.
Le module de sélection des agents Managers doit répondre à diverses exigences :
– Il doit être léger car comme il doit être actif tant que l’ordinateur est connecté au
réseau de partage, il ne faut pas qu’il consomme les ressources partagées.
– Il doit prendre en compte les caractéristiques spécifiques des ordinateurs, en effet
un ordinateur n’est pas soit un calculateur, soit un ordinateur multimédia soit un
carnet d’adresse réseau, il est plus ou moins toutes ces choses à la fois.
– Enfin, parfois un ordinateur peut être préféré à un autre, pourtant meilleur parce
qu’il a une caractéristique spécifique (adresse statique, large disponibilité . . . ) que
l’autre ne possède pas.
Pour répondre à ces trois points, il est nécessaire de construire des agents Managers
147
Chapitre 5. Description du fonctionnement de la plateforme et état d’avancement du prototypage
dotés d’un module cognitif à la fois suffisamment versatile pour pouvoir juger des ma-
chines très différentes mais aussi prendre en compte des critères de jugement parfois assez
incohérents entre eux.
Plusieurs considérations doivent être prises en compte, un ordinateur répond à plu-
sieurs descriptions plus ou moins bien. Selon les critères de sélections globaux (recherche
d’un type d’ordinateur) ses caractéristiques techniques sont plus ou moins importantes.
Par exemple, pour un calculateur scientifique la qualité du processeur et la mémoire
vice sont primordiaux, alors qu’ils sont beaucoup plus secondaires pour un entrepôt de
données.
Il était donc nécessaire de juger chaque machine selon les critères des différents types
d’ordinateurs pertinents pour le site mais il faut aussi qu’un module central prenne en
compte les intérêts globaux de la machine (garantissant que certaines catégories impor-
tantes ne sont pas sous représentées dans la liste des connaissances, par exemple).
Nous avons donc opté pour une architecture en couches agglomérant les résultats
obtenus par des modules spécialisés jugeant chaque ordinateur selon les critères d’un type
d’ordinateur (multimédia, calculateur, serveur de distribution . . . ).
5.1.1 Juger un ordinateur par rapport à un besoin spécifique

Juger un ordinateur dans l’absolu nous est apparu peu pertinent car les ordinateurs
sont des outils, il faut donc juger leur capacité à réaliser les tâches auxquelles ils sont
destinés. Il est évident qu’un super-calcutateur est efficace pour réaliser des calculs ma-
triciels, il est par contre beaucoup moins adapté pour jouer aux jeux vidéos (ne serait-ce
simplement que parce que les grands titres du marché sont destinés à fonctionner que sur
un PC sous Windows) de la même façon qu’un râteau est une mauvaise pelle.
Il nous est donc apparu qu’il fallait juger les ordinateurs selon les critères spécifiques
aux utilisations que peut en avoir l’agent Manager et non selon des critères généraux.
Pourquoi un module utilisant des “graphes conceptuels”

On peut en général décrire un ordinateur selon diverses caractéristiques (processeur,
mémoire, disque dur, type de connexion au réseau . . . ), cependant la qualité d’un ordina-
teur ne dépend pas seulement de ces différentes caractéristiques prises séparément mais
aussi de leurs liens entre elles. Par exemple, un excellent processeur exige une mémoire
vive suffisante pour exprimer ses pleines capacités. Sans cela, beaucoup de temps sera
perdu lors des appels mémoires voir de l’utilisation de la mémoire virtuelle. Il est donc
nécessaire de prendre en compte, non seulement la qualité des différents composants de
l’ordinateur mais aussi l’efficacité globale de ces composants lorsqu’ils sont associés.
Dans ce but, nous avons décidé de décrire chaque modèle d’ordinateur comme un
réseau dans lesquels les nœuds sont les différentes caractéristiques de l’ordinateur et les
liens l’influence des nœuds les uns sur les autres. Nous avons considéré, pour simplifier
que les liens seraient monodirectionnels (puisque l’influence d’une valeur sur une autre
n’est pas nécessairement réciproque) mais potentiellement doublés.
La note donnée à un ordinateur est en fait la somme des valeurs d’activations de
chacun des nœuds corrigés en fonction des liens qui les relient.
148
5.1. Les agents Managers
Pour l’instant les nœuds sont de plusieurs types :

– La plupart des nœuds reçoivent une valeur réelle (un float Java), qui représente
une note globale (c’est le cas des nœuds généralement activés par la qualité des
processeurs, des mémoires, des cartes spécifiques, la qualité de la connexion réseau
de l’ordinateur ou des disques). Le niveau d’activation de ces nœuds dépend de la
note du composant qu’ils jugent.
Normalement la solution employée est la suivante : chaque nœud à une valeur d’ac-
tivation minimale. Si la note est inférieure à la valeur d’activation minimale, l’acti-
vation finale du nœud est 0 et si elle est supérieure à la valeur d’activation minimale,
l’activation est une fonction affine de la note obtenue (la valeur d’activation suit un
modèle la conductivité d’une diode affine en fonction de la tension électrique).
– Le second type de nœud est un nœud de type valeur constante, il permet de prendre
en compte des cas où seule une valeur minimale est nécessaire. Il reçoit les mêmes
entrées que les nœuds à valeur réelle (un float Java) et retourne 0 si la note est
inférieure à la valeur minimale et une valeur constante si la note est supérieure à la
valeur d’activation minimale (c’est un cas spécifique du nœud précédent).
– Le troisième type de nœud est dit booléen car il reçoit un booléen et retourne 0
si FAUX et une valeur d’activation fixée si VRAIE. Ce type de nœud permet de
prendre en compte le type de connexion à Internet (statique ou dynamique).
– Le dernier type de nœud est activé par un tableau de booléen qui représente l’occu-
pation de l’ordinateur sur un échantillon temporel (dans nos exemples, l’échantillon
est journalier, heure par heure mais un échantillon hebdomadaire par demi-journée
serait sans doute plus pertinent.
Nous avions, au départ, décidé de représenter l’occupation par un tableau de réels
représentant la valeur de l’occupation du processeur, mais nous avons changé d’avis
car ces valeur risquaient de prendre trop de place. Nous avons donc opté pour une
représentation binaire inspirée des tarifications énergétiques (la valeur du tableau,
l’occupation est VRAI si l’occupation du processeur est supérieure à 50% et FAUX
sinon).
– Le dernier type de nœud reçoit les caractéristiques du carnet d’adresse de l’ordi-
nateur jugé. Cela permet de juger un ordinateur, non pas par rapport à ses carac-
téristiques intrinsèques mais par rapport aux services auxquels il a accès. Il note
les pourcentages des différents types d’ordinateur en préférant certains mots clés
spécifiques. Il sert essentiellement dans les modèles d’ordinateur de type “carnet
d’adresse divers” auquel cas, l’activation est une fonction qui favorise les carnets
d’adresse divers avec des pourcentages équilibrés comme la suivante :
carnet → R
act : Qlc
c 7→ i=1 (1 + matc (i, 2))
avec carnet = {lc , matc } où matc = (ni , xi )i∈{1,...,lc} ∈ (Nom, [0, 1])lc
149
ou, si on prend le nom en compte :
X
lc
1 ssi nom ∈ D
c 7→ σ(matc (i, 1) × matc (i, 2) + 1)3 avec σ(nom) =
0 sinon
i=1
D est l’ensemble des noms de types d’ordinateurs intéressant le client.

Les modèles de type “cluster spécifiques” recherchent un mot clé caractéristique dans
le carnet d’adresse (comme “calculator” ou “multimédia”) et applique une fonction
affine à seuil au pourcentage ou à la note de ce nom dans le carnet d’adresse.
Définition : une fonction f est affine à un seul seuil x0 ssi
R → R

f: 0 si x < x0
x 7→
ax + b avec (a, b) ∈ R sinon
2
Cette méthode peut induire en erreur si l’ordinateur jugé possède un excellent

exemple d’un type d’ordinateur, dans ce cas le pourcentage obtenu est trompeur,
cependant cette valeur devrait en général être représentative.
Nous avons de plus décidé de construire deux types de liens différents : des liens
d’exigence et des liens de compensation. Ces deux liens ont des raisons d’être différentes :
– Les premiers représentent le fait pour fonction au mieux de leur capacité certains
composants exigent que d’autres fonctionnent bien (par exemple, sans une mémoire
vive suffisante, un processeur ne fonctionnera pas à sa pleine capacité pour certaines
applications, il y aura des temps de latence dus aux appels mémoires). Il est donc
nécessaire de revoir la valeur d’activation de ces nœuds en fonction de l’activation
d’autres nœuds.
Pour répondre à cette exigence, ce type de nœud reçoit en entrée la valeur d’acti-
vation des deux nœuds qu’il relie et compare la valeur du nœud destination à une
fonction affine du nœud origine. Si la valeur d’activation du nœud destination est
inférieure à la valeur de cette fonction pour la valeur de l’activation du nœud des-
tination, elle réduit la valeur de l’activation du nœud d’origine d’une valeur égale
à l’image de la différence entre les deux valeurs par une autre fonction affine. Cela
permet de prendre en compte des lacunes plus ou moins importantes.
– Le deuxième type de lien est le lien de compensation. Il permet de prendre en
compte le fait que la qualité de certaines caractéristiques d’un ordinateur permet de
compenser légèrement ses limites sur d’autres points. (un mauvais disque peut être
compensé par suffisamment de mémoire vive (pour la plupart des applications). La
compensation fonctionne de la même façon que l’exigence. Si la valeur d’activation
du nœud d’origine est supérieure à l’image par une fonction affine de la valeur
d’activation du nœud destination du lien, la valeur d’activation du nœud destination
est augmentée de l’image de la valeur d’activation du nœud d’origine par une autre
fonction affine.
Les nœuds peuvent ou non être reliés par des liens (certains nœuds sont complètement
indépendants) dans un seul sens ou dans les deux sens par des liens qui peuvent être des
compensations, des exigences voir les deux à la fois.
150
5.1. Les agents Managers
Finalement, l’évaluation d’un ordinateur selon un type spécifique d’ordinateurs revient

à la somme suivante, avec vi la valeur de l’activation du iieme nœud et lienij (vi , vj ), la
valeur d’activation (positive, négative ou nulle) du lien mono-directionel qui relie le iieme
nœud et le j ieme nœud, en fonction de l’activation de ces deux nœuds.
X
nn X
nn X
nn
notef inale = vi (ordinateur) + lienjk (vj (ordinateur), vk (ordinateur))
i=1 j=1 k=1
On considèrera que ∀j ∈ N et ∀x ∈ R, lienjj (x, x) = 0. De même, s’il n’existe pas de lien

entre deux nœuds, le lien qui les lie a une valeur nulle.
Quelques exemples de types d’ordinateurs

Nous avons construit la description de différents types d’ordinateurs qui peuvent être
des nœuds caractéristiques de notre système partagé :
– L’ordinateur multimédia,
– Le “serveur de clusters de calcul”,
– L’ordinateur “à connaître”,
– Le calculateur,
– Et enfin l’ordinateur qui ressemble beaucoup au mien (si possible en mieux).
La description de ces différents types d’ordinateurs a été réalisée à partir de nos opi-
nions propres, elles ne sont sans doutes pas complètement pertinentes mais elles per-
mettent de réaliser des tests de validité de notre architecture.
5.1.2 Le système d’agglomération des valeurs

Noter les différents ordinateurs n’est pas suffisant, il faut aussi agglomérer ces valeurs
de façon à décider quel ordinateur conserver dans sa base mémoire et quel ordinateur
éliminer. Le choix final présente une difficulté notable, les ordinateurs ont été jugés par
plusieurs juges indépendants (les modules de jugement spécifiques) lesquels les ont déclaré
aptes ou inaptes sur des critères sans doutes très différents. Il faut de plus noter que
chaque modèle est important (sinon l’utilisateur n’aurait pas pris la peine de construire
sa représentation), il ne doit donc pas être sous représenter sous prétexte qu’il note plus
sévèrement que les autres.
On pourrait comparer cette situation à un concours où chaque candidat est jugé sur
plusieurs matières, à une différence près, l’importance des différentes matières ne peut
être représentée par des cœfficients puisque l’importance comparée des différents modèles
dépend sans doute du nombre d’ordinateurs qui y répondent.
Pour ce faire, plusieurs points doivent être éclaircis :
– Sur quels critères choisit-on les ordinateurs à conserver et les ordinateurs à exclure
puisqu’ils sont notés par des juges qui n’utilisent pas le même système de notation.
– Comment choisir les types d’ordinateurs le plus important à un instant donné.
La solution la plus logique est d’employer pour chaque ordinateur jugé, la somme des
notes qu’il a obtenu des différents types, ponctuée de l’importance relative de ces types
151
laquelle doit dépendre de la l’écart entre sa représentation théorique au sein de l’ensemble

des ordinateurs connus et de sa représentation théorique.
notesd0 un ordinateur
 → R
x0
notation :  ..  Pn
 .  7→ i=0 I(vi0 − vi (t))xi
xn
avec :
[0, 1]2 → R
I:
(x, y) 7→ K(1 + x − y)2
Cependant, cela pose deux problèmes :
– Une autre spécificité de ce problème doit être prise en compte : il est impossible
de classer les ordinateurs dans des catégories associées aux types, en effet, la plu-
part seraient sans doute difficilement classables (pouvant répondre au critères de
plusieurs catégories). Il est donc difficile de classer les différentes catégories les unes
par rapport aux autres. Nous avons donc opté pour utiliser la part de chaque type
d’ordinateur sur l’ensemble des notes obtenues.
R+ → (Descriptions
  d0 ordinateur)n
c0 (t)
Avec Carnet :  .. 
t 7→  .  le carnet d’adresse à l’instant t
cn (t)
et xij est la jième note du iième ordinateur du carnet d’adresse, on a
R+ → R+
Pk
∀i ∈ {1, ..., n} , vi : j=1 xij (t)
t 7→ vi (t) = Pn Pk
l=1 p=1 xlp (t)
Ainsi, on peut passer outre la difficulté de classement des ordinateurs dans des ca-
tégories. Nous utilisons ensuite cette valeur pour compenser la trop grande faiblesse
(ou la trop grande force) des catégories sous représentées. Pour cela nous la compa-
rons au pourcentage de chaque type d’ordinateur recherché par le propriétaire du
site (l’utilisateur).
Cette solution présente un défaut. Supposons qu’une catégorie de seconde impor-
tance soit largement sous représentée, le prochain ordinateur correspondant à ses
critères sera sans doute choisi, même si le système a déjà rejeté des ordinateurs qui
correspondaient mieux aux critères, simplement parce qu’au moment où des Sniffers
ont ramené leurs descriptions, la catégorie était moins sous représentée et donc moins
prioritaire. Pour résoudre ce défaut de “choix en catastrophe”, nous préconisons de
conserver les bonnes descriptions, même si elles ne sont pas assez bonnes pour être
sélectionnées, au moins quelques temps. Il deviendrait ainsi possible d’ajouter au
carnet d’adresses un ordinateur dont la description aurait été apportée précédem-
ment. c’est d’ailleurs semblable à la mémoire enregistrée décrite dans l’architecture.
Cependant, cela n’a pas été réalisé ici. Nous proposons cependant, ci-dessous, une
solution qui permet de compenser certains excès.
152
5.2. Les agents Sniffers
Si on décide de conserver l’historique de toutes les notes, on peut équilibrer l’im-

portance des juges en modifiant la constante Kj à la fin d’un cycle d’utilisation.
Pk
1 Si
Kj := ancienKj × × i=1
(5.1)
k Sj
Cette solution permet d’augmenter l’importance des catégories sous représentées.
Ainsi, un type représentant une part de la somme des notes beaucoup plus faible
que sa part théorique voit sa pondération augmenter lors des évaluations d’ordi-
nateur à venir. Cette solution assure un équilibre relatif (si l’un des types donne
des notes trop basses sont avis n’est pas souvent pris en compte, par contre son
importance augmente car il est considéré comme sous représenté) les deux doivent
donc s’équilibrer.
– Il est difficile d’assurer que les notes données par les différents jugent est comparable.
En effet, même si on arrivait à construire des notes comparables à une date donnée,
elles ne le seraient sans doute plus peu de temps après car l’évolution des ordinateurs
dérèglerait rapidement le système. Cependant, il faut que les différentes exigences
(en terme de représentation des différents types) soient respectées.
Ce dernier correctif n’est pas capital (on peut considérer qu’il est inclus dans le précé-
dent), cependant il permet de conserver des correctifs même si le programme est relancé
par exemple.
5.1.3 Les autres fonctionnalités de l’agent Manager

L’agent Manager ne se borne pas à construire son carnet d’adresse, il est aussi le
gestionnaire de la plateforme locale. A ce titre, il vérifie la fiabilité des agents qui s’exécute
sur son site, il gère les réservations et la charge de la machine et les propriétés, il remet
à jour les caractéristiques de son site. Les fonctionnalités de gestion de l’agent n’ont
pas été implantées. Pour la fonction de jugement sur les autres agents, nous considérons
une méthode de type “bouche-à-oreille”, chaque site demandant son avis aux autres sites
de sa liste de connaissance sur certains émetteurs d’agents mobiles. L’idée est que l’on
puisse parrainer un autre utilisateur. De la même façon on peut utiliser les Managers
pour pouvoir implanter un système de d’incitation au partage. En demandant de temps
en temps à d’autres Managers s’ils ont une description du site d’origine de chaque tâche
présente qui comprend la tendance au partage de ce dernier. Pour réaliser tout cela, nous
devons construire un agent Manager plus complet que celui réalisé jusqu’ici. .
5.2 Les agents Sniffers

5.2.1 Description des agents Sniffers
Des prototypes de Sniffers ont été construits lors des premiers tests de la plateforme.
Ce sont les agents les plus simples de la plateforme. Leur fonctionnement est simple : ils
vagabondent en réparant les incohérences et en recherchant les meilleurs emplacements
selon leurs critères. Nous allons donc rapidement décrire leur fonctionnement.
153
Les agents se déplacent de site en site. Lorsqu’ils arrivent sur un nouveau site, ils com-
mencent par comparer leurs connaissances aux connaissances locales (ils peuvent ainsi
remettre à jour leurs connaissances obsolètes et proposent au Manager local des correc-
tions si certaines des informations de ce dernier sont obsolètes). Après quoi, ils comparent
leur liste de connaissances et la liste locale et remplacent les sites qu’ils connaissent par
ceux de la liste locale qui sont meilleurs. Ils proposent au Manager local de procéder à
des remplacement si leur liste contient des sites qu’ils considèrent supérieurs à la liste
locale. Une fois que les propositions et les modifications ont été réalisées, soit le Sniffer
demande une réservation de puissance sur une certaine plage horaire (s’il est destiné à
rechercher un emplacement pour une tâche spécifique à une date spécifique et si les réser-
vations sont autorisées)(il faut noter que si la réservation est acceptée, le Sniffer retourne
directement sur son site d’origine), soit il passe directement à l’étape suivante : le Sniffer
choisit un autre site, en partie au hasard dans sa liste et migre vers ce nouveau site.
Une fois que sa durée de vie est écoulée, il retourne sur son site d’origine pour rapporter
ses nouvelles connaissances. Certains Sniffers qui sont liés à une certaine tâche peuvent
rejoindre l’agent Task encapsulant cette tâche sur un site choisi à l’avance.
La seule fonctionnalité notable des Sniffers est leur capacité à classer et à choisir
des sites. pour permettre aux Sniffers de faire ce choix, nous utilisons une méthode de
classification basée sur les treillis de Galois.
5.2.2 Représentation des préférences en utilisant des treillis de

Galois
Pouvoir classer les ordinateurs décrits est une nécessité. En effet, les agents ne doivent
pas seulement représenter les machines, il faut aussi qu’ils utilisent ces informations pour
prendre des décisions. En effet, il faut qu’ils soient capables de choisir un site sur lequel
migrer. Dans ce but, ils doivent pouvoir comparer les sites et les classer.
Ce système de classification doit avoir quelques caractéristiques particulières :
– Classer une machine doit être très peu coûteux (car on ne veut pas que les processus
de classement utilisent trop de ressources, notre but étant de fournir des ressources
aux Tasks).
– Les fonctions de classement doivent être simples et peu encombrantes car les agents
sont destinés à migrer et on ne veut pas qu’ils soient tellement lourds que la migration
devienne trop coûteuse.
– Le classement doit être systématique et sans ambiguïté.
Pour réunir ces caractéristiques, nous utilisons des treillis de Galois citeORE44,
DID03.
Les treillis de Galois ont été utilisés dans de multiples situations, il faut cependant
noter qu’ils s’appliquent assez bien à la représentation de certaines connaissances simples
à décrire. Rudolf Wille [Wil90] utilise les treillis de Galois pour représenter des données
et en retirer les concepts sous-jacents. D’une certaine façon nous faisons l’inverse, au
lieu de partir des descriptions des objets pour construire les concepts qui les englobent,
nous partons des concepts (en général, celui d’un ordinateur efficace (ou au contraire peu
efficace) du point de vue d’une tâche) pour juger les descriptions d’ordinateurs que l’on a
154
5.2. Les agents Sniffers
Fig. 5.1 – Un exemple de représentation de préférences par treillis de Gallois
réunies en vue d’une potentielle migration, de façon à choisir un ordinateur.

Les treillis de Galois nous offrent un classement sans ambiguïtés, il est toujours possible
de placer un élément en O(n) comparaisons (avec n le nombre de nœuds de la plus grande
branche du treillis).
Dans notre cas, F est le treillis des descriptions (qui pourrait être vu comme un
classement partiel de sites abstraits et que nous allons présenter dans la figure 5.1 et E est
le treillis d’ensemble de sites réels associés. A ces descriptions, nous associons des valeurs
de préférence. Il se peut en effet que certains ordinateurs ne soient pas comparables d’après
les treillis mais que l’on puisse quand même considérer qu’ils n’ont pas le même intérêt
ou qu’au contraire certains nœuds existent pour des raisons de complétude du treillis.
On peut ainsi garantir qu’une machine sera classée en au plus n comparaisons n la
longueur de la plus longue branche du treillis). Il sera toujours possible de classer une ma-
155
chine dans une catégorie, donc de la comparer. Il faut cependant noter qu’un treillis étant
un ordre partiel, certaines machines seront incomparables. Pour cette raison, nous deman-
dons aussi à l’utilisateur de donner une qualité à chacune des catégories définies par les
descriptions. On peut par exemple définir les catégories suivantes : insuffisante, suffisante,
correcte et excellente, dans ce cas l’agent choisira toujours de migrer vers une machine
se trouvant dans la catégorie la plus élevée. Et au sein de cette catégorie, une machine
parmi celles qui appartiennent à l’ensemble le plus restreint disponible. Cette solution ne
nous permet pas de garantir que la meilleure solution sera sélectionnée, mais elle donne de
la flexibilité à l’ensemble (un agent pourra choisir une destination en fonction des choix
des autres agents, même si ce n’est pas son meilleur choix a priori, etc.) la représentation
et l’outil de classification étant assez simples, ils seront faciles à transporter, ce qui est
un avantage primordial pour la migration. De plus ce système de classification est assez
simple, ce qui peut permettre assez facilement de construire de nouvelles classifications.
5.2.3 Justification des Sniffers par rapport à une solution par

envoi de message
– Les messages présentent une faille de sécurité des données (en échange, ils ne pré-
sentent pas de risques de contamination).
– Les agents Sniffers peuvent découvrir et cartographier un système qui est par dé-
finition (dynamique) connu de façon seulement partielle et en partie obsolète. Un
résultat semblable ne serait possible par envoi de message que si tous les sites po-
tentiels étaient connus les uns de tous les autres. Le poids du système serait alors
trop important pur que le système puisse-t’ être géré.
– Ils permettent la recherche à partir des connaissances des autres agents de machines
efficaces pour les besoins des utilisateurs.
– Les Sniffers explorent le système de façon seulement partielle (on ne peut donc
pas garantir d’optimalité mais en échange on évite la saturation du réseau par des
pings).
Le nombre de pings nécessaire pour qu’une machine connaisse toutes les machines du
réseau (elle ne peut pas lancer des pings au hasard sur Internet) est de n par machine avec
n le nombre de machines connectées (donc n2 pour que toutes les machines se connaissent).
Pour prendre les mises à jour en compte il est nécessaire de répéter ces pings régulièrement
(on pourrait imaginer des chaînes de pings mais le résultat serait le même). Cela exige de
plus que chaque machine connaisse toutes les autres (ce qui signifie que chaque agent a un
carnet de connaissances de n entrées remises à jour en continu. Une solution complète nous
apparaît donc inapplicable. Les agents permettent de suivre un algorithme de recherche
de machine appropriée sans que l’hôte cherchant une machine étudie le contenu du carnet
d’adresses d’un autre à distance (cela entraînerait de gros problèmes de surcharge de
communication).
Les agents sont plus gros que les pings mais supposons que chaque hôte produise m
Sniffers, le nombre de communications liées à la migration des agents est de n ∗ m (donc
en O(n)) alors que dans le cas des pings, les communications sont en O(n2 ) pour obtenir
la couverture potentielle du système dans son ensemble. En fixant le nombre de Sniffers
156
5.3. Les agents Tasks
originaires de chaque hôte, on limite suffisamment le nombre de communications.
5.3 Les agents Tasks

Les agents Tasks ont pour mission de transporter les tâches distribuées vers un site où
elles pourront s’exécuter correctement. Dans ce but, ils doivent pouvoir classer les sites
et doivent être mobiles. Ils classent les sites de la même façon que les Sniffers (car leurs
besoins sont semblables). Les agents Tasks vérifient régulièrement que les services offerts
par leur site d’accueil sont suffisants, s’ils ne le sont plus, ils choisissent un nouveau site
et migrent vers cette nouvelle destination. Ils choisissent leur nouvelle destination soit
dans leur propre liste soit dans la liste locale. Dans une version utlérieure, les agents
Task pourront prendre rendez-vous sur un site précis avec un Sniffer qui leur serait
associé. Dans ce cas, le Sniffer, lorsqu’il arrive sur le site du rendez-vous donne à l’agent
Task toutes les descriptions qu’il a récoltées par l’intermédiaire du tableau noir local.
L’algorithme de l’agent Task est donné en annexe. Les fonctionnalités des agents Tasks
peuvent varier selon la nature des tâches qui les constituent. En effet selon le type de
tâche, la tache peut être une fonction programmée en Java appelée par l’agent lors de
son exécution, au cas où la tâche et une fonction en langage machine, seule la fonction
d’appel du code est incluse dans l’agent.
5.4 Quelques questions de sécurité

5.4.1 Les droits des agents
Il faut se souvenir qu’utiliser des agents distants est dangereux, non seulement pour
la machine d’accueil (un processus libre de toute contrainte sur une machine est plus
dangereux que la plupart des virus), mais aussi pour l’ordinateur émettant l’agent (en
effet, le code migrant risque d’être corrompu pendant qu’il tourne sur la machine distante
et de corrompre les autres machines lors de ses migrations, jusqu’à la machine dont il
est originaire). Il faut donc que nous assurions la gestion des droits et de la sécurité des
utilisateurs. Il faut cependant encourager les utilisateurs à partager le plus de ressources
possibles, il faut donc que les utilisateurs reçoivent “des récompenses” si ils partagent
beaucoup.
Que peut-on partager ?
– Laisser tourner un programme JAVA qui ne serait concerné par aucun des points
suivants.
– Accès aux données partagées de l’hôte avec les droits et dans les conditions indiqués
par celui-ci.
– Utilisation de programmes installés sur l’ordinateur hôte pour lesquels le propriétaire
de l’hôte a donné son accord.
– Laisser tourner un programme classique (langage machine) si l’utilisateur l’accepte.
Et à quels services doivent impérativement être interdits aux agents (et aux hôtes) ?
– L’accès au disque dur : aucun programme ne doit pouvoir écrire un exécutable sur
le disque dur de l’utilisateur, ni accéder au contenu du disque en dehors des données
157
explicitement spécifiées par le propriétaire de la machine.

– Les agents ne doivent avoir accès à aucun service mémoire (susceptibles de leur
servir de point de départ pour obtenir des droits sur la machine).
– Bloquer les communications externes vers l’extérieur du système ? (pour empêcher
que le système serve de base pour se lancer dans une attaque par “flooding”) mais
cela interdit d’utiliser le système pour lancer des requêtes complexes et parallèles
sur des bases de données externes ou comme base pour des recherches sur Internet.
– Interdire les communications non textuelles entre agents sur la même machine : pour
empêcher un agent d’en contaminer un autre ou deux agents de fonctionner comme
des prions.
– Interdire aux agents d’accéder directement aux Sniffers (pour les mêmes raisons
de contamination) et de communiquer directement avec les Sniffers, il faut que les
informations qui transitent entre les agents et les Sniffers soient publiques, pour
éviter qu’un Sniffer “mente” à tout le monde sauf aux agents ayant la même origine
que lui de façon à avantager ceux-ci par rapport aux autres.
5.4.2 Informations accessibles et droits des Sniffers

Les agents Sniffers ont besoin d’avoir accès à certaines informations pour pouvoir
remplir leurs différentes tâches. Il faut en échange garantir qu’ils ne sont pas dangereux
pour la machine qu’ils viennent tester. En effet leurs perpétuelles migrations en feraient des
vecteurs très efficaces pour une infection virale ou même simplement des tests préalables
à une attaque informatique. Pour minimiser les risques d’attaques utilisant les Sniffers,
il faut assurer qu’ils ne peuvent accéder qu’aux informations fournies par l’hôte. Ces
informations peuvent être très diverses. Nous considérerons ici les suivantes :
Processeur et mémoire, OS, processeur vidéo, qualité des communications (bande pas-
sante, limitations, nature de la communication, adresse statique ou dynamique . . . ), dis-
tance à une machine précise, droits et limites relatifs l’accès à la machine, programmes
partagés, restrictions concernant les agents (langage, nombre d’agents simultanément,
communications externes en cours de fonctionnement, etc.) et satisfaction des autres
agents. Enfin, nous considérons qu’il est nécessaire d’inclure un historique de l’état du sys-
tème ainsi que certaines remarques concernant l’utilisateur (l’utilisateur reste t’il connecté
pendant de longues périodes, le système s’éteint-il proprement en général . . . ).
Ces caractéristiques sont nécessaires, même si elles peuvent déjà présenter une menace
car ces informations peuvent servir de base pour certaines attaques, il est nécessaire que
les Sniffers y aient accès. En effet le processeur et l’OS sont nécessaires car ils consti-
tuent la base de la machine, ils permettent de déterminer les compatibilités mais aussi de
choisir une machine ayant la puissance de calcul nécessaire à une tâche. La qualité des
communications et les distances sont absolument nécessaires car de nombreuses tâches
risquent d’exiger des communications, soit entre agents distants soit entre les agents et
leur machine d’origine. Les autres informations concernent les services présents sur l’hôte
en dehors de la puissance de calcul. Il pourrait être possible de ne pas les remplir dans le
cas où le propriétaire de l’hôte refuse de fournir des services originaux (logiciels spécifiques,
cartes de décompression ou de traitement vidéo . . . ).
L’accès aux informations caractéristiques de l’hôte est nécessaire au bon fonctionne-
158
5.4. Quelques questions de sécurité
ment des Sniffers, il faudrait cependant leur interdire tout le reste pour des raisons de
sécurité (voir Prec). En effet, les Sniffers doivent pouvoir laisser une trace de leurs in-
vestigations, nous considérons donc qu’ils doivent pouvoir contacter l’agent gestionnaire
de l’hôte (pour pouvoir lui faire part des résultats de leurs “enquêtes migratoires”. Il faut
aussi que les Sniffers puissent laisser des messages aux agents Tâches dont ils servent les
intérêts. Il faut cependant empêcher que ces messages soient trop secrets, pour
empêcher que les Sniffers puissent mentir quand ils donnent des informations
publiques pour tenter de favoriser les agents Tâche alliés (à voir), cependant,
cela pose des problèmes de sécurité puisqu’on peut prévoir la destination des agents en
suivant les Sniffers qui leur sont associés. Pour éviter ces problèmes, il serait possible
que le Manager n’inscrive les messages qu’après l’arrivée de l’agent concerné. Ainsi, il
devient impossible de prévoir les déplacements d’un agent puisque les messages ne sont
rendus publics qu’après qu’il ait pris connaissance de leur contenu. Il faut garantir que
les messages sont clairs pour tous les agents qui désiraient les lire, cependant tout ce que
nous pouvons garantir c’est qu’ils sont sémantiquement corrects car le sens du message
peut être différent pour l’agent qui sait le décoder (histoire des codes secrets).
159
160
Chapitre 6
Dans ce chapitre, nous allons présenter les différentes applications testées et simula-
tions que nous avons réalisé pour valider notre outil de partage de charges. Comme, pour
des raisons d’infrastructure, il n’existe aucune implantation globale du programme, nous
avons du tester chaque angle de l’application séparément. Nous avons donc choisi de tes-
ter la validité d’un système de partage de ressources basé sur la mobilité et l’utilisation
des Sniffers dans leur forme actuelle en testant un prototype de l’application à échelle
réduite. Nous avons de plus testé le " module de choix des connaissances " des Managers
en simulant l’arrivée d’un très grand nombre de descriptions d’ordinateurs et en simulant
une potentielle perte due à un trop plein d’informations.
Nous allons donc présenter les différentes simulations réalisées ainsi que les résultats
obtenus.
6.1 Le prototype de plateforme

6.1.1 Introduction
Nous avons implanté un prototype partiel de notre sur plusieurs ordinateurs du LIP6,
pour pouvoir tester plusieurs caractéristiques de notre système. Nous pouvions tester
les transferts des différents agents mobiles, le fonctionnement des Sniffers et la capacité
du système dans son ensemble à distribuer les tâches. Dans ce but nous avons créé un
prototype en utilisant la plateforme SyMPA. Ce prototype nous a permis de tester le
fonctionnement des Sniffers et de vérifier qu’ils pouvaient être (au moins à une échelle
réduite) un moyen pertinent de transfert et de remise à jour des informations.
6.1.2 Présentation des tests et résultats

Pour notre démonstration, nous avons utilisé le langage CLAIM [FSS03a] et la plate-
forme SyMPA [SFS03] car elle permet non seulement une définition rapide des agents mais
aussi un suivi facile de leurs pérégrinations au cours de leur exécution. CLAIM [FSS03b]
est un langage de programmation déclaratif pour des agents autonomes, intelligents et
mobiles, qui combine des éléments des langages de programmation orientée agent, pour
représenter l’intelligence, le raisonnement et les interactions des agents, et des éléments
161
Chapitre 6. Les tests et les résultats obtenus
des langages concurrents, pour représenter la mobilité des agents. La représentation hié-
rarchique des agents et les primitives de mobilité sont inspirées du calcul des ambients
[CG98, Car99]. Un agent CLAIM est une entité autonome, intelligente, communicante et
mobile, qui a plusieurs composants : l’autorité, le parent , les connaissances sur les
autres agents et sur le monde, les buts, la queue de messages, les capacités, les
processus qui se déroulent en parallèle et les sous-agents. Le langage offre deux types
de raisonnement pour un agent : raisonnement en avant (activer des capacités quand des
messages arrivent) et raisonnement en arrière (activer des capacités afin d’atteindre des
buts). Le langage est supporté par un système multi-plateforme, appelé SyMPA, compa-
tible avec le standard MASIF [MAS] de l’OMG, qui permet de définir des agents et des
classes d’agents, de vérifier la syntaxe des définitions, d’exécuter, de terminer, d’identifier,
de migrer et de visualiser le comportement, la communication et la mobilité des agents.
L’architecture de SyMPA (voir Figure 22) a trois niveaux que nous allons présenter en-
suite, en montrant leur compatibilité avec l’architecture de MASIF :
– le système central : offre des services pour la gestion et la localisation des agents et
des systèmes d’agents. Dans MASIF, le correspondant est MAFFinder, une interface
qui offre des méthodes pour la gestion des agents, des places et des systèmes d’agents
d’une région. Dans SyMPA, le système central administre (dans cette version) tous
les agents. Dans les prochaines versions de SyMPA, l’administrateur du système sera
capable de choisir parmi plusieurs solutions de gestion, selon l’application courante.
– le système d’agents : une plate-forme qui peut créer, interpréter, identifier, exécu-
ter, transférer et terminer des agents. Il correspond à l’interface MAFAgentSystem
de MASIF. Il offre une interface pour définir des agents et des classes d’agents
CLAIM, un interprète pour vérifier la syntaxe des définitions et des méthodes de
gestion.
– l’agent : une entité autonome, intelligente et mobile définie avec le langage CLAIM.
Chaque agent est uniquement identifié dans le système, mais contrairement à MA-
SIF, en SyMPA on peut avoir des clones d’un agent. Comme les ambients, les agents
forment des hiérarchies. Avec cette représentation une place de MASIF devient un
agent normal qui a des sous-agents. Pour chaque agent il existe un processus appelé
PAgent qui offre des méthodes pour la gestion de l’état de l’agent et qui déclenche
plusieurs processus :
– une interface pour visualiser le comportement, la communication et la mobilité
des agents ;
– un processus qui exécute en parallèle les processus de l’agent ;
– un processus qui réalise le raisonnement en avant de l’agent ;
– un processus qui réalise le raisonnement en arrière de l’agent.
Afin d’assurer l’efficacité et la sécurité des interactions entre les agents, entre les sys-
tèmes d’agents et entre le système central et les systèmes d’agents, nous avons défini des
protocoles de communication correspondants aux opérations de l’agent. De plus, on utilise
des mécanismes de cryptographie et chaque message est crypté avant la transmission et
décrypté à la destination.
La migration est réalisée en utilisant les primitives de migration inspirées du calcul
des ambients : (open), pour ouvrir les frontières d’un sous-agent, (acid), pour ouvrir ses
propres frontières, (in), pour entrer dans un agent du même voisinage, (out), pour sortir
162
6.1. Le prototype de plateforme
Fig. 6.1 – L’architecture de SyMPA
du parent actuel ou (moveTo), pour migrer dans un autre agent. Dans CLAIM, un agent
peut appeler des fonctions implantées en Java. La migration d’un agent est forte pour
ses processus, qui sont repris au niveau où ils ont été interrompus, une fois l’agent à
destination, et elle est faible pour les fonctions Java, parce qu’un processus Java en cours
au début de la migration est relancé depuis le début une fois l’agent arrivé à destination.
Nous avions déjà utilisé CLAIM avec succès pour implanter des applications de commerce
électronique [SFS03]. Nous avons donc décidé de l’utiliser pour implanter notre système
de partage de ressources. Comme nous l’avons vu dans la description de l’application, il
existe trois classes d’agents. Certaines de leurs capacités font appel à des méthodes Java.
Les agents Managers sont des agents statiques situés sur chaque ordinateur impliqué.
Ils possèdent une représentation et un classement des autres sites sous la forme de treillis
de Galois. Ils ont la capacité de créer des agents Sniffer, de donner leurs connaissances
sur les autres machines sites en réponse aux requêtes des agents Sniffers et Tasks. Ils
peuvent mettre à jour leurs connaissances des sites lorsqu’un agent Sniffer leur donne
des informations plus à jour que les leurs. De plus, quand l’agent Manager détecte une
surcharge de la machine qu’il gère, il peut exiger le départ de certains des agents Tasks
163
présents.
Les agents Sniffers sont créés par les agents Manager et ils commencent à migrer vers
les autres ordinateurs où ils remettent à jour à la fois leurs propres connaissances et celles
des agents Managers locaux. Quand ils arrivent sur un site, ils demandent au Manager
local son treillis de Galois de connaissances, ils actualisent leurs propres données et si
celles-ci sont plus récentes que celles du Manager, ils proposent d’actualiser celles de ce
dernier. Quand il a visité tous les ordinateurs connus, ou quand il a dépassé un temps
limite, il rentre sur son site d’origine et fournit à son Manager d’origine les connaissances
accumulées au cours de ses migrations.
Les agents Tasks ont une certaine tâche à réaliser. Pour cela, un agent Task migre vers
la meilleure machine selon son treillis de Galois et commence la tâche. Quand il détecte
que les ressources locales ne sont plus suffisantes ou quand il reçoit un ordre de départ de
la part de l’agent Manager de l’ordinateur où il se trouve, il cherche la meilleure machine,
il migre et il reprend son travail. A la fin, il rentre sur son site d’origine, s’inscrit auprès
du Manager qui l’a créé et se détruit.
6.1.3 Expérimentation
Notre modèle pouvait difficilement être testé en situation réelle, nous avons donc été
forcés de réaliser nos tests à une échelle moindre, d’autant plus que les pare-feux (firewalls)
de l’Université Paris-Dauphine et du LIP 6 empêchent les agents CLAIM de communiquer
correctement. Lors de nos tests, nous avons utilisé une version très simplifiée de notre
programme et nous l’avons installé sur trois machines assez différentes, à la fois par leur
puissance nominale et leur format (portables, ordinateurs de bureaux etc.) connectés par
un réseau universitaire (LIP6), dont voici les caractéristiques :
1. Pentium III à 1 gigahertz avec 1 gigaoctet de mémoire vive sous Windows Server
2002
2. Pentium IV à 2,6 gigahertz avec 512 megaoctets de mémoire vive sous Windows XP
3. Pentium III à 1,5 gigahertz avec 256 megaoctets de mémoire vive sousWindows XP
Les résultats obtenus ne sont bien sûr pas entièrement représentatifs puisqu’ils ont été
obtenus dans un environnement extrêmement simplifié. Cependant, ils donnent une ap-
proximation des différentes caractéristiques que pourrait avoir le système, s’il était im-
planté dans une situation réelle. Nos agents Tasks sont de trois types différents, au sens
ou ils n’ont pas exactement les mêmes treillis de préférence.
La figure 6.2 représente l’architecture de la version simplifiée de notre application.
6.1.4 Résultats
Ces tests ont été réalisés en deux temps, nous avons d’abord lancé quatre agents sur
chacun des ordinateurs, ce qui nous a permis de constater que, de façon surprenante, les
deux premiers ordinateurs étaient environ deux fois plus rapides que le troisième pour nos
agents Tasks. Nous avons d’abord lancé quatre agents Tasks sur chaque ordinateur de
façon statique (c’est-à-dire en interdisant leurs migrations). Les quatre tâches terminaient
après environ vingt minutes sur la machine la plus lente contre dix sur les plus rapides.
164
6.1. Le prototype de plateforme
Fig. 6.2 – L’architecture de la plateforme de test
Nous avons ensuite relancé les mêmes tests mais en ne lançant aucun agent Task sur la
machine 2 et en permettant la migration des agents. Ainsi, deux cinquièmes de la puissance
de calcul totale du système n’était donc plus utilisés. La machine 3 s’est débarrassée de ses
agents Tasks vers la machine 1 qui était déjà surchargée (car c’est la meilleure machine et
qu’elle était libre lors du dernier passage d’un agent Sniffer). La machine 1 s’est trouvée
complètement surchargée mais les agents surnuméraires ont alors migré vers la machine
2 qui était libre. Une distribution de charge concertée (centralisée, par exemple) aurait
évité cette migration inutile de 3 vers 2 mais dans notre cas, ces améliorations étaient
hors de portée puisque les agents travaillent sur des données obsolètes. Cette migration
inutile a pris entre 20 et 40 secondes aux trois agents concernés. Malgré cela les gains ont
été très importants (voir Figure 6.3).
La figure 6.2 représente l’architecture de la version simplifiée de notre application.
Il faut noter que, lors de nos tests, les agents, ayant tous le même treillis de description
de préférence, migrent tous vers la même destination. Il est probable que cela reste le cas
si les agents ont des treillis légèrement différents. Cette migration "en troupeau" n’est pas
très efficace car le site destination risque d’être immédiatement surchargé. Il faudra donc
envisager que les agents se concertent pour ne pas tous migrer vers la même destination
car ce comportement nuit à tous les agents et au système en général. De plus, nous
préconisons, pour la suite, d’introduire un mécanisme d’autorisations et de réservations
qui pourraient permettre aux agents d’éviter des migrations inutiles.
165
Fig. 6.3 – résultats des tests de la plateforme
6.2 Validation du fonctionnement du module de choix

des Managers
Pour valider le module de choix des Managers, nous avons construit un Manager
auquel nous avons donné des listes de Sites à évaluer. Il ne devait conserver que les dix
meilleurs. Pour prendre en compte un éventuel “raz-de-marée” de descriptions de sites,
nous avons placé des limites de temps de traitement de chaque variable. Cela explique
certains résultats.
6.2.1 Implantation
Nous avons utilisé Java pour construire un module de classement et de chiffrage de
sites. L’utilisation de Java se justifiait puisque la plateforme doit être construite en Java.
Nous avons construit notre module en suivant l’architecture décrite dans le chapitre sur
les Managers. Il faut cependant noter que pour introduire des erreurs (comme celles
qui pourraient intervenir si le Manager n’a plus le temps de traiter complètement les
descriptions qui lui sont envoyées), nous avons décidé de placer une limite de temps pour
l’évaluation de chaque ordinateur tout en lançant en parallèle les évaluations selon les
différents critères. Ainsi, il arrive régulièrement que certains critères n’aient pas eu le
temps d’être évalués. Les résultats obtenus sont donc sans doute inférieurs à ce qu’ils
auraient été si nous avions testé le système dans des conditions moins difficiles, cependant
166
6.2. Validation du fonctionnement du module de choix des Managers
il semblait préférable de tester la robustesse du système dans des situations difficiles.
6.2.2 Difficultés des tests

Vérifier la validité du module de sélection des ordinateurs présente plusieurs difficultés,
la première desquelles tient dans l’instantanéité du choix d’une description. Ce problème
peut être décrit simplement en rappelant que le module de sélection des relations juge
une description en fonction des besoins instantanés de la plateforme. Ainsi si l’une des
catégories d’ordinateur est “sous représentée” dans la liste de connaissance, la valeur at-
tribuée aux descriptions répondant au mieux à ses critères est largement augmentée. Or
juger chaque choix à l’instant où il a été réalisé n’est pas très utile puisque ce qui nous
intéresse c’est de savoir si les choix réalisés sont bons sur le long terme.
6.2.3 Génération des descriptions

Nous avons donc décidé de juger les résultats obtenus après que le système ait reçu un
certain nombre de descriptions (100 ou 1000 selon les cas) et nous avons décidé de juger
les résultats obtenus a posteriori. Nous avons donc construit un générateur de descriptions
aléatoires qui construit cinq descriptions aléatoires puis améliore certaines variables de la
description de façon récursive. Nous savons donc que si nous ne prenons en compte que
les descriptions construites à partir d’une description originale, les meilleures descriptions
selon un critère sont aussi meilleures selon les autres critères. On crée ainsi autant de
descriptions que de tests puis on envoie au module de choix ces descriptions dans un
ordre aléatoire.
6.2.4 Les différents types d’ordinateurs sélectionnés

Nous avons décidé de construire différents modèles d’ordinateurs désirables pour pou-
voir tester notre système, les ordinateurs choisis sont les suivants :
– La description d’ordinateurs dite “ordinateurs de calcul” (figure 6.4) favorise les
ordinateurs ayant une grosse puissance de calcul (ici incarnée par le processeur),
une grosse capcaité de mémoire pour pouvoir stocker des valeurs intermédiaires (le
disque pouvant légèrement compenser une absence de mémoire). Il faut aussi que le
site soit très peu encombré puisque les agents envoyés sur ce type de site recherche
de la puissance de calcul.
– La description d’ordinateurs dite “Clusterer” (figure 6.5) est destinée à servir de
“serveur” à un semblant de cluster d’ordinateurs de calculs, il exige donc une adresse
statique (pour être facilement retrouvable), un excellent réseau puisque les agents
Tasks repasseront par lui entre leurs différentes opérations et un processeur suffisant
pour qu’ils puissent être redirigés rapidement. Enfin, il faut qu’il ait un excellent
réseau de connaisances d’ordinateurs spécialisés dans le calcul.
– La description de la figure 6.6 est en fait destinée à aider au placement de tâches
qui fonctionneraient très bien sur un ordinateur personnel semblable au mien mais
que pour des raisons diverses (par exemple parce que j’utilise mon ordinateur dans
un autre but) doivent être distribuées.
167
Fig. 6.4 – Description d’ordinateur destiné à faire des calculs lourds
Fig. 6.5 – Description d’ordinateur destiné à servir de “serveur” à un cluster d’ordinateurs

semblables
168
6.2. Validation du fonctionnement du module de choix des Managers
Fig. 6.6 – description d’ordinateur semblable à “mon PC personnel”
– La description d’ordinateurs dite “Service acces provider” (figure 6.7) est destinée
à favoriser les sites ayant un carnet d’adresse très divers. Ces sites peuvent être de
bons points de départ pour une recherche plus spécifique. Ils doivent donc avoir une
bonne connexion réseau puisque ils sont destinés à être des points de transit, un
bon réseau de relations (différent de celui du clusterer en ce que celui-ci est très
diversifié alors que celui du clusterer est très spécialisé) et une adresse statique pour
être facilement retrouvé.
Ces différentes descriptions présentent une gamme relativement large d’ordinateurs
désirables. Cependant, il faut noter que le choix des modèles est le fait de l’auteur et
n’est là qu’à but de test. D’autres modèles peuvent bien sûr être construits et d’autres
descriptions seraient sans doute meilleures que celles-ci.
6.2.5 Les résultats obtenus

Nous avons réalisé soixante simulations avec cent descriptions d’ordinateurs et trente
simulations de mille descriptions, nous présentons ici les résultats obtenus aux cours de
deux de ces simulations dont les résultats se trouvaient dans la moyenne de leur catégorie.
La figure 6.8 présente les résultats d’une simulation de cent descriptions alors que la figure
6.9 présente les résultats d’une simulation de mille tests. Nous pouvons noter que les
résultats obtenus lors des “grandes” simulations (mille descriptions) sont en pourcentage
169
Fig. 6.7 – Description d’ordinateur destiné à service de point de départ pour la recherche
spécifique d’autres ordinateurs spécialisés
sensiblement meilleures que les plus petites. La courbe représente la qualité des ordinateurs
selon la puissance du processeur, les colones représentent les descriptions qui font partie
de la liste des connaissances à la fin de la simulation.
Fig. 6.8 – Résultats des tests de la plateforme pour 100 simulations
170
6.3. Quelques données probabilistes concernant notre système
Fig. 6.9 – Résultats des tests de la plateforme pour 1000 simulations
Les deux simulations dont nous fournissons les résultats ici montrent l’efficacité du sys-
tème même dans le cas de situations extrêmes. Nous constatons que même si le système
ne traite complètement que la moitié des cas, les résultats sont bons, les ordinateurs
sélectionnés après des séries de tests font toujours partie des meilleurs. Les résultats obte-
nus nous permettent de considérer que la modélisation que nous utilisons pour construire
notre module de choix reste robuste, même dans des conditions difficiles.
6.3 Quelques données probabilistes concernant notre

système
Nous allons maintenant tenter de montrer la validité de notre modèle. Contrairement

aux algorithmes de recherche des systèmes de partages de données peer-to-peer dont on
peut calculer les caractéristiques de façon théorique, notre système ne peut être décrit
qu’en termes probabilistes. Que ce soit en terme de recherche de données ou de choix de
relation, la couverture de l’espace entier par les Sniffers est un cas atteignable (et donc
le pire cas possible). Cependant, nous avons calculé différentes valeurs probabilistes du
système. Il faut cependant noter qu’il est difficile de représenter les caractéristiques de
l’heuristique de recherche que constituent les préférences des Sniffers et celles des Ma-
nagers. Pour représenter le réseau de connaissances des Managers, nous avons opté pour
considérer que les Managers dont les préférences sont semblables forment des “commu-
nautés” dans la communauté. Ces sous-ensembles ne forment pas une partition (certains
sites auront des préférences de plusieurs types), mais en général, nous considérons que les
sites partagent des ressources similaires à celles qu’ils recherchent.
171
6.3.1 Construction de l’architecture de partage

Nous avons d’abord tenté de calculer le temps nécessaire à la construction du réseau
de relations de chaque Manager. Ce qui permet de mesurer la durée de construction d’un
système de partage structuré (selon l’intérêt des différents utilisateurs) à partir de liens
créés au hasard, c’est-à-dire la construction du réseau peer-to-peer.
Soient :
T : le nombre de centres d’intérêt
Dans les parties précédentes, nous ne prenions en compte que du partage de puissance
informatique, donc les centres d’intérêts étaient les types d’ordinateurs recherchés par les
différents Managers. Comme dans cette partie, nous considérons un système de partage
générique, nous utilisons le terme “centre d’intérêt” car les ordinateurs peuvent être classés
selon la nature des fichiers qu’ils partagent, ou selon d’autres critères. Cependant, comme
un ordinateur répond à un centre d’intérêt s’il partage des ressources correspondant à ce
centre d’intérêt, nous utiliserons indifféremment type d’ordinateurs ou centre d’intérêt.
t1 . . .tT : le cardinal de chaque centre d’intérêt divisé par le cardinal de l’ensemble des Sites
Il faut noter que les types ne sont pas des ensembles disjoints. Normalement, l’apparte-
nance d’un Site à un type est graduelle mais nous considérerons ici qu’un Site appartient
à un type s’il est dans les meilleurs r pourcents selon les critères de ce type.
N1 : le nombre de Sniffers
N2 : le nombre de Sites
m : la durée d’une migration de Sniffer
Ms : la taille limite de la mémoire d’un Sniffer
Mm : la taille limite de la mémoire d’un Manager
Cm : le temps nécessaire pour qu’un Manager classe un Site
Cs : le temps nécessaire pour qu’un Sniffer classe un Site
Q(i, s) : la qualité du Site s jugé selon les critères du ieme type
(ramenée à la qualité moyenn des Sites)
Pour un Site N , en considérant un système tour par tour, avec un pas de Cs + Cm + m,
à chaque tour, on a :
1 N1
P (“aucun Sniffer présent sur N ”) = (1 − ) (6.1)
N2
La probabilité d’en avoir au moins 1 est donc :
1 N1
P (“au moins 1 Sniffer présent sur N ”) = 1 − (1 − ) (6.2)
N2
Nous calculons maintenant le nombre de “tours” nécessaires pour que la probabilité de
la proposition “au moins un Sniffer est passé par notre site” soit d’au moins 0,95 :
ln(0, 95)
k= (6.3)
ln(1 − (1 − N12 )N1 )
Dans le cas où un Sniffer est présent, il connait, en moyenne, ti × M2s sites répondant
aux critères du type recherché préférentiellement par N . Dès lors, en considérant que le
172
6.3. Quelques données probabilistes concernant notre système
nombre de sites est grand, on peut considérer que 95 % du réseau de connaissance des
sites du même type ti est construit après :
k × Mm
n= (6.4)
ti × M2s
Il faut noter que n et k sont des entiers, il faut donc arrondir les résultats obtenus.
la progression obtenue est en o(n) du nombre de sites et s’améliore en o(n) du nombre
de Sniffers, cependant ce n’est qu’un calcul probabiliste et nous avons considéré que les
Sniffers suivaient des trajectoires aléatoires. Nous n’avons pas non plus pris en compte le
fait que le retour de l’un Sniffer provenant du site étudié peut entraîner une amélioration
très rapide des connaissances de ce site. Enfin, la structuration du système accélère les
recherches donc les dernières recherches devraient être beaucoup plus rapides. En effet,
n’importe quel site indexé connait nécessairement des sites inconnus du site étudié et,
puisque leurs intérêts sont proches ces sites sont normalement intéressants.
6.3.2 Estimation d’une requête

Nous nous sommes ensuite arrêtés sur le temps de réponse à une requête. Il faut noter
que, comme précédemment, ces résultats sont probabilistes et qu’il est très difficile de
prendre en compte l’heuristique de recherche représentée par la structure et les préférences
de l’agent. Pour pouvoir les estimer, il serait nécessaire d’avoir des résultats à une certaine
échelle.
Dans ce qui suit, nous avons consédéré qu’un utilisateur recherchait une ressource
d’un type qu’il recherche préférentiellement. C’est une hypothèse raisonnable puisque
l’utilisateur choisit le type de sites qu’il indexe en fonction de ses besoins.
Soit :
ti : l’ensemble des sites concerné par la recherche
On considérera que ti est l’une des communautés constitués de sites ayant des intérêts
semblables.
R : l’ensemble des sites possédant la ressource recherchée
On considérera que R ⊆ ti .
N : Card(ti )
pr : Card(R)
On supposera que la ressource recherchée existe au sein de la communauté d’intérêt.

Dès lors, on a : le site M a une probabilité de (1 − pr
N
)Nm de connaître au moins un site
contenant la ressource. Dès lors, puisque chaque site que le Sniffer traverse a autant de
chance d’indexer un site qui possède la ressource recherchée, la probabilité d’avoir trouvé
la ressource après la nième migration est de : (1 − pr
N
)Nm ×n
Cet exemple ne prend pas en compte l’intérêt de la ressource recherchée, seulement le

fait qu’elle peut être associée à un type de sites. En effet, si la ressource est capitale pour
le type de sites (cela signifie qu’elle est courante pour ce type de sites même si elle ne l’est
pas en général, un ordinateur doté d’un bon réseau de connexion devrait la trouver en au
173
plus deux migrations (une migration vers un site possédant une bonne connaissance des
ordinateurs de ce type et un saut vers l’un de ces ordinateurs).
Il est plus difficile d’évaluer le nombre de migrations néceesaire pour trouver une
ressource caractéristique d’un type d’ordinateurs différent de ceux connus par le Manager
demandeur. En effet, il peut être difficile de trouver un groupe de sites, s’il n’existe pas
assez de Managers recherchant à doter leur site d’un carnet d’adresses très diversifié. Ces
Managers “généralistes” peuvent eux-mêmes être considérés comme un type de site et la
connaissance recherchée comme une ressource.
6.3.3 Propagation de l’information concernant les variations des

sites
Finalement, nous avons tenté de mesurer le temps nécessaire à la propagation de
la connaissance au sein de l’architecture : si les caractéristiques d’un site changent, les
connaissances des autres sites sur ce dernier sont remises à jour par les Sniffers.
174
Cinquième partie
Conclusion
175
Le premier point à noter est que notre problématique : minimiser le coût en commu-
nication de l’informatique partagée à large échelle est un enjeu important. En effet, M.
Ripeanu et al. [RFI02] montrent rapidement que les systèmes de partage P2P peuvent
modifier en profondeur le modèle économique de l’Internet des particuliers et qu’il est
nécessaire de minimiser les communications, non pas seulement du point de vue de l’op-
timisation du réseau mais aussi du point de vue de l’intérêt financier de tous les acteurs.
Cependant pour arriver à ce but, il reste certaines étapes importantes à franchir :
Notre plateforme de partage présente quelques défauts importants. D’abord, son uti-
lisation exige qu’il soit simple de construire les treillis des préférences des agents mais
il faut aussi que le système s’adapte aux réalités de son environnement. En effet, non
seulement les sites partagés évoluent au même rythme que les technologies informatiques
mais la qualité des machines partagées peut aussi suivre des cycles temporels beaucoup
courts (selon l’heure, les ordinateurs sont allumés ou éteints occupés ou non. . . ) il faut
donc non seulement prendre en compte les évolutions à terme (c’est pour cela que nous
envisageons d’utiliser les outils de la programmation génétique) et les évolutions immé-
diates qui exigeront un outil d’apprentissage beaucoup plus simple qui serait intégrer dans
chacun des agents Managers. Il faut éviter de “gonfler” les agents migrants car il ne faut
pas consommer les ressources informatiques que l’on désire partager. Il faut aussi noter
que le “réseau” virtuel constitué par les machines partagées est lui-même un important
sujet d’analyse. En effet, s’il est intéressant de modéliser et d’analyser sa topologie en soi
(comme dans le cas des études concernant les topologies des autres systèmes de partage
[CLL02]) ; dans notre cas, ce type d’analyse “topographique” a des utilisations immédiates
réelles : une bonne connaissance de la topographie du réseau peut permettre aux utili-
sateurs d’envoyer leurs agents Tâches directement dans des zones efficaces où même de
préparer leurs migrations en fonction des évolutions prévisibles du réseau au cours du
temps.
Pour pouvoir éventuellement envisager une utilisation plus proactive que réactive du
système de partage, il est nécessaire de disposer des informations nécessaires à la construc-
tion d’une bonne représentation du réseau des sites partagés.
Cependant cela ne suffit pas, il faut aussi disposer d’outils d’analyse et de représenta-
tion adaptés.
Ce sont des conditions plus difficiles à remplir qu’il n’y paraît. Les connaissances des
agents Sniffers sur les ordinateurs qu’ils ont visités peuvent être lacunaires, datées ou
simplement fausses s’ils ont été induits en erreur par un agent Manager. Il faut de plus
que les agents Sniffers réussissent à revenir jusqu’à leur hôte original pour que l’on puisse
étudier les données qu’ils ont récoltées. Il faut de plus appliquer un outil d’analyse de
données adaptées et réussir à tirer des conclusions de l’analyse réalisée automatiquement.
Cependant les données récoltées par les Sniffers sont des données complexes, très diverses,
sans compter qu’elles peuvent être différentes selon le Sniffer qui les a récoltées.
Notre système de partage diverge des systèmes peer-to-peer classiques en ce que les
sites utilisateurs choisissent eux-mêmes leurs “accointances”. Même si les liens entre les
sites ne sont pas bidirectionnels, il devrait se former des “amas de sites ayant des intérêts
communs. En effet, si un site satisfait à mes besoins cela peut signifier que son propriétaire
a des besoins semblables aux miens. . . nous devrions donc avoir des ensembles de sites
connus semblables ou complémentaires. Si nous atteignons effectivement une structure de
177
réseau semblable à un super réseau de clusters virtuels eux-mêmes largement distribués,
l’efficacité de l’ensemble du système devrait être largement améliorée. C’est ce qu’Adriana
Iamnitchi et al. ont montré dans [IRF02].
Il va aussi être nécessaire de juger les Sniffers de façon à pouvoir leur appliquer des
méthodes évolutives pour leur permettre de rester efficaces dans un milieu en perpétuelle
évolution. Pour cela, il va être nécessaire d’appliquer les méthodes de la programmation
génétiques aux treillis de préférences de nos agents.
Il sera aussi nécessaire d’accentuer les liens entre notre plateforme de partage et notre
méthodologie de conception. En effet, il faut aider les concepteurs à concevoir des appli-
cations capables de profiter des technologies de partages ou de modifier les applications
existantes de façon à pouvoir en profiter. Il serait de plus intéressant de construire les
passerelles avec les plateformes de services Web, puisque la problématique de mise en
commun des ressources logicielles n’est pas très différente.
178
Bibliographie
[ABD+ 01] G. Allen, W. Benger, T. Dramlitsch, T. Goodale, H.-C. Hege, G. Lanfer-

mann, A. Merzky, T. Radke, E. Seidel, and J. Shalf. Cactus tools for grid
applications. Cluster Computing, 4(3) :179–188, 2001.
[AC96] M. Abadi and L. Cardelli. A Theory of Objects. MONOGRAPHS IN COM-
PUTER SCIENCE, 1996.
[ADSV03] S. Agrawal, J. Dongarra, K. Seymour, and S. Vadhiyar. Making the Global
Infrastructure a Reality, chapter NetSolve : Past, Present, and Future - A
Look at a Grid Enabled Server. Wiley Publishing, 2003.
[AG91] Ishfaq Ahmad and Arif Ghafoor. Semi-distributed load balancing for mas-
sively parallel multicomputer systems. IEEE Transactions on Software En-
gineering, 17(10), 1991.
[AH00] E. Adar and B. Huberman. Free riding on gnutella. Technical report, Xerox
PARC, 2000.
[AW98] H. Attaiya and J. Welch. Distributed Computing. Mc GrawHill, 1998.
[Bac95] Leila Baccouche. Un mécanisme d’ordonnancement distribué de tâches temps
réel. PhD thesis, INPG LGI, 1995.
[BCC+ 01] F. Berman, A. Chien, K. Cooper, J. Dongarra, I. Foster, D. Gannon,
L. Johnsson, K. Kennedy, C. Kesselman, J. Mellor-Crummey, Dan Reed,
L. Torczon, and R. Wolski. The grads project : Software support for high-
level grid application development. The International Journal of High Per-
formance Computing Applications, 15(4) :327–344, 2001.
[BDG+ 91] A. Beguelin, J. J. Dongarra, G. A. Geist, R. Manchek, and V. S. Sunderam.
Heterogeneous network computing. pages 94–99, 1991.
[BF96] G. Bernard and B. Folliot. Caractéristiques générales du placement dyna-
mique : synthèse et problématique. In Placement dynamique et répartition
de charge : application aux systèmes parallèles et répartis, pages 3–22, Pres-
qu’île de Giens, 1996. INRIA, INRIA.
[BFG+ 00] Ron Brightwell, Lee Ann Fisk, David S. Greenberg, Tramm Hudson, Mike
Levenhagen, Arthur B. Maccabe, and Rolf Riesen. Massively parallel com-
puting using commodity components. Parallel Computing, Elsevier, 26 :243–
266, 2000.
[BHRS98] J. Baumann, F. Hohl, K. Rothermel, and M. Straßer. World Wide Web,
volume 1, chapter Mole - Concepts of a Mobile Agent System, pages 123–
137. 1998.
179
Bibliographie
[BLH99] K. S. Barber, T. H. Liu, and D. C. Han. Agent-oriented design. In LNAI :

Proceedings of MAAMAW’99. Elsevier, 1999.
[Bor02] John Borland. Stealth p2p network hides inside kazaa. news.com, 2002.
[BP97] E. A. Billard and J. C. Pasquale. Load balancing to adjust for proximity
in some network topologies. Parallel Computing, Elsevier, 22 :2007–2023,
1997.
[Bra85] J. G. Brachman, R. J. ; Schmolze. An overview of the kl-one knowledge re-
presentation system. cognitive science. JESA Modelling of Reactive Systems,
9 :171–216, 1985.
[BSDLS00a] M. N. Bouraqadi-Saâdani, R. Douence, T. Ledoux, and M. Südholt. Un mo-
dèle de mobilité forte en java. Technical report, Ecole Nationale Supérieure
des Techniques de l’Industrie des Mines de Nantes, Nantes, 2000.
[BSDLS00b] M. N. Bouraqadi-Saâdani, R. Douence, T. Ledoux, and M. Südholt. Une
infrastructure réflexive pour la mobilité forte en java. Technical report, Ecole
Nationale Supérieure des Techniques de l’Industrie des Mines de Nantes,
Nantes, 2000.
[BSV03] R. Bhagwan, S. Savage, and G. M. Voelke. Overnet : Understanding avai-
lability. In Proceedings of the 2nd International Workshop on Peer-to-Peer
Systems, 2003.
[BZW98] Walter Brenner, Rüdiger Zarnekow, and Harmut Wittig. Intelligent Software
Agents, Fondations and Applications. Springer-Verlag, Berlin, Heidelberg,
New York, 1998.
[Car99] Luca Cardelli. Abstractions for mobile computation, in secure internet pro-
gramming : Security issues for mobile and distributed objects. Lecture Notes
in Computer Science, Springer, 1603 :51–94, 1999.
[CG89] N. Carriero and D. Gelernter. How to write parallel programs : a guide to
the perplexed. ACM Computing Surveys, 21(3) :323–357, 1989.
[CG98] Luca Cardelli and A.D. Gordon. Foundations of Software Science and Com-
putational Structures, volume 1378 of Lecture Notes in Computer Science,
chapter Mobile Ambients, pages 140–155. Springer, 1998.
[CHK94] David Chess, Colin Harrison, and Aaron Kershenbaum. Mobile agents : Are
they a good idea ? Web page, 1994.
[CLL02] J. Chu, K. Labonte, and B. Levine. Availability and locality measurements
of peer-to-peer file systems. In Proc. ITCom : Scalability and Traffic Control
in IP Networks II Conferences, Proceedings of SPIE, volume 4868, 2002.
[COR] CORBA. Integrating mobile agent technology and corba.
[Cyb89] G. Cybenko. Dynamic load balancing for distributed memory multiproces-
sors. Journal of Parallel and Distributed Computing, 7(2) :279 – 301, 1989.
[D.02] Laforenza D. Grid programming : Some indications where we are headed.
Parallel Computing, North-Holland Elsevier, 28(12) :1701–1720, 2002.
180
[DDTV99] A. Delhay, M. Dauchet, P. Taillibert, and P. Vanheeghe. Maximization of
the average quality of anytime contract algorithms over a time interval.
In Proceedings of the Sixteenth International Joint Conference on Artificial
Intelligence, pages 212 – 221. Morgan Kaufmann Publishers Inc, 1999.
[Dea98] Desaulniers and et al. fleet management and logistics, chapter A unified fra-
mework for deterministic time constraint vehicle routing and crew scheduling
problem, pages 57–93. Kluwer, Boston, 1998.
[DGMS93] Jack Dongarra, G. A. Geist, Robert Manchek, and V. S. Sunderam. Integra-
ted PVM framework supports heterogeneous network computing. Computers
in physics, 7(2) :166–174, 1993.
[DHS00] Stephen R. Donaldson, Jonathan M.D. Hill, and David B. Skillicorn. Bsp
clusters : High performance, reliable and very low cost. Parallel Computing,
Elsevier, 26 :199–242, 2000.
[DK01] Yuefan Deng and Alex Korobka. The performance of a supercomputer built
with commodity components. Parallel Computing, Elsevier, 27 :91–108,
2001.
[DMC96] Marco Dorigo, Vittorio Maniezzo, and Alberto Colorni. The ant system :
Optimization by a colony of cooperating agents. IEEE Transactions on
Systems, Man, and Cybernetics Part B : Cybernetics, 26(1) :29–41, 1996.
[DS01] M. Dorigo and T. Stützle. An experimental study of the simple ant colony.
Technical report, Université Libre de Bruxelles, Brussels, 2001.
[ea04] A. Montresor et al. Messor : Load-balancing through a swarm of autonomous
agents. In Springer-Verlag, editor, Proc. of AP2PC 2002, LNCS 2530, 2004.
[Edi00] Editorial. Parallel computing on clusters of workstations. Parallel Compu-
ting, Elsevier, Parallel Computing, Elsevier :175–177, 2000.
[ESA96] Elfallah-Seghrouchni and S. A., Haddad. A recursive model for distributed
planning. In Proceedings of ICMAS’96. AAAI Press, 1996.
[ESHH01] Taylor E., Eric J. Schwabe, Bruce K. Holmer, and Michelle R. Hribar. Ba-
lancing load versus decreasing communication : Parameterizing the tradeoff.
Journal of Parallel and Distributed Computing, 61(5) :567–580, 2001.
[Ev96] P. Eck van. The desire research program. Technical report, 1996.
[FCM03] C. J. Freitas, D. B. Coffin, and R. L. Murphy. The characterization of a
wide area network computation. Parallel Computing, Elsevier, 29 :879–894,
2003.
[Fen01] Serge Fenet. Vers un paradigme de programmation pour les applications
distribuées basé sur le comportement des insectes : application à la sécurité
des réseaux. PhD thesis, LISI, 2001.
[Fer95] J. Ferber. Les systèmes multi-agents, vers une intelligence collective. Inter-
Editions, 1995.
[FG01] G. C. Fox and D. Gannon. Computational grids. IEEE Comput Sci Eng.,
3(4) :74–77, 2001.
181
Bibliographie
[FIP98] FIPA. Fipa 98 draft specification : Part 11 : Agent management support for
mobility. Technical Report 8415, Version 0.3, FIPA, 1998.
[FIP01] FIPA. Fipa agent software integration specification. Technical report, FIPA,
2001.
[FK] I. Foster and C. Kesselman. The globus project : a statuts report. Web
page.
[FK99] I. Foster and C. Kesselman. The Grid : Blueprint for a Future Computing
Infrastructure. Morgan, Kaufmann, 1999.
[FKNT02] I. Foster, C. Kesselman, J. M. Nick, and S. Tuecke. Grid services for distri-
buted system integration. Computer, 35(6), 2002.
[FPR95] B. Folliot, P.Sens, and P.-G. Raverdy. Calculateurs Parallèles, volume 7,
chapter Plateforme de Répartition de Charge et de Tolérance aux Fautes
pour Applications Parallèles en Environnement Réparti, pages 345–366. Her-
mès, 1995.
[FSS03a] A. El Fallah-Seghrouchni and Alexandru Suna. Claim : A computational
language for autonomous, intelligent and mobile agents. In Proceedings,
ProMAS’03, workshop of AAMAS, Melbourne, Astralia, 2003. ACM Press.
[FSS03b] A. El Fallah-Seghrouchni and Alexandru Suna. An united framework for
programming autonomous, intelligent and mobile agents. In Proceedings,
CEEMAS’03. Springer-Verlag, 2003.
[GAD+ 94] A. Geist, A.B., J. Dongarra, W. Jiang, R. Manchek, and V.S. Sunderam.
PVM : Parallel Virtual Machine : A Users Guide and Tutorial for Network
Parallel Computing. The MIT Press, 1994.
[GBL+ 03] I. Gupta, K. Birman, P. Linga, A. Demers, and R. van Renesse. Kelips :
Building an efficient and stable p2p dht through increased memory and
background overhead. In Proceedings of the 2nd International Workshop on
Peer-to-Peer Systems, 2003.
[Gea02] D. Gannon and et al. Programming the grid : Distributed software compo-
nents, p2p and grid web services for scientific applications. Cluster Compu-
ting, 5(3) :325–336, 2002.
[GFGRA98] E. Giménez-Funes, L. Godo, and J. Rodriguez-Aguilar. Designing bidding
strategies for trading agents in electronic auctions. In Proceedings of IC-
MAS’98 : the Third International Conference on Multi-Agent Systems. ACM
Press, 1998.
[Gib03] Steve Gibson. DCOMbobulator : Effortlessly Tame Windows Dangerous
DCOM Facility. Gibson Reseach Corporation, 2003.
[HBDV03] K. Heinrich, M. Berry, J. Dongarra, and S. Vadhiyar. Statistical Data Mi-
ning and Knowledge Discovery, chapter The Semantic Conference Organizer.
CRC Press, 2003.
[HCF+ 94] D. Hagimont, P.Y. Chevalier, A. Freyssinet, S. Krakowiak, S. Lacourte,
J. Mossière, and X. Rousset de Pina. Persistent shared object support
182
in the guide system : Evaluation and related work. In Proceedings of the
Ninth Annual Conf. on Object-Oriented Programming Systems, Languages,
and Applications, volume 29, pages 129–144, Portland OR (USA), 1994. ci-
teseer.nj.nec.com/chevalier94persistent.html.
[HJS+ 03] N. Harvey, M. Jones, S. Saroiu, M. Theimer, and A. Wolman. Skipnet : A
scalable overlay network with practical locality properties. In Proceedings of
USITS 2003, 2003.
[HW98] Junling Hu and Michael P. Wellman. Online learning about other agents in
a dynamic multiagent system. In Katia P. Sycara and Michael Wooldridge,
editors, Proceedings of the 2nd International Conference on Autonomous
Agents (Agents’98), pages 239–246, 1998.
[HW01] J. Hu and M. P. Wellman. Learning about other agents in a dynamic mul-
tiagent system. Cognitive Systems Research (Elsevier), 2 :6779, 2001.
[IBM03] IBM. Aglets web page, 2003.
[IRF02] A. Iamnitchi, M. Ripeanu, and I. Foster. Locating data in (small-world ?)
peer-to-peer scientific collaborations. In LNCS 2429 : Proceedings of
IPTPS’02. Elsevier, 2002.
[Jen99] N. R. Jennings. Agent-oriented software engineering. In LNAI : Proceedings
of MAAMAW’99, volume 1647. Elsevier, 1999.
[JO98] Ferber J. and Gutknecht O. Aalaadin : a meta-model for the analysis and
design of organizations in multi-agent systems. In Proceedings of ICMAS’98.
ACM, 1998.
[JPS02] T. Juan, A. Pierce, and L. Sterling. Roadmap : extending the gaia metho-
dology for complex open systems. In Proceedings of AAMAS’02, pages 3–10,
Bologna, 2002. ACM Press.
[JZA+ 93] N. R. Jennings, L. Z.Varga, R. Aarnts, J. Fuchs, and P.Skarek. Transforming
standalone expert systems into a community of cooperating agents. Journal
of Engineering Applications of Artificial Intelligence, 6(4) :317–331, 1993.
[Kei01] Keidar. Group communication. Technical report, MIT Labs, 2001.
[KFST02] G. Klein, A. El Fallah-Seghrouchni, and P. Taillibert. Hamac : An agent
based programming method. In Proceedings of AAMAS’02, pages 47–48,
Bologne, 2002. ACM Press.
[KSFS04] G. Klein, A. Suna, and A. El Fallah-Seghrouchni. Resource sharing and load-
balancing based on agent mobility. In Proceedings of the 6th International
Conference on Entreprise Information Systems, Porto, 2004.
[KZ97] Joseph Kiniry and Daniel Zimmerman. Special feature : A hands-on look at
java mobile agents. IEEE Internet Computing, 1(4), 1997.
[Leb03] Marjorie Lebars. Systèmes multi-agents pour l’aide à la négociation lors du
partage de l’eau entre différents usagers. PhD thesis, LAMSADE - INRA,
Université Paris IX - Dauphine : Paris, 2003.
183
Bibliographie
[LO98] D. Lange and M. Oshima. The Aglet book “ Programming and Deploying
Java Mobile Agents with Aglets ”. Addison-Wesley, 1998.
[MAD] Madkit. Web page.
[MAS] Masif : The omg mobile agent system interoperability facility. Web page.
[Maz01] H. Mazouzi. Ingénierie des protocoles d’interaction : des systèmes distribués
aux systèmes multi-agents. PhD thesis, LAMSADE. 2001, Université Paris
IX - Dauphine : Paris., 2001.
[MBB+ 98] D. Milojicic, M. Breugst, I. Busse, J. Campbell, S. Covaci, B. Friedman,
K. Kosaka, D. Lange, K. Ono, M. Oshima, C. Tham, S. Virdhagriswaran,
and J. White. Masif, the omg mobile agent system interoperability facility,
1998.
[MBB 99] Dejan S. Milojicic, Markus Breugst, Ingo Busse, John Campbell, Stefan
+
Covaci, Barry Friedman, Kazuya Kosaka, Danny B. Lange, Kouichi Ono,

Mitsuru Oshima, Cynthia Tham, Sankar Virdhagriswaran, and Jim White.
Masif : The omg mobile agent system interoperability facility. Lecture Notes
in Computer Science, Springer, 1477 :50–67, 1999.
[MCC94] F. G. Mc Cabe and K. L. Clark. April - agent process interaction language,
1994.
[MEFSH02] H. Mazouzi, A. El Fallah-Seghrouchni, and S. Haddad. Open protocol design
for complex interactions in multi-agent systems. In Proceedings of AAMAS’
02. AAAI Press, 2002.
[Mic] Microsoft, Corps. .NET Technical Resources.
[Mic96] Microsoft, Corps. DCOM Technical Overview, 1996.
[MJK00] Wooldridge M., N. R. Jennings, and D. Kinny. The gaia methodology for
agent-oriented analysis and design. Journal of Autonomous Agents and
Multi-agent systems, 3(3) :285–312, 2000.
[ML99] Huhns M. and Stephens L. Multiagent systems and societies of agents. In
Weiss G., editor, Multiagent Systems, a Modern Approach to Distributed
Artificial Intelligence, pages 79–120. MIT Press, Massachusetts, 1999.
[MPI] MPICH-G2. MPICH-G2 : A Globus-enabled MPI.
[MS99] Mauro Migliardi and Vaidy S. Sunderam. Heterogeneous distributed vir-
tual machines in the harness metacomputing framework. In Heterogeneous
Computing Workshop, pages 60–72. 1999.
[MS00] Mauro Migliardi and Vaidy S. Sunderam. Active agents programming in
harness. In Proceedings of HPCN, pages 622–625, 2000.
[Mus00] Soraia Raupp Musse. Simulation of the human crowd based on the group so-
ciological and psychological behaviors (présentation de sujet de thèse). Tech-
nical report, ECOLE POLYTECHNIQUE FEDERALE DE LAUSANNE
(EPFL), Lausanne, 2000.
[NGA02] Amara-Hachmi N., Klein G., and El Fallah-Seghrouchni A. Vers une concep-
tion de systèmes multi-agents orientée communication et mobilité. In In
Proceedings of JFIADSMA’02, Lille, France, 2002. Hermès.
184
[OMG03] OMG. CORBA/IIOP Specification, 2003.
[Ore44] O. Ore. Galois connections. Trans. Amer. Math. Soc., 55 :494–513, 1944.
[Pic01] G. P. Picco. Mobile agents : An introduction. Journal of Microprocessors
and Microsystems, 25(2) :65–74, 2001.
[Puj02] Guy Pujolle. Les Réseaux. Eyrolles, 30 aout 2002 edition, 2002.
[RD85] H. O. Roux and A. M. Deplanche. A t-time petri net extension for real-time
task scedulling modelling. JESA Modelling of Reactive Systems, 36 :973–986,
1985.
[RFI02] M. Ripeanu, I. Foster, and A. Iamnitchi. Mapping the gnutella network :
Properties of large-scale peer-to peer systems and implications for system
design. IEEE Internet Computing Journal special issue on peer-to-peer net-
working, 6(1), 2002.
[RGI92] A. Rao, M. Georgeff, and F. Ingrand. An architecture for real-time reasoning
and system control. IEEE Expert, 7(6), 1992.
[Rhe01] H. Rheingold. The Virtual Community : Homesteading on the Electronic
Frontier, revised edition. MIT Press, 2001.
[Rip01] M. Ripeanu. Peer-to-peer architecture case study : Gnutella network. Tech-
nical report, University of Chicago, 2001.
[Set] Seti. Seti@home. Web site.
[SFS03] Alexandru Suna and Amal El Fallah-Seghrouchni. Programming e-commerce
applications in the claim language. In Proceedings, CSCS14, 2003.
[SIC03] SICS. SICStus Prolog, 2003.
[sita] AUML Web site. Auml web site. Web site.
[Sitb] SMALLTALK Web Site. Smalltalk web site. Web site.
[sitc] UML Web site. The current uml specification, version 1.5. Web site.
[SMK 01] +
I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan.
Chord : A scalable peer-to-peer lookup service for internet applications. In
Proceedings of ACM SIGCOMM ’01, pages 149–160, 2001.
[SS86] L. Sterling and E. Shapiro. The Art of Prolog. The MIT Press, Cambridge
MA, 1986.
[SSCJ98] O. Shehory, K. Sycara, P. Chalasani, and S. Jha. Agent cloning : An ap-
proach to agent mobility and resource allocation. IEEE Communications,
36(7) :58–67, July 1998.
[SST95] Andrea Schaerf, Yoav Shoham, and Mashe Tennenholtz. Adaptative load
balancing : a study in multi-agent learning. Journal of Artificial Intelligence
Research, 2 :475–500, 1995.
[Sun94] V. S. Sunderam. Methodologies and systems for heterogeneous concurrent
computing. pages 29–45, 1994.
[SUN04a] SUN. Ejb reference. WEB page, 2004.
185
Bibliographie
[SUN04b] SUN. Java RMI : Reference, Documentation, 2004.

[Syc88] K. Sycara. Utility theory in conflict resolution. Annals of operations research,
12(5) :p. 65–84, 1988.
[Syc89] K. Sycara. Multiagent compromise via negociation. In L. Gasser, editor,
Distributed Artificial Intelligence, pages p. 119–137. Morgan Kaufmann /
Pitman, 1989.
[Tan03] Andrew Tanenbaum. Réseaux. Pearson Education, 2003.
[Tel01] British Telecom. Zeus web page. Web document, 2001.
[TJvdM01] J. Treur, C. M. Jonker, and L. van der May. Component-based design of
intelligent multi-agent systems. Web page, 2001.
[TL89] M. M. Theimer and K. A. Lantz. Finding idle machines in a workstation-
based distributed system. IEEE Transactions on Software Engineering,
15(11) :1444– 1458, 1989.
[VEFS01] G. Vauvert and A. El Fallah-Seghrouchni. E-commerce agents. In Procee-
dings of the 2nd Intelligent Agent Technology, pages 355–356. World Scien-
tific Publishing Co., 2001.
[Wat00] John D. Watts. Parallel algorithms for coupled-cluster methods. Parallel
Computing, Elsevier, 26 :857–867, 2000.
[Wei99] G. Weiss. Multiagent systems : A Modern Approach to Distributed Artificial
Intelligence. MIT Press, 1999.
[Wil90] Rudolf Wille. Concept lattices and conceptual knowledge systems. Fachbe-
reich mathematik, Technische Hochschule Darmstadt, Darmstadt, 1990.
[WWHG] B. S. White, M. Walker, M. Humphrey, and A. S. Grimshaw. Legionfs : A
secure and scalable file system supporting cross-domain high-performance
applications. Technical report.
[Zha04] Yi Zhang. Bayesian Graphical Models for Adaptive Information Filtering.
PhD thesis, Carnegie Mellon University, 2004.
[Zhu00] Xiaotong Zhuang. Survey of the security aspects in mobile agent systems.
Technical report, Georgia Institute of Technology, Atlanta, 2000.
186

Systèmes Multiagents Distribués Et Systèmes Distribués Multiagents - Thèse Gilles Klein

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Systèmes Multiagents Distribués Et Systèmes Distribués Multiagents - Thèse Gilles Klein

Transféré par

Droits d'auteur :

Formats disponibles

U.F.

R des Sciences des Organisations

Systèmes Multiagents Distribués et

Doctorat de l’Université Paris IX Dauphine

Directeur : Madame Amal El Fallah-Seghrouchni

Laboratoire d’Analyse et Modélisation de Systèmes pour l’Aide à la Décision UMR 7024

Table des figures vii

Partie I Plan détaillé et Introduction 1

Partie II Systèmes multi-agents et informatique partagée : un

1.1 Architectures issues des systèmes distribuées . . . . . . . . . . . . . . . 15

2.1 Interactions, communications . . . . . . . . . . . . . . . . . . . . . . . . 53

3.1 Les réseaux sémantiques : . . . . . . . . . . . . . . . . . . . . . . . . . 59

Partie III Méthodologie de conception de systèmes multia-

2.1 Une présentation rapide de notre méthode de conception de SMA . . . 71

3.1 Un résumé rapide de la partie statique de notre méthode : HAMAC . . 77

4.1 Redistribution dynamique des charges : introduction de la mobilité . . 101

6.1 L’architecture des premières versions d’Arès . . . . . . . . . . . . . . . 111

Partie IV Notre système de partage de ressources 121

1.1 De ASMAA vers un outil de partage de ressources informatiques . . . . 123

2.1 Les communautés d’utilisateurs . . . . . . . . . . . . . . . . . . . . . . 127

4.1 Capacité d’un agent à juger de la qualité des services . . . . . . . . . . 143

5.1 Les agents Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

6.1 Le prototype de plateforme . . . . . . . . . . . . . . . . . . . . . . . . 161

Partie V Conclusion 175

2.1 Méthode de conception et implémentation de SMA . . . . . . . . . . . . . 72

4.1 Architecture de plate-forme conforme à MASIF [MAS] . . . . . . . . . . . 103

5.1 Notre modèle d’agent “le danseur de Maccarena” . . . . . . . . . . . . . . . 108

6.1 Représentation du processus de recherche et d’emprunt d’un ouvrage et de

3.1 Un exemple de “réseau câblé routé” . . . . . . . . . . . . . . . . . . . . . . 135

5.1 Un exemple de représentation de préférences par treillis de Gallois . . . . . 155

6.1 L’architecture de SyMPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Plan détaillé et Introduction

Croissance des besoins

utilisateurs souffrent régulièrement de la surcharge de leur système informatique. Cela

Technologies de partage de ressources informatiques

Dans ce chapitre, nous présentons différentes méthodes de représentations . . . de don-

La conception de systèmes multiagents distribués : HAMAC et ASMAA

Un système de partage à grande échelle basé sur les agents mobiles

Quelle clientèle pour un système de partage

Description des ressources partagées

Problèmes posés par un système de partage

Description du fonctionnement de la plateforme et état d’avancement du

Les tests et les résultats obtenus

Ces dernières années ont vu apparaître de multiples applications distribuées à grande

Systèmes multi-agents et informatique

Technologies de partage de ressources

1.1 Architectures issues des systèmes distribuées

1.1.1 Les solutions de distribution de charge

Les architectures de systèmes distribués

Les architectures de réseau

Les ordinateurs multiprocesseurs

Les systèmes en réseau

Les architectures abstraites

Fig. 1.2 – Exemples d’architectures classiques

Quelques modèles de systèmes de distribution de charge

Les architectures statiques et dynamiques

Les architectures statiques

Fig. 1.3 – Un exemple d’architecture hiérarchique

Les architectures de distribution de charge statiques suivent un schéma semblable assez

Les architectures dynamiques

Les caractéristiques des algorithmes de placement

algorithmes de placement de processus.

Les hypothèses classiques