Projet de technologie de l information RAPPORT

Transcription

1 Projet de technologie de l information RAPPORT Groupe i : Thomas Schwery & Alexandre Chappuis Assistant : Laurent Bindschaedler École Polytechnique Fédérale de Lausanne Année Propédeutique, printemps 2008 Table des matières 1 Introduction 3 2 Description des classes Classes de bases Peer PeerClient Classes pour les fichiers UploadedFileInfo FileBlock Replica RepositoryInfos EncodedFileInfo SuperBlock EncodedBlock Classes pour le PeerServer PeerServer PeerServerChannel Classes pour les Repositories Repository RepositoryChannel Classes pour la Gui Gui GuiFrame ThreadDownload ThreadUpload Classes utilitaires Menu UserInput Log Matrix GeneratorMatrix

2 3 Diagramme des classes 10 4 Améliorations Gui PeerServer et Repositories Gestion des processus Sérialisation Hack Divers Répartition des tâches 15 6 Conclusion 15 7 Annexes 16 2

3 1 Introduction Ce projet nous a accompagné durant un semestre. Tout au long de ce dernier, nous avons petit à petit implémenté en JAVA un système Peer-to-Peer pour le partage de fichiers, avec contrôle d accès, réplication par blocs et encodage Reed-Solomon. Ce rapport se veut d abord d apporter une meilleure vue d ensemble de notre implémentation, en décrivant toutes nos classes et les liens qui les unissent, notamment grâce à un diagramme de toutes les classes. Nous ne décrirons que leurs principales méthodes. Nous ajouterons ensuite quelques mots sur les différentes améliorations que nous avons apportées au programme de base et sur la répartition des tâches au sein de notre groupe. Finalement, nous tirerons quelques conclusions sur nos expériences, sur le savoir-faire que nous avons acquis et sur le déroulement du travail durant le semestre. 2 Description des classes Les vingt-deux classes de notre projet sont ici décrites avec leurs principales méthodes. Pour une liste et description de tous les attributs et méthodes d une classe, prière de consulter la Javadoc du projet, accessible depuis la page./doc/index.html ou consultable dans le code source de chaque fichier. 2.1 Classes de bases Peer Cette classe sert de démarrage à notre programme Peer to Peer. Elle traite les arguments fournis à la méthode main, les contrôle et s occupe de créer les répertoires requis. Elle instancie finalement un PeerClient, à travers lequel le menu principal est démarré. La classe Peer permet aussi de recevoir des arguments en format UNIX ( paramètre valeur). C est la méthode unixargs(string[] args) qui s occupe de les convertir dans le bon format. Quant à elle, la méthode error() affiche un message d erreur et quitte le programme PeerClient PeerClient est de loin la plus grande classe de notre programme. C est elle qui gère toutes les demandes de l utilisateur. Son constructeur prend en paramètre les arguments récoltés par la classe Peer. Il initialise également un fichier log dans lequel les erreurs seront affichées. La méthode start(), munie d une boucle infinie et d un switch, permet d afficher le menu principal et de traiter le choix de l utilisateur. C est aussi la classe PeerClient qui s occupe de gérer les ajouts et suppressions de fichiers dans nos collections. Nous avons séparés nos fichiers en deux collections : une pour les fichiers normaux, une pour les fichiers encodés. En outre, nous avons tenté de dupliquer le minimum de code lors de la création des méthodes concernant le download et l upload des fichiers. Nous disposons ainsi d une seule méthode pour le téléchargement, pour l affichage et pour savoir 3

