:: Enseignements :: ESIPE :: E4INFO :: 2010-2011 :: Applications réseaux ::

Projet Transfile

Note préliminaire : ce document n'est pas forcément une version définitive et est susceptible d'évolutions.

Le projet est à réaliser par groupes de 2 personnes (un binôme). Un seul groupe de 3 personnes sera admis. Dès que possible, faites connaître votre binôme à l'enseignant de cours, par mail. Vous vérifiez ensuite que vous êtes bien dans la liste des binômes enregistrés.

Nous souhaitons réaliser un serveur proposant des fichiers en téléchargement ainsi qu'un client permettant de les récupérer. Deux variantes protocolaires doivent être compatibles : la première utilise une connexion TCP pour chaque client téléchargeant tandis que la seconde emploie le protocole UDP en multicast dans le cas où plusieurs clients désirent obtenir le même fichier.

Connexion TCP

Serveur de fichiers

Le serveur de fichiers propose en téléchargement les fichiers présents dans un répertoire communiqué et son arborescence. Chaque fichier peut être récupéré en différents tronçons définis par le décalage de son premier octet ainsi que sa taille en octets. Il est nécessaire de pouvoir explorer l'arborescence de fichiers.

Un client souhaitant explorer l'arborescence (lister les enfants d'un répertoire avec des détails tels que leur nom, taille et date de modification) ou télécharger des tronçons doit ouvrir une connexion TCP sur le serveur et lui communiquer des commandes auxquelles il répondra. On proposera un protocole simple sous la forme d'une RFC (en français ou en anglais) pour réaliser ces opérations.

Le serveur doit pouvoir gérer plusieurs connexions avec différents clients simultanément. Il devra maintenir des statistiques de téléchargement qui pourront être obtenues avec une commande spécifique. Elles mentionneront les volumes globaux de données échangées (en émission et réception) ainsi que pour chacun des fichiers servis.

Programme Le serveur sera exécutable via une fonction main implantée dans la classe fr.upemlv.transfile.server.FileServer et acceptera (au moins) les arguments suivants :

-p port : port d'attache du serveur
-a adresse : adresse d'attache du serveur (par défaut l'adresse joker nulle si celle-ci n'est pas spécifiée)
-d racine : répertoire racine de l'arborescence de fichiers servie
-r débit : débit maximal servi pour l'ensemble des connexions en octets par seconde (implantation facultative)

Lorsque le serveur reçoit par la JVM un signal de terminaison, celui-ci doit signaler proprement son extinction aux clients et couper ensuite les connexions. Il écrit ses statistiques dans un fichier server-statistics.

Améliorations De nombreuses améliorations sont imaginables dont par exemple la possibilité de compresser les tronçons à envoyer ou alors de faire jouer également à des clients téléchargeurs un rôle de serveur (partage de fichiers de type BitTorrent).

Client récupérateur de fichiers

Le client implanté devra être compatible avec le protocole défini dans la RFC et utilisé par le serveur. Il devra être capable de télécharger un fichier en plusieurs tronçons et de résister aux coupures de connexion TCP en relançant le téléchargement.

Script Le client utilise un petit langage de script dont les commandes sont communiquées sur l'entrée standard System.in. Ce langage devra comprendre au moins les commandes suivantes :

cd répertoire : changement de répertoire courant sur l'arborescence du serveur (avec support des chemins relatifs et absolus, le répertoire racine étant /), le répertoire courant de départ étant la racine
ls : affichage du contenu du répertoire courant (un fichier/répertoire par ligne avec ses détails)
get fichier : lancement du téléchargement du fichier précisé dans le répertoire courant du serveur
get-multicast fichier : lancement du téléchargement en multicast (voir section suivante)
status : affichage de tous les fichiers en cours de téléchargement avec leur progression, chaque tâche étant identifiée par un entier
kill tâche : tue la tâche de téléchargement dont l'entier est spécifié

Tous les fichiers sont enregistrés sous le répertoire courant de lancement du client mais en respectant l'arborescence du serveur. Par exemple, si l'on télécharge le fichier /java/javadoc/index.html sur le serveur et que le client est lancé sous ~/tmp, le fichier est créé à l'emplacement ~/tmp/java/javadoc/index.html (il faudra créer les répertoires intermédiaires si nécessaire). Lorsqu'un téléchargement est tué, les données temporaires ne sont pas effacées et pourront être réutilisées afin d'éviter de retélécharger des tronçons déjà obtenus.

