:: Enseignements :: Licence :: L3 :: 2012-2013 :: Programmation Objet avec Java ::
[LOGO]

Ghosty


Le but de ce projet est de fabriquer un programme qui repliquera le contenu d'un répertoire (et des ces sous-répertoires) sur le Cloud, au moins sur Google Drive, en cryptant le contenu (RSA 2048, par défaut) au passage.

Condition de rendu

Ce projet est à faire par binome (2 personnes, ni 1 ni 3) et doit être envoyer par mail au plus tard le 31 décembre 2011 à 23h59 aux adresses forax@univ-mlv.fr et jerome.pilliet@upe.fr.

Cahier des charges

Le programme doit après être lancé doit synchroniser le contenu du répertoire (et des ses sous-répertoire) avec un système de stockage de fichier sur internet. Pour éviter tous problème de piratage, les fichiers stockés sur le cloud seront encryptés en utilisant l'algorithme RSA.
Lors du premier lancement du programme, l'utilisateur devra spécifier un répertoire de synchronization, les informations nécessaires concernant Google Drive et le keystore (là où sont stockées les clés RSA). Si le keystore n'est pas spécifié, ghosty créera celui-ci en demandant une phrase secrète permettant de générer les deux clés RSA.
Le programme créera alors un fichier .ghosty/conf.txt dans le répertoire de synchronisation avec toute les informations nécessaires à la synchronisation (bien sûr, ces informations ne seront pas synchronisées).
La synchronisation doit avoir lieu dans les deux sens, toutes modifications sur l'ordinateur local doit être sauvegardées sur le cloud et toutes modifications sur le cloud doit être répercutées sur le disque local. Le scénario suivant doit donc fonctionner, si un utilisateur se loge sur deux ordinateurs différents toutes modifications sur l'un des ordinateurs doit être répercutées sur l'autre.
Le programme doit pouvoir fonctionner en mode offline. C'est à dire, même si des modifications sur le répertoire de synchronisation sont faite alors que le programme ghosty ne fonctionne pas. Ghosty devra re-synchonizer toutes les modifications qui ont été effectué lorsque le programme sera de nouveau lancé. Le programme utilisera pour détecter les changement une base de signatures au format MD5.
Voici la liste des fonctionnalités du logiciel
  • Le fichier de configuration, le .ghosty/conf.txt, doit être au format en XML.
    ghosty --clean force une ré-installation et donc écrase le contenu du .ghosty s'il existe déjà.
    Lors d'une modification du fichier de configuration, le programme doit se mettre à jour automatiquement sans re-démarrage de l'application ghosty.
  • ghosty --debug doit permettre de lancer ghosty sans qu'il encrypte les fichiers, juste pour tester.
  • Lors d'un erreur de synchro, celle-ci est journalisé dans le fichier log du répertoire .ghosty (.ghosty/log.txt). Les erreurs au démarrage sont écrites sur la sortie d'erreur standard pas dans le fichier de log !
  • Un utilisateur peut déposer un fichier directement sur le cloud et si celui-ci est placé dans le bon répertoire, il sera pris en compte par ghosty et sera alors automatiquement encripté.
  • Le programme doit avoir une base de signatures de fichiers au format MD5 pour détecter les modifications.
    La gestion en local et sur le cloud de cette base est laissé à votre discretion. Et bien sûr, vous ne devez pas avoir la même que celle d'un autre binôme.
  • Une seule instance du programme ghosty devra tourner sur un ordinateur, pour cela le programme .ghosty devra utiliser un verrou sur le fichier .ghosty/lock. Le verrou sur le fichier devra être rendu au système de fichier si le programme est intérrompu par un Control-C ou en cas de terminaison normale.
  • Optionnellement, ghosty devra implanter un algorithme particulier pour les gros fichiers, plus de 256 méga-octets (256 * 1024 * 1024 octets). Il faut considérer les gros fichiers comme une suite de parties chacune ayant son MD5, le fichier ne devra pas être découpé ni sur le disque local ni sur le cloud, mais uniquement géré comme une série de partie pour le calcul du MD5 par le programme.

Références

Google Drive SDK
Java Crypto API
Java XML Processing API
Jar Archive (JAR) Files
JavaDoc spec
et la javadoc des classes java.nio.file.Path, java.nio.channels.FileChannel et java.nio.file.WatchService.

Conditions de rendu

Le projet est à rendre par mail aux chargés de TD et à l'enseignant de cours, au plus tard le 31 décembre à 23h59. Le format de rendu est une archive au format zip (tout rar, tar.gz, 7z et autre ne sera pas ouvert) contenant:

Cette archive Zip (attention à l'encodage) aura comme nom Nom1Nom2_Ghosty.zip, où les noms sont ceux des membres du binôme par ordre alphabétique. L'extraction de cette archive devra créer un répertoire de nom Nom1Nom2_Ghosty pour contenir tous les éléments demandés ci-dessus. Elle sera envoyée par mail aux enseignants de la matière, avec dans le corps du message les noms et prénoms de chacun des membres du binôme.

Notation