4 si un fichier se trouve déjà dans une collection ou non. Les méthodes listsharedfiles() et isalreadyuploaded() disposent ainsi d un paramètre muni d une syntaxe bien particulière : List<? extends UploadedFileInfo>. Cette dernière permet de recevoir une collection de données de types UploadedFileInfo ou de toutes ses sous-classes. On peut ainsi passer en paramètre notre collection de fichiers normaux ou encodés. Quant à la méthode download, nous sommes sûr qu elle appelera la bonne méthode de téléchargement du fichier grâce à la résolution dynamique des liens de Java. Il n a par contre pas été possible de faire une seule méthode pour l upload. Nous l avons donc séparé en deux méthodes : uploadfile() et encodedupload(). Ces deux méthodes n étant pas très longues, nous pensons rester en accord avec le principe de dupliquer le minimum de code. Pour ces deux dernière, nous demandons les informations nécessaires à l utilisateurs si cela n a pas déjà été fait par la Gui, c est-à-dire si l appel de ses méthodes se fait depuis le mode console. Le démarrage du PeerServer et des Repositories se fait aussi dans cette classe. Les méthodes newpeerserver() et newrepository() permettent de démarrer les threads qui attendront les connexions (voir sections 2.3 et 2.4 page 7 de ce rapport pour de plus amples informations sur ces connexions). Ces méthodes appellent également les méthodes d enregistrement de ces processus auprès du Directory. La classe PeerClient s occupe finalement de gérer l historique des fichiers uploadés : c est elle qui l enregistre à la fermeture du programme et qui le lit au démarrage. La page html contenant les infos sur les fichiers est aussi maintenue à jour par PeerClient. La plupart des méthodes de cette classe sont publiques afin qu elles soient disponibles pour la Gui. (Pour de plus amples informations sur la Gui, lire la section 2.5 en page 8 de ce rapport.) 2.2 Classes pour les fichiers Chaque classe de cette catégorie, hormis RepositoryInfos, représente une partie bien spécifique d un fichier et contient les méthodes suivantes : Upload() : permet d uploader la partie du fichier et de mettre à jour l avancement de la barre de progression si l appel s est fait depuis la Gui. Download() : permet de télécharger la partie du fichier et de mettre à jour l avancement de la barre de progression si l appel s est fait depuis la Gui. printxxxinfos() : permet d afficher des informations sur la partie du fichier receivexxxinfos() : permet de recevoir les informations de la partie du fichier auprès d un PeerServer sendxxxinfos() : permet d envoyer les informations de la partie du fichier (utilisé par notre PeerServer) Nous décrirons ici les spécificités et méthodes additionnelles de chaque partie des fichiers normaux, puis des fichiers encodés UploadedFileInfo Un UploadedFileInfo est composé de plusieurs FileBlock, contenant chacun un morceau du fichier entier. Cette classe permet donc de stocker toutes les informations importantes sur un fichier, dans son plus haut niveau d abstraction. 4

5 Ces informations sont indispensables pour les étapes d upload, de download et d envoi/réception d informations. Toutes ces étapes sont gérées par les méthodes de cette classe. Le download est appelé par la méthode download(). Elle télécharge les blocs du fichier dans un ordre croissant. Si un bloc échoue, le download est annulé. L upload s effectue grâce à la méthode uploadfile(). Cette méthode prend en arguments le nombre de répliques souhaitées, le nom du fichier ainsi qu un channel ouvert vers le directory, permettant de recevoir la liste des repositories. Cette liste est reçue dans la méthode receivelistrepositories(). La taille du fichier à uploader est contrôlée par la méthode readfile() et les informations sur les blocs (nom, taille, etc...) sont définis dans setblockinfos(). A la fin d un upload ou d un download, il ne faut pas oublier de fermer les connexion encore actives. La méthode fermeturechannelrepositories() permet de réaliser cela FileBlock Un FileBlock est composé de plusieurs Replica, les répliques du bloc stockées sur les repositories. Cette classe permet donc de stocker toutes les informations concernant un bloc d un fichier. Ces informations concernent la taille, l emplacement et les répliques du bloc. Le download est géré par la méthode download(), qui va contacter chaque réplique tour à tour, jusqu à ce qu une réplique soit téléchargée avec succès. Si aucune réplique n a pu être téléchargée, le downlad est annulé. L upload est géré par la méthode upload(), qui va créer un tableau de Replica et les envoyer sur les Repositories. Les informations sur les Repositories sont stockées dans des objets RepositoryInfos Replica Replica est le plus petit élément d un fichier. Il s agit de la réplique d un bloc, c est à dire d une copie d un morceau du fichier, qui se trouve sur un repository. Il s agit de la seule classe en interaction avec les repositories, toutes les autres n étant que des objets intermédiaires utiles au stockage des informations nécessaires à la découpe et à la reconstitution du fichier. Chaque réplique possède un nom unique qui comprend le nom du fichier, l heure courante, le nombre de blocs et le nombre de répliques. Le download d une réplique est géré par la méthode download(), qui va contacter le Repository la contenant et recevoir les bytes de cette dernière. Il s agit de la seule méthode téléchargeant effectivement les données du fichier, celles-ci étant écrites sur le disque dur par la méthode writeblock(). L envoi de la réplique est effectué par la méthode upload(). Celle-ci envoie le fichier sur le repository fourni en argument. Il s agit également de la seule méthode envoyant effectivement les données du fichier RepositoryInfos RepositoryInfos permet de stocker les informations concernant un repository. Cette classe ne possède aucune méthode de communication, son seul rôle étant l enregistrement d informations pour les répliques. Cette classe permet 5

