Pire2Pire

Année 2006-2007

Enseignants: E. Duris, S. Paumier, G. Roussel

duris at univ-mlv.fr, paumier at univ-mlv.fr, roussel at univ-mlv.fr

Date de dernière mise à jour : 14 mars 2007

Présentation générale

On souhaite concevoir et mettre en oeuvre un système de téléchargement partagé de fichiers. L'idée est de découper chaque fichier en plusieurs fragments. Un client TOTO qui souhaite télécharger le fichier BINIOU doit demander à un serveur les informations sur ce fichier : en combien de fragments le fichier BINIOU est découpé et, pour chaque fragment, l'ensemble des clients qui le possèdent.

Le client TOTO est ensuite libre de choisir chez quels clients il va récupérer les différents fragments afin d'obtenir l'intégralité du fichier BINIOU. De plus, dès que TOTO a récupéré un fragment de BINIOU, il devient à son tour un distributeur possible de ce fragment.

Ce système sera constitué de deux types d'entités:

Chaque serveur de cartographie est en possession d'informations sur les autres serveurs et sur un ensemble de fichiers que lui seul cartographie. Par conséquent, pour un fichier donné, il ne doit y avoir qu'un seul serveur le cartographiant, c'est-à-dire, maintenant à jour pour chaque fragment des fichiers qu'il gère, la liste des clients possédant ce fragment.

Un client possède une liste initiale (qui peut être complétée) de serveurs de cartographie à contacter. Chaque fragment qu'il détient est associé à un fichier dont il connaît le serveur de cartographie.

Principales opérations

Problèmes à résoudre

Etant donné qu'un seul serveur de cartographie est admis par fichier partagé, il faut gérer le cas où ce serveur meurt. Chaque client partageant des fragments de fichiers devra tester périodiquement si les serveurs gérant ces derniers sont toujours en vie. Si ce n'est pas le cas pour le serveur de cartographie d'un fichier POUET, le client devra choisir à sa convenance un autre serveur de cartographie pour le fichier POUET.

Attention, plusieurs clients possédant les fragments de POUET peuvent hypothétiquement confier la cartographie de POUET à des serveurs différents. Il faut donc prévoir un mécanisme de communication entre les différents serveurs pour assurer l'unicité de la gestion de chaque fichier.

De même, si un client meurt, ses fragments ne sont plus accessibles. Les serveurs de cartographie des fichiers qu'il possédait doivent donc gérer cette disparition.

Travail demandé

Ce projet est à faire en binôme (cela veut dire deux personnes pas trois ni une). Pensez à [re-]lire les conseils décrits dans la charte des projets d'informatique.

Vous devez écrire une RFC qui décrive tous les protocoles à mettre en oeuvre pour réaliser ce système. Cette RFC (un document texte en ASCII rédigé en anglais) doit se contenter de décrire le mode de communication entre les entités intervenant. En aucun cas, elle ne doit détailler l'implantation d'un serveur de cartographie ou d'un client peer. La date de rendu de cette RFC est le lundi 26 mars 2007, 9h00 du matin, par mail aux adresses spécifiées en haut de cette page, avec comme sujet "projet réseau M1" et comme pièce jointe la RFC de nom nom1_nom2_RFC.txtnom1 et nom2 sont les noms respectifs des personnes formant le binôme triés dans l'ordre alphabétique.

Dans un deuxième temps, vous devrez implémenter au moins un client et un serveur en Java respectant votre RFC. Ces implémentations prendront la forme de fichiers Jar exécutables pire2pire_client.jar et pire2pire_serveur.jar.

Le rendu s'effectuera également par mail sous forme d'une pièce jointe au format ZIP contenant l'ensemble des programmes et documents, avant le lundi 23 avril 2007, 9h00 du matin. Le mail devra être envoyé aux trois adresses mail données au début de ce document. Le fichier s'appellera nom1_nom2.zip - nom1 et nom2 étant les noms respectifs des personnes formant le binôme triés dans l'ordre alphabétique.

Voici les noms des répertoires et fichiers qui doivent être contenus dans l'archive zip.

  1. un fichier readme.txt indiquant comment compiler le programme et l'exécuter, où se trouve la documentation, etc.
  2. un fichier Ant build.xml permettant de compiler les sources du programme, et de créer les jars exécutables des serveurs et clients dans bin.
  3. un répertoire src contenant l'ensemble des sources (.java).
  4. un répertoire classes contenant l'ensemble des classes (.class) correspondant aux sources.
  5. un répertoire docs contenant quatre documents :
    1. La RFC (au format texte ASCII, en anglais) du premier rendu.
    2. La RFC (au format texte ASCII, en anglais) correspondant aux jar exécutables livrés (ayant éventuellement été modifiée).
    3. La documentation utilisateur (au format PDF) user.pdf décrivant comment compiler, exécuter, utiliser l'application.
    4. La documentation (au format PDF) développeur dev.pdf contenant :
      • La description des avantages/inconvénients de votre RFC, et les raisons de ses évolutions éventuelles depuis la première version.
      • La description des avantages/inconvénients/problèmes connus de vos implémentations.
    En plus des deux documents, le répertoire docs devra contenir un sous répertoire api contenant la documentation complète du logiciel au format javadoc.