Programme Le client est implanté dans la classe fr.upemlv.transfile.client.FileClient et accepte comme premier argument le nom d'hôte du serveur et pour second son numéro de port.

Connexion multidiffusion UDP

Attention: dans le cadre de l'utilisation du multicast dans les salles de TP de l'université, il ne faut pas utiliser des adresses dans la plage 224.0.0.0 - 224.0.0.255 qui sont normalement utilisées pour les annonces et le routage multicast. Vous pouvez regarder pour plus de détail l'URL http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml#multicast-addresses-13 Dans le cadre de votre projet, vous vous limiterez à l'utilisation des adresses dans la plage 239.252.0.0 - 239.255.255.255. Par ailleurs, ne tentez pas de changer le TTL qui doit être à 1 par défaut.

Votre compréhension de ces exigences et le respect de ces consignes sont indispensables au bon fonctionnement du réseau dans l'université. Merci de faire preuve de responsabilité pour nous permettre de continuer à offrir la possibilité de tester ce genre de programme ailleurs qu'en environnement "clos" (salles de TP réseau par exemple).

Le mode multidiffusion en UDP permet au serveur d'envoyer le contenu du fichier sous la forme de datagrammes expédiés en un seul exemplaire à un groupe de multicast. Ce mode est intéressant si plusieurs clients souhaitent télécharger simultanément le même fichier. Toutefois il présente certains inconvénients. Le serveur impose une cadence d'envoi pouvant créer des congestions : certains clients en écoute sur le groupe peuvent ne pas recevoir certains paquets.

Le serveur découpe les fichiers à envoyer en tronçons de taille compatible avec un datagramme UDP. Le serveur envoie séquentiellement au groupe de multidiffusion les tronçons numérotés de 0 à n-1 : à l'issue de l'envoi du tronçon n-1, on reprend l'envoi au tronçon 0. Ainsi un client s'étant abonné au groupe et ayant reçu initialement le tronçon i réceptionnera les tronçons i à n-1 puis les tronçons 0 à i-1. Il pourra ensuite se désinscrire du groupe de multidiffusion et constater s'il lui manque ou non des tronçons. Si c'est le cas, il devra redemander l'expédition de ces tronçons en mode TCP.

