rapport de stage - merlet.iiens.netmerlet.iiens.net/stage/2a/rapport.pdf · minist`ere de...

Ministere de l’Education NationaleConservatoire National des Arts et Metiers

Institut d’Informatique d’Entreprise

Rapport de Stage

Routage de requetes optimise par apprentissagedans les architectures P2P

MERLET BenoıtStage de 2eme annee

Stage effectue au Departement Informatique de l’INT,du 1er juin 2005 au 23 aout 2005

Maıtre de stage : M. Bruno DEFUDE, membre de l’equipe Base de Donnees duDepartement Informatique de l’INT et responsable du projet RARE.

Table des matieres

1 Introduction - Le P2P 5

2 Cadre du stage 62.1 L’INT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Le Departement Informatique . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Environnement technique . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Environnement humain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Le sujet du stage 93.1 Le projet RARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.2 Les acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Le but du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Les outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 La bibliotheque JXTA . . . . . . . . . . . . . . . . . . . . . . . . . 123.3.2 Le simulateur PeerSim . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4 Calendrier du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Travail effectue 144.1 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.1 Fonctionnalites elementaires . . . . . . . . . . . . . . . . . . . . . . 144.1.2 La semantique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.1.3 Apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.4 Partage des connaissances . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Conception et modelisation . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.1 Principe de conception . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.2 Diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Le developpement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.1 Le simulateur basique . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.2 Les ajouts de fonctionnalites . . . . . . . . . . . . . . . . . . . . . 204.3.3 L’interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3.4 Ce qu’il reste a faire . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4 Les tests du simulateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1

TABLE DES MATIERES TABLE DES MATIERES

4.4.1 Tests nominaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.4.2 Montee en charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.5 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Conclusion 25

A Documentation de PeerSim 26

B Specification du protocole Gnutella 27

C Documentation du simulateur 28

2

Table des figures

2.1 Logos du GET et de l’INT . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Projet RARE : Qui fait quoi ? . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1 Diagramme UML principal . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Diagramme UML des protocoles . . . . . . . . . . . . . . . . . . . . . . . 174.3 Diagramme UML des dynamics . . . . . . . . . . . . . . . . . . . . . . . . 184.4 Diagramme UML des observers . . . . . . . . . . . . . . . . . . . . . . . . 184.5 Diagramme UML des types de base . . . . . . . . . . . . . . . . . . . . . . 194.6 La propagation des requetes dans Gnutella . . . . . . . . . . . . . . . . . 204.7 Vue d’ensemble de la GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3

Remerciements

Tout d’abord :– Je tiens a remercier Bruno DEFUDE, qui m’a permis de faire ce stage en tant que

developpeur dans le projet dont il est le responsable. Ce fut tres interessant detravailler sous sa direction.

– Je remercie egalement Jerome SICARD, stagiaire de DEA sur le meme projet, avecqui je partageais mon bureau et qui m’a fait decouvrir (et apprecier) un monderempli de meta-donnees, d’interpretations semantiques, de Bloom Filters et deGossiping.

– Merci a Brigitte HOUASSINE pour m’avoir simplifie le cote administratif, etm’avoir, a plusieurs reprises, permis de rentrer dans mon bureau.

– Enfin, je remercie mon co-stagiaire, Pierre ZUREK, qui m’a tenu studieusementcompagnie tout l’ete alors que les stagiaires de l’IIE qui avaient commence plustot se sont retrouves en vacances et nous envoyaient des cartes postales.

Mais aussi, et de facon moins formelle :– merci a l’INT d’etre situe pres de chez moi ;– merci a DELL pour nos nouvelles stations de travail ;– merci au babyfoot, pour nous avoir occupe lors des pauses dejeuner ;– merci a d’autres stagiaires de DEA, Christophe et Yacine, qui sonnaient la soupe

d’une facon toute particuliere ;– et un grand merci a tous les membres du Departement Informatique qui nous ont

magnifiquement accueillis.

4

Chapitre 1

Introduction - Le P2P

De nos jours, la tres grande majorite des proprietaires d’ordinateurs connaissent lePeer To Peer, pair a pair en francais, notamment grace au partage de fichiers sur In-ternet. De nombreux protocoles existent : KaZaa, eDonkey, eMule, Bittorrent, Gnutella,pour ne citer que les plus connus. Ils permettent pour la plupart, via un client adapte,de faire des recherches de fichiers sur le reseau P2P correspondant.

Le theme general de mon stage etait les reseaux P2P. Il s’est deroule au sein del’equipe Base de Donnees du Departement Informatique de l’Institut National des Tele-communications sous la direction de Bruno DEFUDE, le responsable du projet auquelj’ai pris part : le projet RARE (Routage par Apprentissage de REquetes). J’ai egalementbeneficie de l’aide de Jerome SICARD, stagiaire de DEA sur le meme projet. L’objectifprincipal du stage etait de developper un simulateur de reseau P2P.

Ce stage a pris place dans les locaux de l’INT en binome avec Pierre ZUREK. Lesujet demandait une grande autonomie, de l’initiative, un travail en equipe et un par-tage des connaissances. Il a aussi ete l’occasion de mettre en pratique les connaissancesacquises a l’IIE, notamment concernant la conception et la modelisation objet, ainsi quela programmation en Java. Le laboratoire de recherche de l’INT est public, ce qui m’aegalement permis d’entrevoir le monde de la recherche publique en France.

Ce rapport a pour objectif de developper, en les expliquant, les etapes de realisationde notre projet, mais aussi les perspectives de developpement futures. Certains chapitresfont des points techniques, d’autres sont plus theoriques, mais il est conseille de tout lirepour se rendre compte a quel point le cote pair a pair de l’informatique a de beaux joursdevant lui etant donnees les ameliorations possibles.

5

Chapitre 2

Cadre du stage

2.1 L’INT

Sous tutelle du Ministere de l’Industrie, de l’Economie et des Finances, l’InstitutNational des Telecommunications (INT) est un etablissement public d’enseignement su-perieur et de recherche. Il fait partie du Groupe des Ecoles des Telecommunications(GET).

Fig. 2.1 – Logos du GET et de l’INT

La Recherche a l’INT s’inscrit dans le domaine generique des Sciences et Technologiesde l’Information et de la Communication (STIC). La recherche est conduite sous l’anglescientifique et technique et sous l’angle du management et des usages. Elle s’appuie surun corps d’enseignants-chercheurs conferant a l’Institut une double competence (mana-gement/usages, scientifique/technique). Les domaines couverts sont principalement :

– les reseaux et services ;– l’informatique ;– le traitement du signal et de l’image ;– l’electronique et la physique ;– les systemes d’information ;– le management, l’economie et le droit des TIC ;– le marketing des TIC.

L’INT compte 170 enseignants-chercheurs repartis dans 8 departements. Les re-cherches a l’INT sont de type exploratoire ou pre-competitif. Elles sont, essentiellement,tournees vers l’application et l’innovation industrielle et s’appuient necessairement surdes etudes amonts conduites dans les laboratoires de l’Institut. Elles sont aussi, ele-

6

2.2. LE DEPARTEMENT INFORMATIQUE CHAPITRE 2. CADRE DU STAGE

ment primordial a la qualite et a l’actualite des enseignements de l’INT, situees dansun secteur en plein developpement. Elles se fondent sur de nombreuses relations et col-laborations scientifiques avec les communautes nationale et internationale. La recherchea l’INT constitue une reference reconnue sur les plans national et international, sur lestechnologies, les services et les usages.

2.2 Le Departement Informatique

Le Departement Informatique est l’un des 8 departements d’enseignement-recherchede l’INT. Le personnel permanent comporte 19 enseignants-chercheurs, un ingenieur derecherche, une secretaire et un nombre non negligeable de thesards.

Responsable du Departement : Guy BERNARDResponsable adjoint : Francois MEUNIERResponsable de la Formation Continue : Djamel BELAIDSecretaire : Brigitte HOUASSINEIngenieur de Recherche : Olivier BERGER

Pour les activites de recherche-developpement, les enseignants-chercheurs du Depar-tement Informatique sont rattaches a l’une des 3 equipes suivantes :

– Bases de donnees ;– Parallelisme ;– Systemes Repartis.

L’Equipe Systemes Repartis fait partie de la Formation SAMOVAR1. Ses activitesde recherche s’appuient sur un ensemble de machines autonomes reliees en reseau. Unetelle architecture offre une grande puissance de traitement a faible cout et permet l’accesa des ressources distribuees, en particulier via Internet.

L’axe principal de recherche concerne les aspects lies au systeme d’exploitation etau middleware pour offrir aux utilisateurs un support logiciel leur permettant de bene-ficier de la puissance maximale du reseau et cela de facon transparente, l’ensemble desmachines etant vu comme un seul processeur virtuel.

2.3 Environnement technique

J’avais a ma disposition une station de travail DELL dernier cri, specialement livreeau departement pour moi. J’ai du y installer un systeme d’exploitation (Fedora Core4, en l’occurence). J’ai aussi pris la liberte d’installer un gestionnaire de code source(subversion) etant donne que nous etions deux stagiaires a developper sur le meme projet.

1http ://www.int-evry.fr/samovar/presentation/

7

2.4. ENVIRONNEMENT HUMAIN CHAPITRE 2. CADRE DU STAGE

Le developpement devait se faire en Java, j’ai donc naturellement utilise l’environnementde developpement integre Eclipse.

2.4 Environnement humain

Voici nos interlocuteurs privilegies lors de notre stage :– Bruno DEFUDE, un des responsables du projet RARE et notre maıtre de stage,

dont le role etait de nous encadrer pour toute la duree du stage.– Jerome SICARD, stagiaire de DEA sur le projet RARE, qui partageait le meme

bureau que nous, et qui nous encadrait au jour le jour. Notre but etait d’imple-menter le fruit de ses recherches.

– Les equipes de l’ENST Paris, de l’ENST Bretagne, et du Laboratoire LIP6 parisien,que nous avons croise lors de reunions regulierement organisees ente les membresdu projet RARE a Paris.

8

Chapitre 3

Le sujet du stage

3.1 Le projet RARE

Le projet RARE1 (Routage par Apprentissage de REquetes) est un projet incitatif fi-nance par le GET (Groupe des Ecoles des Telecommunications) qui regroupe des equipesde l’INT, de l’ENST Bretagne et de l’ENST Paris. Le laboratoire LIP6 est egalementassocie au projet. Son titre exact est � Routage de requetes optimise par apprentissagedans les architectures P2P �.

3.1.1 Le contexte

Un nouveau modele de recherche est arrive ces dernieres annees, essentiellement portepar le partage de fichiers musicaux : le modele P2P. Cette approche permet d’interrogerun tres grand nombre de serveurs sans les connaitre a l’avance, et meme sans connaıtrel’etat global du systeme.

Le principe de resolution de requetes est le suivant : un client soumet sa requetea un serveur quelconque du reseau (le plus proche de lui par exemple), celui-ci resoutla requete localement et la propage a un certain nombre de ses voisins (aleatoirementchoisis). La recherche s’arrete quand une profondeur predefinie a ete atteinte.

Cette approche est bien sur tres inefficace et conduit a generer un grand nombre demessages. Elle fonctionne assez bien lorsque les ressources recherchees sont en generalles memes. Pour ameliorer cette approche, plusieurs propositions ont ete faites, commeles super-pairs (ou P2P hierarchise), les DHT (Distributed Hash Tables ou P2P struc-ture) ou encore le P2P semantique. Le projet RARE se siture dans ce dernier courant etpropose de remplacer la propagation aleatoire par une propagation guidee, c’est-a-direaller interroger les pairs les plus susceptibles de repondre.

1http ://www-inf.int-evry.fr/ defude/RARE/

9

3.1. LE PROJET RARE CHAPITRE 3. LE SUJET DU STAGE

La difficulte est de construire un tel systeme sans connaissance globale du reseau. Leprojet propose pour cela de coupler des algorithmes d’apprentissage automatique avecun protocole P2P. Ces algorithmes doivent analyser les requetes passees des utilisateurset leurs reponses pour etre ensuite capables de predire le bon routage pour une nouvellerequete. Chaque pair aura donc une connaissance assez precise du passe de ses utilisa-teurs mais une connaissance peu precise du passe des autres utilisateurs. Pour resoudrece probleme le projet propose deux approches. La plus simple consiste simplement aavoir une connaissance par defaut qui sera utilisee pour le routage. La deuxieme consistea permettre aux noeuds d’echanger des connaissances entre eux.

Ce projet est innovant dans les domaines suivants :– classification automatique de requetes utilisateurs ;– classification decentralisee des nœuds serveurs ;– construction automatique de communautes d’utilisateurs ;– recommandations par apprentissage dans un environnement decentralise ;– couplage P2P avec classification et apprentissage automatiques.

3.1.2 Les acteurs

Le projet RARE permet aussi de renforcer les collaborations entre ces equipes duGET dans le domaine de l’apprentissage automatique. Il permet de plus de poursuivreune collaboration avec le LIP6 dans le domaine du P2P semantique.

Comme le projet RARE est d’envergure, quatre equipes sont a pied d’œuvre :L’equipe de l’ENST Paris : elle developpe un generateur d’instances de reseau.L’equipe de l’INT : elle s’occupe de developper un simulateur de reseau P2P.L’equipe du LIP6 : elle a un role consultatif sur les evolutions du simulateur.L’equipe de l’ENST Bretagne : elle developpe un reseau de neurones.

Generateur

ENST Paris

-

Simulateur

INT & LIP6Apprentissage

ENST Bretagne

Fig. 3.1 – Projet RARE : Qui fait quoi ?

Le generateur est base sur des fichiers journaux d’un reseau Gnutella mis en placepour partager des fichiers audio. Il permet de creer un ensemble de pairs contenant des

10

3.2. LE BUT DU STAGE CHAPITRE 3. LE SUJET DU STAGE

documents et un ensemble de requetes a initialiser. Ces fichiers de sortie du generateursont les fichiers d’entree du simulateur : ceux qui donnent l’etat initial du reseau P2P. Lebut est alors de faire evoluer le reseau en integrant ou non les ameliorations proposeespar le projet (l’apprentissage grace au reseau de neurones), et pouvoir ainsi evaluer lespropositions sur un grand nombre d’instances.

Pierre ZUREK et moi-meme faisions donc partie de l’equipe de l’INT. Nous etionscharges d’inplementer le simulateur.

3.2 Le but du stage

Dans ce stage, il s’agissait de s’interesser a la definition d’un protocole P2P particu-lier et a son implementation sous la forme d’un simulateur de reseau P2P utilisant cenouveau protocole pour le dialogue entre les pairs.

Le but etait que tout le projet RARE puisse l’utiliser. Le simulateur a developperdevait permettre d’une part de supporter la propagation des requetes entre les pairs,mais aussi de gerer l’ajout et le retrait des pairs ainsi que l’echange des informations deroutage semantique entre les pairs.

Il est a noter que le reseau de neurones (developpe par l’equipe de l’ENST Bretagne)assure une propagation intelligente des requetes et a donc tout a fait sa place dans lesimulateur. Il fallait donc faire en sorte de faciliter le travail d’integration de ce reseauau simulateur que nous avions a developper.

Le sujet proposait la demarche suivante :

1. etude bibliographique des systemes P2P et notamment des systemes P2P seman-tiques ;

2. definition d’un protocole adapte au cas simple ou il n’y a pas d’echange de connais-sances entre les pairs ;

3. extension du protocole developpe pour le cas simple au cas ou il y a echange deconnaissances entre les pairs ;

4. prototypage du cas simple sur l’environnement JXTA (bibliotheque Java).

Cepandant, il s’est trouve que Jerome (le stagiaire de DEA) avait plus ou moins lememe sujet de stage que nous. Etant donne qu’il a commence son stage plusieurs moisavant nous, lorsque nous sommes arrives, il avait deja bien avance le travail bibliogra-phique, mais aussi developpe une premiere version minimaliste du simulateur. De plus,le projet RARE comptait s’interesser a deux approches disctinctes : l’implementation etla simulation. Or, deux semaines apres le debut de notre stage, une reunion du projetRARE a eu lieu a Paris, et il a ete decide de se concentrer prioritairement sur la secondeapproche.

11

3.3. LES OUTILS CHAPITRE 3. LE SUJET DU STAGE

3.3 Les outils

3.3.1 La bibliotheque JXTA

Le sujet initial prevoyait de tester le protocole a developper en grandeur nature sur unreseau de quelques machines. Pour cela, il mentionnait une bibliotheque Java : JXTA2.La nature meme du Java assure la portabilite de cette bibliotheque.

La technologie JXTA est un ensemble de protocoles ouverts qui permettent de fairecommuniquer toutes sortes d’interfaces (telephones portables, PDA, stations de travailtraditionnelles, serveurs, ...), et ceci en utilisant le principe du P2P. Les differentes in-terfaces sont en effet vues comme des pairs sur un reseau virtuel ou ils peuvent interagiret communiquer.

Toutes les interactions se font au moyen d’advertisement (en fait, un fichier XML)contenant toutes les informations necessaires pour que les N pairs voulant communiquerpuissent le faire. C’est a peu pres equivalent a un systeme d’evenements associe a desrendez-vous permettant de synchroniser les echanges d’informations qui peuvent egale-ment etre securises.

Nous avons commence a explorer cette bibliotheque durant les premieres semaines destage, de facon a nous familiariser avec les differents concepts. Cepandant, les participantsdu projet RARE se sont reunis et ont prefere laisser tomber cette idee. En effet, cettesolution ne permettait pas de tester la montee en charge du simulateur (et donc de serendre compte des resultats effectifs du protocole du projet RARE), car il fallait disposerd’un parc impressionnant de machines : une par pair.

3.3.2 Le simulateur PeerSim

C’est en fait suite a cette reunion que nous savions exactement quoi faire : un simu-lateur evolue de reseaux P2P. Comme les travaux de recherche avaient deja ete faits, unprojet equivalent avait deja ete trouve : PeerSim3.

On peut lire sur la page du projet que ce simulateur a specialement ete pense pourtester de nouveaux protocoles sur des reseaux dynamiques et a grande echelle. Tout aete imagine de facon simple (en faisant abstraction de certaines couches, comme parexemple la pile de protocoles de transport et de communication), parametrable (par lebiais d’un fichier de configuration), extensible (utilisation d’un systeme de plugins) etportable (developpement en Java).

Le simulateur PeerSim est un ensemble de classes Java qui implementent un simula-teur de reseau P2P. Deux types de simulations sont possibles : par evenements ou par

2http ://www.jxta.org/3http ://peersim.sourceforge.net/

12

3.4. CALENDRIER DU STAGE CHAPITRE 3. LE SUJET DU STAGE

cycles. C’est ce dernier type le plus interessant : nous laissons evoluer le reseau pendantun nombre predefini de cycles. Il nous suffira d’analyser l’etat du reseau a la fin de lasimulation pour en tirer les bonnes conclusions.

De facon a simuler et observer tout type de reseau P2P, les developpeurs de PeerSimmettent a notre disposition trois types de composants (ou plugins) :

les protocoles : ils definissent un comportement de nœud, il peut eventuellementen avoir plusieurs par nœud.

les dynamics : ils permettent de modifier le reseau. Par exemple : rajouter despairs, couper des liaisons, ...

les observers : ils permettent d’observer la simulation pour faire des statistiques.

Tout ces composants sont assembles grace a un fichier de configuration ou l’on ini-tialise les variables du reseau, declare la structure d’un nœud (les protocoles qui vont s’yexecuter a chaque cycle), initialise ces protocoles, declare les dynamics et les observersque l’on veut utiliser.

3.4 Calendrier du stage

Semaines Travaux effectuesS01 Decouverte de JXTAS02 et de PeerSimS03 Conception et modelisation du simulateurS04S05 Developpement du simulateurS06S07 Corrections d’erreursS08 et ajout de fonctionnalitesS09 Realisation d’une interfaceS10 graphiqueS11 Redaction de laS12 documentation technique

13

Chapitre 4

Travail effectue

4.1 Cahier des charges

Dans ce paragraphe, je vais essayer de construire le cahier des charges du simulateur.Il aurait pu nous etre fourni tel quel, mais le projet RARE etant un projet de Recherche,il obeissait a un processus incremental : le simulateur s’est construit au fur et a mesuredes idees qui venaient aux protagonistes.

4.1.1 Fonctionnalites elementaires

Avant de simuler l’evolution d’un reseau, quel qu’il soit, il faut bien sur etre capablede le construire et de l’initialiser. Ces deux fonctionnalites devait non seulement etre pre-sentes, mais aussi parametrables, de maniere a ne pas simuler toujours le meme reseau.

Un reseau P2P est constitue de pairs qui dialoguent. Il fallait donc que chaque pairpuisse emettre des requetes (des recherches de documents) et que ces requetes soientcorrectement propagees sur le reseau. Les pairs detenteurs de documents pertinents de-vaient renvoyer au pair emetteur de la requete la liste de ces documents de facon a luilaisser le choix de les telecharger ou non.

Afin d’augmenter la combinatoire des executions du simulateur, il fallait que le reseaune soit pas statique. En effet, le contenu des pairs devait pouvoir evoluer, mais aussi lereseau en lui meme : arrivees ou departs de pairs sur le reseau, ouvertures ou fermeturesde liaisons entre certains pairs, ...

4.1.2 La semantique

Comme nous l’avons vu precedemment, le projet RARE se positionne dans le cadrede l’etude du P2P semantique. Il s’agit de decouvrir un sens aux documents et auxcriteres de recherche, en collectant des informations sur le comportement des pairs, lesdonnees disponibles et les relations (semantiques) entre les deux au travers des requetesechangees, pour se rendre compte plus facilement qu’un document constitue une reponse

14

4.2. CONCEPTION ET MODELISATION CHAPITRE 4. TRAVAIL EFFECTUE

pertinente.

Ceci est possible grace a l’utilisation des Bloom filters. Le principe est assez simple.On peut assimiler un document a un ensemble de meta-donnees. On construit alors unvecteur v de m bits en utilisant k fonctions de hachage h1,...,hk prenant leurs valeursdans l’ensemble {1,...,m}. On applique les k fonctions de hachage a chaque meta-donneedu document, et on met a 1 dans v tous les bits de tous les indices ainsi trouves. Cevecteur represente le sens du document.

On peut faire de meme pour une requete (chaque mot de la requete peut etre vucomme une meta-donnee), et en construisant une distance sur l’espace des Bloom filters,on a facilement l’ecart de sens entre le document et la requete. Cette methode permetaussi de donner du sens a tout un pair en faisant le ou logique des Bloom filters de tousses documents.

4.1.3 Apprentissage

Imaginons maintenant qu’au lieu de transferer une requete a des voisins aleatoire-ment choisis, on se servait de cette semantique pour apprendre (en analysant les requetespassees) quels pairs ont l’habitude de repondre a une requete portant un sens donne.Cela permettrait de predire le bon routage des nouvelles requetes qui arrivent sur le pair.

Ce mecanisme d’apprentissage etait developpe sous la forme d’un reseau de neuronespar l’equipe de l’ENST Bretagne. Il fallait evidemment faciliter l’insertion du mecanismedans notre simulateur.

4.1.4 Partage des connaissances

En supposant que le systeme precedent est fonctionnel, une autre amelioration vienta l’idee. En effet, les tables de routages sont locales a un pair. Il pourrait etre interessantde faire en sorte que les pairs puissent s’echanger les informations contenues dans leurtables de routages. Cela permettrait de faire evoluer la connaissance globale du reseausur chaque pair, et faire en quelque sorte une moyenne (sur le reseau) des connaissancesacquises (en local).

Cette technique d’echange est appellee du gossiping, et il fallait prevoir son ajout ausimulateur.

4.2 Conception et modelisation

4.2.1 Principe de conception

Il nous a paru tout de suite important, au regard du travail demande, et de facon afaciliter la maintenance et la reutilisabilite du code de le decouper en modules logiques

15


capables d’effectuer des actions simples. C’est ainsi que par exemple l’initialisation dureseau a simuler, la gestion des requetes (initialisation, resolution, transfert), mais aussila gestion des reponses (creation, transfert, reception), ou encore la generation de tracesd’execution se retrouvent dans autant de modules quasiment independants les uns desautres.

Le simulateur PeerSim que nous avons utilise nous a grandement facilite la tache.Comme on peut le voir en annexe, il a deja ete pense pour executer une simulation dereseau sur un ensemble de cycles, mais en laissant a l’utilisateur le choix des interactionsentre nœuds a simuler. C’est pour cela que soit au debut du cycle de simulation, soit surchaque pair du reseau, des composants (protocoles, dynamics et observers) sont execu-tes. C’est a l’utilisateur de coder une classe Java par composant.

Il nous a donc fallu concevoir, puis modeliser et enfin implementer les modules sousforme de protocoles, de dynamics, ou d’observers.

4.2.2 Diagrammes UML

Dans ce paragraphe, les diagrammes UML des 5 principaux packages de notre im-plementation du simulateur vont etre commentes. Les images suivantes ont ete genereesdirectement a partir de la derniere version du code source avec Eclipse. Elles sont dela sorte tres lisibles et a jour. Mais il est a noter qu’avant de commencer a developper,nous sommes passes par une phase de modelisation importante, mais source de diversesratures.

Package principal

Fig. 4.1 – Diagramme UML principal

Il est compose de 5 classes :

16


DocumentHolder qui permet de gerer une liste de documents. C’est la representationd’un pair sur le reseau.

Gnutella qui herite de la precedente. C’est donc la representation d’un pair, mais avectous les attributs et les methodes pour lui permettre de communiquer. C’est unprotocole au sens PeerSim du terme.

Constants qui permet de stocker les constantes du reseau (la liste de tous les documentssur le reseau par exemple) qui sont correctement initialisees au debut de l’executiondu simulateur.

Variables qui permet de stocker les variables globales du reseau. Elle est reduite a unevariable qui compte le nombre de messages envoyes sur le reseau.

MyDefaultHandler qui est un gestionnaire generique de lecture de fichiers XML.

Package handlers

Fig. 4.2 – Diagramme UML des protocoles

Ce package est constitue de 4 gestionnaires qui sont tous des protocoles de PeerSim :

OverlayHandler qui permet de gerer le voisinage d’un nœud. Il contient par exempleune methode qui choisit les voisins a qui propager les requetes.

QueryHandler qui implemente le systeme de requetage d’un nœud (initialisation, reso-lution, transfert).

QueryHitHandler qui a l’instar du precedent implemente le systeme de reponse d’unnœud (creation, transfert, reception et traitement).

LogHandler qui est notifie a chaque action du simulateur. C’est lui qui amasse desinformations pour la creation de la trace d’execution de la simulation.

17


Fig. 4.3 – Diagramme UML des dynamics

Package dynamics

Comme indique sur la figure 4.3, ce package contient 3 groupes de classes. Chaque groupecontient un dynamic particulier qui est execute au debut de la simulation et qui permetd’initialiser une partie du reseau :

ProtocolsInitializer qui associe les gestionnaires du package precedent au protocoleprincipal (Gnutella) de chaque pair sur le reseau.

DocumentsInitializer qui lit l’ensemble des documents du reseau dans un fichier XML(avec SAXHandlerDocumentsDefinition) et qui les distribue sur les nœuds gracea un second fichier XML (avec SAXHandlerDocumentsDistribution).

QueriesInitializer qui fait de meme que la classe precedente mais sur un ensemblede requetes a initialiser (definition avec SAXHandlerQueriesDefinition et distri-bution avec SAXHandlerDocumentsDistribution).

Package observers

Fig. 4.4 – Diagramme UML des observers

Notre implementation du simulateur de reseau P2P contient 2 observers :

MessageObserver qui affiche au debut de chaque cycle le nombre de messages dejaenvoyes a travers le reseau.

18

4.3. LE DEVELOPPEMENT CHAPITRE 4. TRAVAIL EFFECTUE

LogObserver qui attend le dernier cycle pour accomplir effectivement sa tache. C’est cetobserver qui genere la trace d’execution de la simulation sous forme d’un fichierXML.

Package types

Fig. 4.5 – Diagramme UML des types de base

Voici les 3 types particuliers que l’on n’arrete pas de manipuler :

Document qui represente un document que peut posseder un pair. Il est caracterise parun indentifiant (dans la liste de tous les documents du reseau) et d’une liste demeta-donnees representant son contenu.

Query qui represente une requete et qui est caracterisee essentiellement par un identi-fiant, son TTL, et son critere de recherche (les mots cles de la recherche).

QueryHit qui represente une reponse que pourrait envoyer un pair suite a l’evaluationd’une requete. Elle est caracterisee par l’identifiant de la requete associee, du pairrepondant, et d’une liste des documents pertients.

4.3 Le developpement

Apres la phase de conception et de modelisation du simulateur, nous sommes passesa son developement. Il s’est fait de facon un peu particuliere, et comme le suggerait lesujet de stage : en plusieurs phases.

4.3.1 Le simulateur basique

Le but de cette premiere mouture etait de construire un simulateur elabore autourd’un protocole adapte au cas simple (et bien connu) des reseaux P2P, c’est-a-dire quandil n’y a pas d’echange de connaissances entre les pairs. Nous avons donc choisi, en accordavec nos encadrants, d’utiliser un protocole libre existant : Gnutella. C’est en effet unprotocole de reference dont le comportement est bien connu et bien defini.

Le but etait vraiment de suivre a la lettre la specification de ce protocole, en an-nexe de ce rapport. Nous avons donc defini les types Query (representant une requete)

19


et QueryHit (pour la reponse) en consequence, et en gardant les noms de la specification.

De meme, pour la propagation des requetes et des reponses, la specification a ete res-pectee : lorsqu’un pair doit propager une requete Q, il choisit aleatoirement un certainnombre de voisins et leur envoie, et la reponse A a cette requete Q suit le chemin inversesuivi par la requete Q (figure 4.6).

��

��Q�

�� R

��

@@

@R

Q

@@

@I

R

��

��Q�

�� R

��

Fig. 4.6 – La propagation des requetes dans Gnutella

Cette premiere version a ete rapidement implementee, d’autant plus que Jeromeavait deja developpe une pre-version dont nous nous sommes servis. Nous avons alors eteconvies a une reunion a Paris, concernant tout le projet RARE, et nous avons pu faireune demonstration de notre travail.

4.3.2 Les ajouts de fonctionnalites

Lors de cette reunion, nous avons pu decouvrir les personnes des autres equipes surle projet et nous rendre compte de l’avancement de chacun. Suite a notre demonstration,nous avons eu droit a beaucoup de questions mais aussi des demandes d’implementation.

Voici les points principaux :– Nous avions fait en sorte que les entrees du simulateurs soient des fichiers XML

donnant la liste de documents presents sur le reseau et la liste des requetes ainitialiser durant la simulation. Deux autres fichiers XML donnaient la distributionde ces documents et de ces requetes a initialiser sur les differents nœuds du reseau.Le probleme etait que ces documents n’etaient pas generes par nous, mais par uneautre equipe. Cette reunion a ete le moyen de tomber d’accord sur le format desfichier XML, et ainsi de mettre en place dans le simulateur une verification de ceformat a partir de schemas XML.

– La premiere version du simulateur fonctionnait correctement : elle permettait d’en-voyer et de recevoir des messages sur un reseau P2P. Le probleme, c’est que nousn’avions pas beaucoup reflechi a la maniere d’implementer le fait qu’un pair puisseprendre la decision de telecharger un document suite a une requete qu’il a initialise.La encore, la reunion a permis de decider de prendre pour reference un devin qui

20


pour chaque requete sait evaluer une distance entre les documents ideaux et lesdocuments pertinents presents sur le reseau. Nous avons donc decide de rajouterune liste des documents les plus pertinents pour chaque requete dans le fichierXML de definition des requetes.

– Avant la reunion, nous ne nous etions pas trop rendus compte que le simulateuretait au cœur du projet, en ce sens qu’il devait evaluer les ameliorations que leprojet RARE est cense apporter au P2P. Par exemple, nous n’avions pas parti-culierement fait en sorte de faciliter le travail d’integration du reseau de neuronesdeveloppe par l’equipe de l’ENST Bretagne. Nous avions en effet code en dur lechoix (aleatoire, comme dans le protocole Gnutella) des voisins a qui propagerles requetes. Apres la reunion, nous avons donc reorganise notre code pour faireen sorte que cette fonctionalite soit un module du simulateur, et donc facilementparametrable, voire re-implementable.

– L’equipe de l’ENST Bretagne developpant le reseau de neurones devait lui faireapprendre le passe des requetes, mais pour cela, il leur fallait des exemples d’ap-prentissage. Nous nous somme mis d’accord lors de cette reunion que le meilleurmoyen serait de faire tourner notre simulateur sur une instance de reseau assezgrande, et ceci en gardant le principe du devin pour prendre les decisions de te-lechargement. La trace de cette simulation leur fournirait alors tout ce dont ilsavaient besoin. Mais pour leur faciliter le travail et leur rendre la trace directe-ment exploitable, nous avons conjointement decide de generer un fichier XML deformat specifique et discute au prealable.

4.3.3 L’interface graphique

Suite a ces changements, il s’est trouve que le fichier de configuration du simulateur,dans lequel on specifiait tous les parametres de simulation (par exemple les modules acharger, les fichiers XML a lire pour initier le reseau, le nom du fichier XML ou ecrirela trace ...) prenait un volume important, mais surtout devanait assez obscur.

Pour remedier a ce probleme, nous avons decide de developper une interface graphiqueassez complete qui permet de construire pas a pas la configuration d’une simulation. Lechoix de son implementation s’est impose de lui meme : Swing, la bibliotheque graphiquefournie avec la machine virtuelle de SUN. L’interface graphique est parametrable, defacon a pouvoir specifier simplement le fonctionnement d’un module et ses parametresobligatoires qui doivent figurer dans la configuration.

4.3.4 Ce qu’il reste a faire

Comme je l’ai mentionne plus haut, le developpement dans un projet de Recherche,et ce fut le cas pour le developpement du simulateur dans le projet RARE, est souventincremental : on ne se base pas sur un cahier des charges precis, mais on implementeles fonctionnalites au fur et a mesure qu’elles germent dans nos tetes ou dans celles des

21


Fig. 4.7 – Vue d’ensemble de la GUI

chercheurs sur le projet.C’est pour cela que le simulateur est tres loin de son etat final.

Voici une liste detaillee des objectifs a moyen terme :– Dans un premier temps, il serait judicieux d’integrer le reseau de neurones au si-

mulateur. En effet, une fois qu’il aura appris du passe des requetes, on pourraevaluer (notamment en nombre de messages) l’amelioration par rapport a la solu-tion basique. Avec la documentation que nous avons laissee avant de partir, celane devrait pas leur poser de problemes.

– Dans un deuxieme temps, il faudrait implementer la solution de gossiping : c’esten effet elle qui permettra a un pair de partager sa connaissance du reseau (engros, la semantique de sa table de routage) avec ses voisins. Jerome, a la fin de sonstage de DEA, travaillait sur ce point pour prendre un peu d’avance sur la thesequ’il a pu obtenir grace a son implication dans le projet RARE.

– Dans un troisieme temps, et pour rendre le code du simulateur encore plus propreet reutilisable, il pourrait etre avantageux de construire une API complete, eninterfacant toutes les classes de l’application (en Java, creer des interfaces ou desclasses abstraites). Il faudrait finalement faire comme les developpeurs de PeerSimmais avec un simulateur plus evolue, de facon a pouvoir eventuellement le distribuerdans la communaute.

– Enfin, pour evaluer en grandeur nature le nouveau protocole P2P du projet RARE,le mieux serait quand meme d’ecrire un client (pourquoi pas en JXTA) capable de

22

4.4. LES TESTS DU SIMULATEUR CHAPITRE 4. TRAVAIL EFFECTUE

prototyper ce nouveau protocole et que l’on puisse ainsi le tester sur des reseauxreels, avec toutes les contraintes inherentes que l’on peut aisement contourner avecun simulateur.

4.4 Les tests du simulateur

Comme il faut toujours le faire dans un developpement d’application, nous sommespasses par plusieurs phases de tests etalees durant le stage et entre deux phases dedeveloppement.

4.4.1 Tests nominaux

Avant de faire une confiance aveugle au simulateur qui aura pour role de juger de lapertinence des ameliorations apportees au P2P en general, il a fallu s’assurer qu’il faisaitbien ce qu’on lui demandait.

Nous avons teste plusieurs criteres :

Detection de cycles : dans le cas d’une instance de reseau avec au moins un cycle, unnœud peut recevoir la meme requete (identifiee par son Id) plusieurs fois. Il fautdonc verifier dans ce cas la que le nœud ne traite pas plusieurs fois les requetesqu’il a deja recu et donc deja traite.

Temps de calculs : une requete est traitee en 1 cycle, donc si un nœud doit traiterplusieurs requetes pour un cycle donne, il faut verifier qu’elles sont bien mises dansune file d’attente et qu’elles seront transferees sur les nœuds voisins aux bons cycles.

Transfert des requetes : le protocole Gnutella prevoit de choisir degree voisins parmitous les voisins du nœud courant (en enlevant le nœud d’ou provient la requete atransferer) et de leur transferer les requetes. C’est ce qui a ete implemente, mais ilfaut verifier que c’est le cas dans la pratique, et ce qui se passe aux limites (quandil n’y a pas assez de voisins pour en choisir le bon nombre, par exemple). De plus,il faut tester le mecanisme de TTL (Time To Live) des requetes, soit le nombrede propagation que pourra subir une requete avant d’etre oubliee.

Transfert des reponses : toujours en nous appuyant sur la specification du protocoleGnutella, nous avons fait en sorte que la reponse du nœud N a la requete Q initieepar le nœud I suive le chemin inverse qu’a parcouru Q entre I et N (voir figure4.6, page 20). Cela doit etre verifie.

Telechargement des documents : une fois la reponse recue par le nœud initiateur dela requete associee, il peut prendre ou non la decision de telecharger des documentsinclus dans la reponse. Il faut verifier que ce systeme fonctionne correctement, c’est-

23

4.5. DOCUMENTATION CHAPITRE 4. TRAVAIL EFFECTUE

a-dire qu’il prenne bien la decision en accord avec le devin et qu’il mette bien ajour la liste de documents du pair emeteur de la requete.

4.4.2 Montee en charge

Dans un second temps, nous avons teste notre simulateur sur des donnees assezgrandes (en fait les seules qu’on a pu nous fournir) de facon a tester la montee en chargede l’application. Le test que nous avons pu faire est celui-ci : 600 cycles, 133 pairs,17856 documents, 683 requetes.

En stage, nous avions a notre disposition des stations de travail DELL munies d’IntelPentium 4 a 2.80GHz et de 1Go de memoire RAM, et l’execution de cette simulationprenait environ 2 minutes et utilisait un peu moins de 70Mo de memoire. Tout cela pourdire que nous avons pense le code du simulateur de facon a optimiser le temps de calculplutot que l’utilisation de la memoire. C’est pour cela que sur chaque noeud, nous avonsopte pour des structures de donnees peu communes (un tableau de FIFO). Le probleme,c’est que la taille de ces tableaux est directement associee au nombre de cycles de simu-lation.

Le point faible du simulateur et donc la : ne pas pouvoir faire des simulations associanta la fois un trop grand nombre de cycles et une instance de reseau de trop grande taille.Il reste neanmoins plus facile et moins onereux de rajouter de la RAM que de changerle processeur.

4.5 Documentation

Lors de notre stage, et tout le long du developpement, nous avons egalement fait desefforts de documentation, et ce a deux niveaux. Le premier est que nous avons commentetout notre code en JavaDoc, en anglais, pour qu’il soit facilement reutilisable par le plusgrand nombre. Le deuxieme est que nous avons consacre la derniere semaine de notrestage a ecrire une documentation technique de notre implementation du simulateur dereseau P2P qui est disponible en annexe. Elle se veut claire, precise, facile a lire, etorientant les lecteurs desireux de mettre les mains dans notre code, limitant ainsi l’effortde developpement dans le futur.

24

Chapitre 5

Conclusion

Pour conclure ce rapport, je peux dire que je suis tres heureux d’avoir ete l’une desdeux personnes a etre choisi pour effectuer ce stage. J’ai rencontre des gens formidablesqui m’ont aide a bien comprendre ce que je faisais, et meme a me donner une certainevision du P2P dont je n’avais meme pas conscience : plus que le partage de fichiers surun reseau, c’est aussi un partage de ressources (memoire, temps de calcul, ...) qui sont laplupart du temps inutilisees. Je pense que ce cote de l’informatique se developpera dansl’avenir.

De plus, ce stage m’a permis de toucher du doigt le monde de la recherche publiqueen France. C’est un environnement completement different de celui que j’ai pu connaıtreen stage de 1ere annee (monde de l’entreprise, hors recherche). Et, encore une fois, ladisponibilite des personnes de mon entourage direct m’a ete d’un grand secours.

Enfin, ce stage m’a permis d’approfondir mes connaissances dans divers domainestechniques : conception et modelisation objets (Design Paterns, UML), programmationobjet (Java) et reseaux (P2P). Mais aussi dans des domaines plus relationnels : autono-mie et initiative, travail en equipe, comprehension et adaptation a un projet existant.

25

Annexe A

Documentation de PeerSim

Annexe B

Specification du protocoleGnutella

Annexe C

Documentation du simulateur