6 également de stocker un Channel ou un ErrorChannel de manière temporaire, ces objets n étant pas sérialisables. Une méthode compareto() permet de comparer deux repositories. Cette méthode compare les taux d échec de deux repositories, considérant le repository ayant la fréquence d échec la plus élevée -c est à dire le plus disponiblecomme étant le plus petit EncodedFileInfo EncodedFileInfo est le pendant encodé d un UploadedFileInfo. Il en hérite d ailleurs toutes les méthodes et variables et redéfinit certaines méthodes, telles que uploadfile(), download() et sendfileinfos(). Un fichier encodé est découpé en plusieurs SuperBlock, contenant chacun un morceau du fichier. L envoi est géré par la méthode uploadfile(), s occupant de récupérer la liste des repositories, d en sélectionner les meilleurs, de calculer les paramètres d encodage et d appeler la méthode d envoi de chaque SuperBlock. Les paramètres d encodage nécessitent de connaître deux informations : le taux d échec global et le taux d échec désiré. Le premier est calculé à partir du nombre de repositories indisponibles et du taux d échec des repositories sélectionnés. Le deuxième est demandé à l utilisateur. Ces taux permettent de calculer le nombre de mots d informations nécessaires pour l encodage (le paramètre k). Ces mots d informations sont ensuite encodés. Les mots codes résultants sont placés dans une matrice, la matrice des mots-codes du SuperBlock, qui est passée en paramètre à la méthode d upload d un SuperBloc. La procédure de téléchargement est gérée par la méthode download(). Celle-ci va calculer la matrice génératrice du code et chercher à télécharger les différents SuperBlock SuperBlock Un SuperBlock est un morceau de fichier encodé, divisé en blocs encodés appelés EncodedBlock. Chacun des SuperBlock peut être codé et décodé indépendemment des autres SuperBlock avec la même matrice génératrice. L envoi de données est géré par la méthode upload() qui récupère la matrice de mots-codes du SuperBlock et la découpe en EncodedBlock pour l envoi des données vers les repositories. C est aussi elle qui définit le nom du Super- Block et qui entrelace les mots-codes avant leur envoi sur les repositories. Le téléchargement se fait par la méthode download(), qui va lancer le download de chaque EncodedBlock constituant le fichier, jusqu à ce qu un nombre suffisant -c est à dire k - de blocs aient été obtenus. Ces derniers sont ensuite décodés par la méthode decode(), qui va résoudre les systèmes d équations et retrouver les mots d informations originaux pour les écrire sur le disque dur EncodedBlock EncodedBlock est le pendant encodé de FileBlock. Il s agit d un motcode du fichier encodé qui sera ensuite envoyé sur les repositories. Il en hérite les méthodes et variables et redéfinit certaines méthodes telles que download(), upload() ou sendblockinfos(). Comme pour FileBlock, il s agit de la seule partie concernée directement par l envoi des données du fichier. 6

