Rapport de projet 2A

LIN Kaishin
SENG Alain
Promotion 2008
Rapport de projet 2A
Interception système pour
l’émulation d’applications
Correspondant école :
Phuong LE-HONG Responsables Loria : Lucas NUSSBAUM
Martin QUINSON

Rapport de projet 2A – Interception
Kaishin LIN et Alain SENG
Page 2 / 19
Introduction
Ce projet s’inscrit dans le cadre des projets de deuxième année du département
Information et Systèmes de l’Ecole des Mines de Nancy. Ces derniers ont pour
objectif d’initier à la gestion concrète d’un projet en groupe, mais également de
permettre aux élèves d’approfondir leurs connaissances dans un domaine technique
et scientifique qui ne serait éventuellement pas abordé en cours. Le projet se déroule
sur l’année scolaire 2009-2010 au sein de l’équipe AlGorille du Loria, et est encadré
par deux de ses membres M. Lucas NUSSBAUM et M. Martin QUINSON.

Rapport de projet 2A – Interception
Kaishin LIN et Alain SENG
Page 3 / 19
Table des matières
INTRODUCTION ................................................................................................................................................ 2
TABLE DES MATIERES ....................................................................................................................................... 3
I. GESTION DU PROJET...................................................................................................................................... 4
CONTEXTE.............................................................................................................................................................. 4
ENJEUX ................................................................................................................................................................. 4
CAHIER DES CHARGES INITIAL ..................................................................................................................................... 5
Objectifs ......................................................................................................................................................... 5
Fonctions attendues ...................................................................................................................................... 5
Critères d’évaluation et d’acceptabilité ......................................................................................................... 6
Contraintes et modalités de réalisation ......................................................................................................... 6
Echéancier ..................................................................................................................................................... 6
II. TRAVAUX REALISES ...................................................................................................................................... 7
DEVELOPPEMENT D’APPLICATIONS DISTRIBUEES ............................................................................................................ 7
INTERCEPTION : LES AGENTS JAVA .............................................................................................................................. 8
Le contexte..................................................................................................................................................... 8
Les objectifs fonctionnels et techniques ........................................................................................................ 9
Les moyens disponibles ................................................................................................................................ 10
ADAPTATION AVEC SIMGRID ................................................................................................................................... 11
III. DIFFICULTES RENCONTREES ...................................................................................................................... 13
DIFFICULTES AU COURS DES REALISATIONS .................................................................................................................. 13
DIFFICULTES SUR LA GESTION DE PROJET .................................................................................................................... 13
CONCLUSION .................................................................................................................................................. 15
ANNEXES ........................................................................................................................................................ 16
A. LES DIFFERENTES APPLICATIONS DISTRIBUEES DEVELOPPEES ....................................................................................... 16
La classe Message ....................................................................................................................................... 16
Intérêt du multithreading ............................................................................................................................ 16
Ping-pong : le modèle du Client/Serveur ..................................................................................................... 17
Token Ring : structure en anneau ................................................................................................................ 17
All-to-All ....................................................................................................................................................... 17
Scatter-Gather ............................................................................................................................................. 17
B. COMPLEMENTS TECHNIQUES SUR L’INTERCEPTEUR ................................................................................................... 18
Le Manifest et le fichier jar .......................................................................................................................... 18
Le fichier Agent.java .................................................................................................................................... 18
ASM : ClassRenamer.java ............................................................................................................................ 19
Message.java et RealMessage.java............................................................................................................. 19

