:: Enseignements :: Master :: M1 :: 2008-2009 :: Architecture et Programmation Réseau ::

Projet d'Architecture et Programmation Réseau

TCSMP - Time-Cost Stamped Mail Protocol

Le but de ce projet est d'étudier comment un protocole de transport de mail pourrait limiter la profusion de mails indésirables en faisant payer à l'expéditeur le temps (CPU) de résolution d'un problème automatiquement soumis par le destinataire. L'objectif est de réfléchir aux contraintes d'un tel protocole, de le définir sous la forme d'une RFC et d'en implanter un prototype en Java.

Avertissement: ce sujet de projet peut évoluer à tout moment pour corriger des erreurs ou apporter des précisions. Vérifiez régulièrement sur ce site sa version.

version 1.4 au 17 mars 2009 à 15h
version 1.3 au 11 mars 2009 à 15h30
version 1.2 au 6 mars 2009 à 17h30
version 1.1 au 6 mars 2009 à 15h30
version 1.0 du 26 février 2009 à 10h30

Idée

Pour réduire la quasi impunité des spammeurs, on souhaite mettre en place un protocole de mail qui impose à l'expéditeur de dépenser un peu de temps en résolvant un puzzle. Ainsi, le temps consacré à la résolution du puzzle est vu comme le timbre d'une lettre classique, car s'il faut passer 1 ou 2 secondes à résoudre un puzzle pour chaque mail envoyé, ça pénalisera fortement ceux qui envoient massivement des mails, sans gêner l'utilisateur normal.

Le principe est le suivant :

X veut écrire à Y@BINIOU
X contacte son propre serveur d'envoi POUET
POUET trouve l'adresse du serveur BINIOU et lui demande un puzzle
BINIOU fournit un puzzle
POUET transmet ce puzzle à X
X résout le puzzle et envoie la solution à POUET
POUET envoie le mail de X et la solution du puzzle à BINIOU
BINIOU vérifie la solution et, si elle est correcte, stocke le message pour que Z puisse le lire (par exemple sur un serveur mail classique)

Les puzzles seront de type Eternity: des grilles où chaque case contient 4 symboles (nord,sud,est,ouest), de telle sorte que les symboles contigus pour 2 cases côte à côte soient identiques.

Exemple à 6 cases:

 A    Z    E
E P  P R  R L
 B    X    G
 
 B    X    G
H A  A F  F S
 Q    B    I

Ce genre de puzzle est facile à générer, dur à résoudre (complexité exponentielle), et il est très rapide de tester si une solution est correcte. Le serveur de BINIOU doit donc générer des puzzles, mélanger les pièces et l'orientation de chaque pièce, et envoyer le puzzle au serveur POUET.

Des petits détails intéressants

Au delà de ces concepts plutôt simples, il y a différents problèmes auxquels il peut être intéressant de prêter attention. En voici quelques uns qui peuvent être complétés:

Indépendamment de la manière d'implémenter la génération du puzzle et sa résolution, il est fondamental de s'assurer que la solution fournie par le client est "juste" pour autoriser l'envoi effectif du courrier.
Est-il possible d'imposer un "coût" de timbre (temps ou complexité de traitement) proportionnel à la taille du courrier envoyé.

Ce qu'il faut faire

L'objectif est de réfléchir aux principes de fonctionnement d'un tel mécanisme et aux protocoles nécessaires à sa mise en place. Vous pourrez avantageusement vous inspirer de ce qui est utilisé pour le fonctionnement des mails actuels défini par la RFC 5321 qui standardise le protocole SMTP (voir également le site de RFC Editor).

Tout en étant conscient du temps dont vous disposez, et sans nécessairement prendre en compte la totalité des fonctionnalités disponibles dans SMTP, vous devrez définir une RFC (en anglais et en mode texte au format des autres RFC) définissant votre protocole TCSMP (Time-Cost Stamped Mail Protocol). Rappelons que le principe d'une RFC est que si deux implantations complètement indépendantes l'une de l'autre respectent la même RFC, elles doivent être compatibles et pouvoir communiquer.

Bien sûr, pour valider le principe de votre protocole, vous serez amenés à réaliser des prototypes d'impantation. La seconde partie de ce projet consistera donc à réaliser en Java trois applications distinctes (même si elles partagent des classes communes):

un client TCSMP qui fait office de mailer, capable de résoudre les puzzles;
un serveur sortant TCSMP qui relaie les messages postés par le client et les puzzles retournés par le serveur TPOP;
un serveur TPOP qui fournit les puzzles, vérifie les solutions et achemine les messages à destination si les puzzles sont correctement résolus.