7 Le téléchargement est effectué par la méthode download(), qui va contacter tous les repositories contenant cet EncodedBlock -habituellement un seul- tour à tour afin de récupérer les bytes du mot-code. L envoi des données est géré par la méthode upload() qui contacte le repository et lui envoie le packet contenant le mot-code préparé par SuperBlock.upload(). 2.3 Classes pour le PeerServer Le PeerServer récupère les données sur les fichiers en ligne et les envoie aux clients. Cet envoi s effectue dans les méthodes sendxxxinfos() présentes dans chaque classe nécessitant un envoi de données. Celles-ci s appellent à travers les méthodes UploadedFileInfo.sendFileInfo() et EncodedFileInfo.sendFileInfo(), les méthodes des autres classes étant appelées par ces deux méthodes. Le PeerServer ne fait que consulter les collections de fichiers uploadés. Seul le PeerClient est habilité à les modifier PeerServer La classe PeerServer sert de lanceur aux threads démarrés pour chaque connexion. Son rôle est d écouter chaque connexion et de lancer un processus qui gérera les commandes de chaque client. La boucle de lancement peut être interrompue grâce à la méthode stop(). Dans ce cas, aucune nouvelle connexion ne pourra être établie tandis que les connexions déjà établies resteront ouvertes jusqu à leur fermeture par le client PeerServerChannel Cette classe, implémentant Runnable, permet de gérer les commandes reçues par un client. La boucle de réception est interrompue dès que le client envoie un BREAK ou qu une erreur de connexion est levée. Les commandes comprises par le PeerServer sont celles spécifiées dans le protocole. 2.4 Classes pour les Repositories Le repository permet de stocker les données envoyées sur le réseau. L enregistrement se fait dans un dossier spécifique au repository, constitué du nom du peerclient l ayant démarré et du port sur lequel le repository écoute les connexions. Ainsi, un repository peut être interrompu, redémarré et peut continuer à servir les fichiers uploadés, même si le port de ce dernier a changé. Chaque repository possède également une fréquence d échec qui définit le nombre de connexions à accepter avant d en refuser une. Cette fréquence est choisie par deux lancers de dés à six faces, ce qui veut dire que la fréquence est comprise entre 2 et Repository La classe Repository sert de lanceur aux threads démarrés pour chaque connexion. Son rôle est d écouter chaque connexion et de lancer un processus qui gérera les commandes de chaque client. La boucle de lancement peut être interrompue grâce à la méthode stop(). Dans ce cas, aucune nouvelle connexion 7

8 ne pourra être établie tandis que les connexions déjà établies resteront ouvertes jusqu à leur fermeture par le client RepositoryChannel Cette classe, implémentant Runnable, permet de gérer les commandes reçues par un client. La boucle de réception est interrompue dès que le client envoie un BREAK ou qu une erreur de connexion est levée. Les commandes comprises par le Repository sont celles spécifiées dans le protocole. 2.5 Classes pour la Gui Pour la Gui, nous avons décidé de travailler avec Swing, car beaucoup plus de composants étaient disponibles et leur look plus agréable à nos yeux Gui Cette classe très courte est appelée par le PeerClient. Elle implémente l interface Runnable car la fenêtre de l interface graphique doit être appelée dans un nouveau Thread. On crée donc dans la méthode run() (la seule méthode de cette classe) un nouvel objet GuiFrame. On la rend ensuite visible GuiFrame GuiFrame représente la fenêtre de notre interface graphique. Elle dispose d un constructeur qui définit tous les éléments compris dans le fenêtre et dispose de plusieurs méthodes qui écoutent les événements déclenchés par l utilisateur. C est dans cette classe qu apparaît l interaction avec le PeerClient. La fenêtre est organisée en plusieurs JPanel. Chacun de ses derniers contient les composants nécessaires à la Gui (Boutons, listes, panels, textfields, etc...). Finalement, ils se retrouvent organisés dans un gestionnaire de mise en forme GridLayout. La plupart des composants sont des variables d instances car ils doivent être accessibles depuis plusieurs méthodes. Ils sont cependant initialisés dans le constructeur de la fenêtre. Deux méthodes d écoute se trouvent dans cette classe : actionperformed() Cette méthode permet d écouter les actions effectuées sur tous les boutons et d agir selon la source de l événement. Elle est similaire à la méthode start() de notre PeerClient, dans le sens où elle traite le choix de l utilisateur. Elle fait appel aux méthodes connexion(), achat(), voirpeerserver(), voirfichiers(), download() et upload(). La méthode download() lance un nouveau thread pour le téléchargement. La méthode upload() fait de même, mais demande dans un premier temps à l utilisateur les informations nécessaires, tel que le nombre de répliques s il s agit d un fichier normal ou le nombre de paquets tests à envoyer / le taux d échec lors du téléchargement s il s agit d un fichier avec encodage. itemstatechanged() Cette méthode permet d écouter les actions effectuées sur les listes de choix (pour le choix du Directory, des PeerServers et des fichiers). On notera la présence d une méthode insertion() qui nous permet d insérer une ligne dans la partie Informations de la Gui. Les méthodes insertintotable() et 8