Le serveur choisit une adresse de groupe de multidiffusion par fichier servi (sans toutefois sortir de la plage d'adresse 239.252.0.0 - 239.255.255.255). Un client demande le téléchargement en multidiffusion depuis sa connexion TCP avec le serveur qui lui communique l'adresse du groupe. Pour éviter des "conflits" ou des trames parasites, vous pourrez utiliser pour chaque binôme une plage dédiée à votre binôme: le binôme numéro N pourra utiliser toutes les adresses dans la plage 239.252.N0.0 - 239.255.N9.255, par exemple 239.252.10.0 - 239.255.19.255 pour le binôme numéro 1, ou encore la plage 239.252.190.0 - 239.255.199.255, pour le binôme numéro 19. Voir la liste des binômes enregistrés pour les plages de chaque binôme.

Consignes et conseils

Ce projet est un travail à faire en binôme. On rappelle qu'un binôme est constitué d'exactement deux personnes travaillant de manière équitable sur le projet. La note des deux membres du binôme pourra être différente à l'appréciation du correcteur.
Il est conseillé de traiter le projet par étapes. La première consiste à élaborer la RFC en envisageant les differents cas de figure et en essayant de se focaliser sur le protocole (nature, format et séquentialité des échanges), en faisant abstraction de la manière dont les programmes implantant cette RFC seront codés ou utilisés. La RFC devra clairement distinguer les échanges réalisés en TCP et ceux en UDP. Ensuite (et probablement un peu en même temps, il semble raisonable d'implanter le serveur en TCP puis le client en TCP, en utilisant un seul fil d'exécution puis plusieurs. Le mode multidiffusion UDP ne sera abordé que lorsque le mode TCP unicast fonctionnera correctement. Toute amélioration ne pourra être prise en considération que si les fonctionnalités de base demandées sont implantées.
La gestion des entrées/sorties (E/S) sera réalisée à l'aide de classes des paquetages java.{io,nio}. La gestion des fichiers et de leur chemins peut être facilitée avec la classe java.io.File. La classe java.io.RandomAccessFile pourra être utilisée pour les opérations d'E/S non séquentielles sur les fichiers.
Les arguments et commandes indiqués doivent être respectés scrupuleusement, les programmes rendus étant susceptibles d'être testés automatiquement par des scripts.
Les sources doivent être claires, commentées, organisées en paquetages et le découpage en classes doit être judicieux. Les sources ne peuvent dépendre que de l'API standard du JDK (paquetage java). La copie de code depuis une source externe ou entre des binômes différents n'est pas autorisée (des tests pourront être réalisés). La génération d'une javadoc sera prévue et fonctionnelle. La présence d'un fichier README.TXT décrivant la compilation et l'exécution des programmes est nécessaire. Un script de compilation doit être présent (fichier ANT build.xml) prévoyant au minimum:
- une tâche de compilation (target compile)
- une tâche de génération de la javadoc (target javadoc)
- une tâche de génération des jar exécutables nécessaires (target jar)
- une tâche de nettoyage pour qu'il ne reste plus que le minimum (target clean)
Un rapport au format PDF d'une dizaine de pages devra être inclus. Il décrira l'architecture, les choix d'implantation et les difficultés rencontrées ainsi que les éventuelles limitations, bugs et améliorations; il contiendra une section sur la répartition du travail entre les membres du binôme. Une RFC décrivant le protocole devra également être écrite (en anglais).
Le projet est à rendre sous forme d'archive zip ne contenant que le minimum (tout ce qui peut être généré doit être supprimé: penser à faire un ant clean avant de générer l'archive) avant la date limite du 5 juin 2011 par courrier électronique expédié à etienne.duris AT univ-mlv.fr ainsi qu'à michel.chilowicz AT univ-mlv.fr et à arnaud.carayol AT univ-mlv.fr depuis le webmail de l'université avec pour sujet Transfile IR2: login1 login2 où login1 et login2 sont les logins des deux membres du binôme.

Remise du projet

Le projet consiste à concevoir la RFC et à programmer le serveur et client demandés. L'évaluation sera basée sur (i) , (ii) les codes sources de ce que vous avez fait, (iii) la qualité de votre soutenance et (iv) le rapport finalqui devra contenir entre autres :

la RFC du protocole,
les codes sources de vos programmes et leur documentation,
la qualité de votre soutenance,
le rapport

Vous devez rendre deux livrables:

une version préliminaire (la plus aboutie possible) de la RFC, au plus tard le 8 mai 2011; cette RFC, au format fichier texte, sera envoyée par mail à etienne.duris AT univ-mlv.fr ainsi qu'à michel.chilowicz AT univ-mlv.fr et à arnaud.carayol AT univ-mlv.fr depuis votre mail de l'université avec pour sujet Transfile IR2: login1 login2 où login1 et login2 sont les logins des deux membres du binôme.
une archive zip devra être déposée le 5 juin à 23h59 au plus tard sur un dépôt sur etudiant :
/home/shares/igm/prof/XXXX qui vous sera bientôt précisé.
Ce zip contiendra l'ensemble de votre projet (sources, rapport, README.txt, RFC finale, paramètres, etc.), mais ce qui peut être généré doit être supprimé: penser à faire un ant clean avant de générer l'archive.
Le zip aura un nom formé à partir de vos noms (par exemple, si vous vous appelez Toto et votre binôme Tartenpion, le zip doit être nommé TotoTartenpion.zip). L'extraction de cette archive devra créer un répertoire du nom de l'archive pour contenir tous les éléments demandés ci-dessus (dans l'exemple, un répertoire TotoTartenpion).

Cas de pénalités (non exhaustifs):

RFC ou projet rendu en retard
Archive qui n'a pas le nom demandé
Extraction du zip ne produisant pas le répertoire demandé

Soutenance

Une soutenance sera organisée où vous devrez utiliser l'archive zip rendue par mail et présenter une démonstration que vous aurez préparée et testée dans les salles de TP de l'université.