Rendu initial

Le projet est à réaliser par groupes de 4 personnes.

Pour le 22 mars 2009 au plus tard, vous devrez rendre par mail un document décrivant le protocole envisagé en français (format texte ou pdf à l'exclusion de tout autre format). L'idée est que vous vous consacriez sur le fond (le principe et la définition du protocole) plutôt que sur l'anglais et la mise en forme.

Dans le même temps, vous pourrez avantageusement préparer à rédiger votre RFC au format texte et en anglais car elle sera due sous cette forme dans le rendu final. De même, rien ne vous empêche de réaliser des petits prototypes pour valider la faisabilité de telle ou telle fonctionnalité et c'est même fortement conseillé, mais il ne vous sera pas demandé de rendre de code à cette étape.

Le document en français à rendre le 22 mars doit établir clairement l'objectif du protocole, son principe de fonctionnement et le format des données qui sont échangées (protocole de transport utilisé, format, encodage, codes d'opérations, etc.). Il ne doit en aucun cas faire des hypothèses sur la manière de réaliser une implantation de ce protocole, ni en terme de langage de programmation, ni en terme d'architecture de l'application.

Un mail sera envoyé, depuis le compte @etudiant.univ-mlv.fr de l'un des membres du groupe, aux enseignants de la matière avec comme sujet "Initial TCSMP Java Reseau M1". Le corps du mail indiquera les noms et prénoms des différents membres du groupe. Le fichier (texte ou pdf) du document sera attaché à ce mail et les noms et prénoms des auteurs devra être rappelé au début de ce fichier.

Rendu final

Avant même le rendu initial, vous devrez commencer à réaliser des applications Java votre protocole et sa RFC. En matière de communication, ces applications devront respecter scrupuleusement la RFC que vous établirez. Dans le cas où vous seriez amené à changer les principes et la définition du protocole entre le rendu initial et la RFC ou les applications, vous détaillerez dans un document annexe l'ensemble des évolutions avec leur justification.

Pour le 12 avril 2009 au plus tard, et sachant que les soutenances des projets auront lieu l'après-midi du 14 avril, vous devrez rendre une archive au format zip (tout rar, tar.gz, 7z et autre ne sera pas ouvert) contenant:

un répertoire src contenant les sources du projet et les éventuelles ressources (images, etc.) à recopier à côté des classes;
un répertoire docs contenant un manuel de l'utilisateur (user.pdf) permettant d'installer, prendre en main et utiliser vos applications ainsi qu'un manuel qui explique votre architecture (dev.pdf), les deux manuels au format PDF;
un répertoire rfc contenant la RFC (format texte ASCII). Dans le cas où des modifications auraient dû être effectuées dans le principe ou la définition du protocole établis lors du rendu initial, vous fournirez un document evolutions.pdf justifiant chacune des modifications que vous avez été contraint d'apporter.
des jar exécutables clientTCSMP.jar, serverTCSMP.jar et serveurTPOP.jar pour un client et un serveur TCSMP dans votre implantation.
un build.xml qui permet de
- compiler les sources (target compile)
- créer les jar exécutables nécessaires (target jar)
- générer la javadoc dans docs/doc (target javadoc)
- nettoyer le projet pour qu'il ne reste plus que les éléments demandés (target clean)
un répertoire lib contenant les éventuelles bibliothèques dont a besoin votre projet pour fonctionner.

Cette archive zip aura comme nom Nom1Nom2Nom3Nom4_TCSMP.zip, où les noms sont ceux des membres du groupe par ordre alphabétique. L'extraction de cette archive devra créer un répertoire de nom Nom1Nom2Nom3Nom4_TCSMP pour contenir tous les éléments demandés ci-dessous. Vous l'attacherez en pièce jointe à un mail envoyé depuis le compte @etudiant.univ-mlv.fr de l'un des membres du groupe aux enseignants de la matière avec comme sujet "Rendu final TCSMP Java Reseau M1" avec dans le corps du message les noms et prénoms de chacun des membres du groupe.

Attention: vérifiez bien que votre archive soit la plus légère possible au moment du rendu (pas de javadocs), qu'elle s'extrait correctement dans un nouvel environnement et que toutes les cibles du build.xml fonctionnent correctement.

Soutenance

Lors de votre soutenance (qui aura lieu l'après-midi du 14 avril 2009), 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é.