9 removeupload() permettent de gérer l ajout et la suppression des fichiers dans les tables pour le download et l upload. La Gui contient aussi deux classes internes, qui sont décrites dans la rubrique Améliorations de ce document ThreadDownload Cette classe permet de lancer un téléchargement en arrière-fond depuis Gui- Frame. Son constructeur permet d initialiser les informations sur le fichier à télécharger et sa méthode run() permet de démarrer le téléchargement en faisant appel au PeerClient. C est aussi ici que la barre de progression est créée et passée en paramètre au peerclient. La couleur de cette dernière dépendra du type du fichier : elle sera bleu foncé s il s agit d un fichier encodé et bleu clair sinon. Au début du téléchargement, on ajoutera dans la table de download de la Gui le couple (nom du fichier, barre de progression). Six secondes après la réussite ou l échec de l opération, on le retirera ThreadUpload Cette classe permet de lancer un upload en arrière-fond depuis GuiFrame. Son constructeur permet d initialiser les informations sur le fichier à uploader et sa méthode run() permet de démarrer l upload en faisant appel au peerclient. C est aussi ici que la barre de progression est créée et passée en paramètre au peerclient. La couleur de cette dernière dépendra du type du fichier : elle sera bleu foncé s il s agit d un fichier encodé et bleu clair sinon. Au début de l upload, on ajoutera dans la table d upload de la Gui le couple (nom du fichier, barre de progression). Six secondes après la réussite ou l échec de l opération, on le retirera. 2.6 Classes utilitaires Menu Les menus étant appelés à maintes reprises dans notre projet (menu principal, choix des fichiers, des peerservers etc...), nous nous sommes simplifiés la vie en créant cette classe dès les premières semaines de travail. Un menu peut être construit de deux façons : soit en lui passant un tableau de chaînes de caractères en paramètre, soit une liste. Une fois le menu créé, il suffit d appeler la méthode affiche menu() qui nous retournera le choix de l utilisateur. On pourra ensuite effectuer diverses actions en fonction de ce choix. Nos menus gèrent aussi d éventuels séparateurs. Nous avons adopté la convention de commencer et de finir un séparateur par un tiret ( - ). Notre classe tient compte des éventuels séparateurs du menu et ne les comptabilise pas pour le choix de l utilisateur UserInput Cette classe permet de faciliter les demandes d entrées de données par l utilisateur. Il est possible de demander des entiers et des réels de manière simple, en spécifiant uniquement la question à poser et, si cela est nécessaire, le nombre 9