Rapport de projet 2A – Interception
Kaishin LIN et Alain SENG
Page 4 / 19
I. Gestion du projet
Contexte
La recherche dans de nombreux secteurs nécessite une puissance de calcul
croissante et, la mise en commun des ressources de plusieurs ordinateurs permet de
répondre à ce besoin. Malheureusement, l’écriture d’applications destinées à
fonctionner sur des systèmes distribués n’est pas simple. Les expérimentations jouent
un rôle crucial dans cette conception car les modélisations théoriques qui pourraient
décrire l’application sont, soit trop complexes pour être exploitables, soit trop
simplistes pour être réellement utiles.
Pour les expérimentations, deux possibilités s’offrent alors aux programmeurs :
- soit, ils effectuent leurs tests sur une plate-forme, copie conforme de celle où
sera installée l’application (achat de matériel en double)
- soit ils procèdent à des simulations.
Les inconvénients de la première solution sont de taille. Elle nécessite en effet
l’écriture préalable du programme complet avant de pouvoir procéder aux
expérimentations, ce qui rend ardue la comparaison entre les différentes solutions
possibles et dont on voudrait justement évaluer les avantages ou inconvénients
respectifs. De plus, cette solution pose des problèmes de reproductibilité : il est
difficile d’isoler une plate-forme réelle pour procéder aux expérimentations in situ et
les autres utilisateurs peuvent influer sur les résultats.
La simulation ne présente pas les problèmes énumérés ci-dessus mais nécessite
l’implémentation d’un prototype destiné à fonctionner sur le simulateur, puis une
réécriture de l’application destinée à fonctionner sur la plate-forme réelle (une fois le
prototype validé). Ecrire l’application deux fois représente une surcharge de travail
qui pourrait être évitée si on parvenait à effectuer des simulations directement à partir
de l’application réelle. Au cours de l’implémentation du prototype, des écueils divers
peuvent en outre surgir : situations de compétition (race condition), interblocages
(dead locks), famines, absence d’horloge centralisée et donc asynchronisme…
Enjeux
Le projet s’insère donc dans un axe de recherche visant à permettre la conduite
de simulations sans avoir à implémenter de prototype, d’où un gain de temps et de
fiabilité. Par exemple, la vérification d’absence de divergence entre le modèle et
l’application réelle n’aurait plus lieu d’être, éliminant une source potentielle
d’erreurs.
Les tests d’applications déjà existantes s’en trouveraient également facilités
puisque l’étape délicate de leur modélisation, pour laquelle il faut décortiquer le
fonctionnement et donc comprendre exactement le travail d’un tiers, ne constituerait
plus un écueil.

Rapport de projet 2A – Interception
Kaishin LIN et Alain SENG
Page 5 / 19
Cahier des charges initial
L’établissement du cahier des charges correspond à un jalon important de la
gestion de projet que nous avons établi début novembre. En plus des objectifs et d’un
descriptif des fonctions attendues, il comporte un échéancier qui s’est révélé au final
être assez éloigné de la réalité. Nous y reviendrons dans la partie III consacrée aux
problèmes rencontrés lors de la gestion de projet.
Objectifs
L’objectif est donc de permettre à des applications réelles de s’exécuter
directement dans un simulateur. Pour ce faire, il est nécessaire de :
1. Etudier les moyens d’intercepter les actions d’une application
2. Implémenter des exemples d’applications distribuées
3. Implémenter une méthode d’interception qui redirige les interactions avec
l’environnement vers le simulateur SimGrid
Fonctions attendues
Il existe différentes pistes pour intercepter les actions d’une application :
l’appel ptrace du debugger gdb, le détecteur d’anomalie valgrind, l’éditeur de liens
dynamiques (ldd) de linux, les agents utilisés dans Java. Dans le cadre du projet, on
ne s’intéressera qu’à cette dernière piste.
Il est demandé aux étudiants qu’ils développent quelques exemples
d’applications distribuées plus ou moins complexes en Java afin de disposer
d’exemples à tester intéressants par la suite.
En plus de pouvoir procéder simplement aux interceptions, le développement
de l’intercepteur doit prendre en compte la nécessité d’interagir avec le simulateur
SimGrid. Les interceptions réalisées devront lui permettre de simuler le temps de
calcul qu’il aurait fallu à une plate-forme réelle pour exécuter les instructions
demandées.
Fig.1 : Résumé des fonctions attendues
Développement d’applications distribuées à tester
Développement d’une méthode d’interception
Adaptation de l’intercepteur avec SimGrid
Test sur les applications