10 minimum et maximum accepté. Les méthodes sont statiques afin que l on puisse les appeler de cette manière, sans créer d objet : int entier = UserInput.askInt("Question...", minimum, maximum) Log Cette classe permet d écrire des fichiers log des problèmes et événements survenus durant l exécution du programme. Le constructeur permet d initialiser le nom du fichier voulu et la méthode add() permet d ajouter la ligne fournie en argument à ce dernier, précédée de l heure et la date auxquelles s est produit l événement. Pour plus d informations sur les raisons de cette classe, prière de lire le paragraphe divers de la section Améliorations Matrix Les matrices étant utilisées à maintes reprises dans la version encodées de nos downloads et uploads, nous avons créé cette classe pour les représenter. Un vecteur sera tout simplement une matrice de dimensions (1 n). Tous les éléments d une matrice seront des éléments du corps F256. Nous pouvons construire une matrice de deux façons : soit en spécifiant uniquement ses dimensions, soit en spécifiant ses dimensions et son contenu (en bytes qui seront convertis en éléments). Les deux constructeurs de cette classe permettent ces opérations. Les deux méthodes les plus utilisées sont sans doute multiply() qui multiplie la matrice courante avec celle passée en paramètre et echelonner() qui échelonne la matrice courante. On trouve aussi des méthodes utilitaires qui permettent de définir une ligne ou une colonne bien spécifique de la matrice GeneratorMatrix Cette classe hérite des propriétés d une matrice normale. Son constructeur fait appel au constructeur d une matrice sans contenu, qui initialise ses dimensions. Il définit ensuite le contenu de la matrice génératrice, d une manière optimale. Pour ce faire, nous calculons l élément (i, j) à partir des éléments précédents, ce qui réduit considérablement les calculs. Comme nous travaillons avec un générateur de corps (l élément deux), nous savons que la 1 e ligne et la 1 e colonne sont composées uniquement de 1. La deuxième colonne est une succession de puissances de 2, et les autres éléments de la ligne i et colonne j se calculent d après cette formule : G ij = G ij 1 G i2 3 Diagramme des classes Nous avons réalisé le diagramme des classes à l aide du plugin Amateras UML pour Eclipse. Vous le trouverez dans les annexes de ce document, en format A3 couleur. 10

11 4 Améliorations Nos améliorations peuvent se diviser en plusieurs catégories : celles concernant la Gui, celles concernant la gestion des processus, celles pour le PeerServer et les Repositories, celles concernant la sérialisation, celles à consommer avec modération ( HACK ) et toutes celles que nous avons implémentées par-ci parlà. Nous procéderons par ordre d importance. 4.1 Gui La Gui est l endroit où les améliorations nous ont pris le plus de temps. Premièrement, nous avons voulu implémenter toutes les fonctions principales de notre projet dans la Gui. Nous avons ainsi conçu les méthodes de notre PeerClient d un façon simple, afin que la Gui puisse les utiliser de la même façon que le PeerClient le fait. L upload, les opérations encodées, le démarrage d un PeerServer et la création de repositories sont ainsi possibles depuis le programme en version graphique. De plus, l upload des fichiers (avec encodage ou non) perd une grande limite qu il avait en mode console : celle de pouvoir les choisir librement sur le disque dur. En mode graphique, grâce à un JFileChooser, il nous est possible d uploader n importe quel fichier provenant de l ordinateur local. Fig. 1 Uploads multiples et leurs progressions : en bleu foncé les fichiers encodés et en bleu clair les fichiers normaux L amélioration la plus conséquente est sans doute la possibilité d effectuer de multiples uploads / downloads simultanément, tout en voyant l avancement de chaque opération dans une barre de progression. Le composant JProgressBar nous a pour cela rendu service. Il ne fût pas difficile de permettre les uploads et downloads multiples : il suffit en effet de démarrer un nouveau Thread à chaque download/upload. Deux problèmes se sont par contre posés : il fallait d abord trouver un moyen de définir l avancement de la barre de progression à des intervalles bien précis, puis il fallait gérer une table (ajout/suppression) contenant dans une colonne le nom du fichier, et dans l autre la barre de progression. Pour résoudre le premier problème, il nous a fallu transmettre la JProgressBar dans les méthodes upload/download de notre PeerClient, qui s occupe de les transmettre plus loin. Nous fixons le maximum de la barre de progression au nombre de bloc du fichier normal / superblocs du fichier encodé. A chaque upload/download d un 11

12 bloc/superbloc, nous mettons à jour la barre de progression et la Gui. Les barres de progressions ne sont donc pas mises à jour en temps réel, mais par intervalles de blocs/superblocs. Pour résoudre le deuxième problème, nous avons du créer une JTable avec deux colonnes dont les cellules ne sont pas modifiables (nous utilisons en fait la classe interne FileTable qui redéfinit JTable). La première, contenant les noms des fichiers, n a pas posé de problème. La deuxième colonne, quant à elle, devait pouvoir accepter des barres de progressions. Pour ce faire, nous avons redéfinit le rendu d une cellule dans une classe interne à la Gui que nous avons appelé CellRenderer, et nous avons appliqué ce rendu aux cellules de la deuxième colonne, contenant les JProgressBar. L ajout et la suppression de couples (nom du fichier, barre de progression) se font dans les Threads lancés pour les downloads/uploads. Pour la suppression d un couple, on attend six secondes après la fin de l upload/du download. Pour supprimer le bon fichier, il suffit de supprimer la première ligne qui contient le nom du fichier courant. Fig. 2 Downloads multiples et leurs progressions : en bleu foncé les fichiers encodés et en bleu clair les fichiers normaux Nous avons finalement différencié les fichiers encodés des fichiers normaux par la couleur de leur barre de progression et ajouté quelques petites icônes améliorant la convivialité du programme. Ces dernières ont été tirées d un pack d icônes du site et se trouvent dans le dossier./images/ 4.2 PeerServer et Repositories Notre PeerServer et nos Repositories acceptent les connexions multiples. C est-à-dire qu ils peuvent dialoguer avec plusieurs Peers simultanément. Pour réaliser cela, nous avons séparé chaque entité (PeerServer ou Repository) en deux classes bien distinctes : une première qui s occupe de réserver le port auprès de l ordinateur et d attendre des connexions, et une deuxième gérant tout le dialogue avec le Peer et les actions qui en découlent une fois qu une connexion a été détectée et acceptée. Chaque fois qu une connexion est acceptée, un nouveau 12

13 Thread s occupant de gérer le dialogue et les actions est lancé. 4.3 Gestion des processus Nous avons implémenté dans notre programme une gestion complète des processus. Il est ainsi possible, depuis le mode console du programme, de stopper/redémarrer le PeerServer ou les Repositories et d afficher les processus en cours. Notre PeerServer et chacun de nos Repositories disposent ainsi d une méthode stop() qui interrompt la boucle principale du processus. Comme notre PeerServer et nos Repositories acceptent les connexions multiples, il faut aussi à chaque fois créer une nouvelle connexion qui envoie un BREAK au canal qui s occupe de gérer le dialogue avec un Peer, afin que sa boucle soit aussi stoppée. 4.4 Sérialisation Cette amélioration permet à l utilisateur de garder les informations sur les fichiers qu il a uploadé d une session à l autre. C est-à-dire qu il peut sans autre stopper son programme et au prochain redémarrage de ce dernier, il n aura perdu aucune information sur les fichiers qu il proposait aux utilisateurs. Il devra simplement redémarrer un PeerServer pour les mettre à disposition des utilisateurs. Cela ne voudra toutefois pas dire que les fichiers seront téléchargeables : en effet, si les repositories sur lesquels ils ont été stockés ne sont plus actifs, il sera impossible de les récupérer. Pour pouvoir sérialiser nos fichiers, il a fallu que nos classes les représentant implémentent l interface Serializable. Quelques attributs de ces classes, tels les canaux, ont été déclaré transient afin qu ils ne soient pas sérialisés. A chaque fermeture du programme, l historique est sauvegardé dans un fichier et à chaque redémarrage, ce fichier est lu en testant le type de l objet, afin de savoir s il doit être ajouté dans la collection de fichiers encodés ou non. Le fichier de sérialisation se trouve à cet endroit :./infos/historique.serialize Nous avons aussi prévu une fonction qui permet de vider les collections de fichiers uploadés (encodés ou non) et de supprimer le fichier de sérialisation. 4.5 Hack Cette amélioration est un petit clin d oeil au concepteur du Directory. Ce dernier ne contrôle en effet pas l identité de la personne pour certaines opérations. Il est ainsi possible d effacer tous les PeerServer et Repositories du Directory. Pour ce faire, il faut dans un premier temps récupérer la liste des PeerServer et des Repositories (avec les commandes PEERSERVERNAMES et REPO- SITORYINFO ). Pour chaque PeerServer différent du nôtre, nous créons une nouvelle connexion avec le Directory (envoi de HELLO et du nom désiré), puis nous lui envoyons un BREAK avant de fermer le canal. De cette manière, le Directory supprime le PeerServer désiré. Il est encore plus simple de supprimer les Repositories. En effet, en ayant le nom d un Repository, il suffit d envoyer la commande UNREGISTERREPOSITORY au Directory, suivi de son nom. Il sera alors effacé. 13