TCSMP - Time-Cost Stamped Mail Protocol

Transcription

1 Projet de Master Informatique M1 Université Paris-Est Marne-la-Vallée Session TCSMP Time-Cost Stamped Mail Protocol TCSMP - Time-Cost Stamped Mail Protocol Documentation utilisateur,,,

2 Introduction... 3 I) Conception... 4 II) Client... 6 III) serveur TCSMP et TPOP... 8 A) Serveur TCSMP (relais)... 8 B) Serveur TPOP... 9 Conclusion

3 Introduction L'objectif de ce projet est de définir un protocole, et sa RFC associée, qui permettrait de limiter l'envoie de mails indésirables. Pour cela on fait payer un coût à l'envoie du mail, le prix à payer est du temps CPU. L'expéditeur du mail doit résoudre un ou plusieurs "puzzles" envoyés par le ou les serveurs de destination et lui renvoyer pour avoir le droit de transmettre son . La résolution d'un puzzle doit prendre quelques secondes par courrier électronique. Ainsi pour l'utilisateur courant, cela est transparent. Mais par contre cela pénalise très fortement un envoie massif de mails. L'implantation de ce protocole est codé en java et est expliquée dans le présent document

4 I) Conception Nous avons choisi de faire une extension de la RFC 5321 plutôt qu'un protocole indépendant car notre protocole est très proche de SMTP et que nous pouvons ainsi être plus facilement compatible avec les serveurs de mail ne suivant pas notre extension. Il s'agit donc de faire payer un coût à l'expéditeur du mail. Pour cela il est judicieux de trouver une méthode qui ne coûte du temps qu'au client, et pas au serveur. C'est pour cela que les puzzles sont intéressants. Les puzzles sont similaires à ceux du jeu "eternity", sauf que les symboles des différentes faces sont représentés par des caractères. Pour résoudre un puzzle de ce type, on doit mettre les pièces dans l'ordre pour que chaque face adjacente ait le même symbole. L'intérêt de ce type de puzzle est que la résolution est dur (complexité exponentielle), et il est très rapide de tester si une solution est correcte. On connait donc le temps moyen de résolution d'un puzzle selon sa taille, et cela permet de faire varier celle-ci selon le nombre de message envoyé par le client. En ce qui concerne la génération du puzzle, on se base sur l'algorithme suivant: Soit un puzzle de taille [2,2], on construit un tableau de taille [2* 2+1, 2+1] contenant des lettres tirée aléatoirement. Puis pour générer chaque pièce, on utilise la méthode suivante A D E F T Y V S G H X N C C C On obtient les pièces suivantes : A D F T T Y V S V S H X X B C C - 4 -

5 La résolution ce base sur l'algorithme "Brute Force", on teste l'ensemble des solutions possibles. On prend une pièce parmi les pièces disponible, on la place. On prend une suivante, on essaye de la placer et un ainsi de suite. Si on arrive à un blocage, aucune pièce ne peut être placé, on retire alors la pièce précédente, et on recommence en essayant de placer une autre pièce. Ceci jusqu'a trouver la bonne solution. Ce qui prend un certain temps

6 II) Client Notre protocole TCSMP, étant une extension du protocole SMTP, exige du client qu'il attende la réponse complète du serveur (qui peut être sur plusieurs lignes) avant de lui demander une autre commande. C'est pourquoi nous avons choisis de le faire en mode bloquant, avec une seule thread pour l'écoute et l'écriture. Le client ne pouvant ainsi pas passer à l'état suivant tant que la réponse n'était pas complètement arrivée. La classe Mailer gère la connexion avec le serveur. Une fois la connexion effectuée, elle délègue l'envoie du mail a la classe MAILService qui va communiquer avec le serveur et envoyer le mail. Toutes les informations contenu dans le mail sont stocké dans la classe Mail qui permet aussi de formater l'entête au format mime et d'encoder le message dans le bon Charset. Pour la communication avec le serveur, nous avons utilisé le design pattern State afin de rendre notre client modulaire et ainsi prévoir l'ajout de nouveau état (pour implémenter d'autres protocole d'extension de SMTP par exemple). Avec un état de QUIT, qui informe le serveur que le client va quitter (avec la commande QUIT) et ferme proprement les flux. Si jamais le serveur répond une erreur ou un message inattendu, notre client va directement dans l'état QUIT afin de fermer la connexion, le problème venant forcement du serveur puisque notre client respecte scrupuleusement la RFC. Nous avons également un état "puits" appelé lorsqu'un problème de connexion survient (fermeture par le serveur ou problème matériel) qui ferme tout simplement les flux de lecture et d'écriture pour clore proprement la connexion

7 Voici les états que nous avons mit en place pour respecter notre protocole. «L état d initialisation», c est lui qui débute l envoie des mails. Il débute par l attente du message de bienvenue du server. Ensuite il envoie «EHLO» au serveur. Puis il attend la réponse du serveur: les services qu il prend en compte. Si le serveur nous envoie autre chose que «250», on passe à l état «Quit». Sinon, on passe dans l état «domaine défini». En cas d exceptions, on passe à l état «fermeture de connexion». «domaine défini» Cet état s occupe d envoyer au serveur la commande «MAIL FROM», l adresse de l expéditeur. Puis on attend ca réponse, si il nous retourne «250» on passe à l état «d envoie des destinataires». Sinon, on passe à l état «Quit» «envoie des destinataires» Cet état s occupe d envoyer au serveur les destinataires du mail. Pour chaque destinataire, on envoie la commande «RCPT TO : <adresse >». Si le serveur valide tous les destinataires, on passe dans l un de ses états : o Si le serveur possède le service TCSMP, on passe à l état «envoie de la taille du message» o Sinon, on passe à l état «envoie des données» En cas d erreur on passe dans l état «Quit». «envoie de la taille du message» Cet état consiste à envoyer au serveur la taille du mail (en tête + corps du message). Si le serveur nous renvoie une erreur, on passe dans l état «Quit» Sinon, le serveur nous confirme qu il a bien reçu la taille et qu elle est valide, on attend qu il nous renvoi un puzzle. Si il nous renvoie bien un puzzle, on le stock et on passe à l état «résolution de puzzle». Sinon, on passe dans l état «Quit». «résolution de puzzle» Durant cet état, on résout le puzzle stocké par l état précédent. Ensuite, on renvoie la solution. La réponse du serveur peut être l une des suivantes : o Une erreur, la solution envoyée n est pas correcte. On passe dans l état «Quit» o Un nouveau puzzle à résoudre, on le stock et on repasse dans le même état ; o «250», la solution est correcte. Plus de puzzle à résoudre, on passe dans l état «envoie des données» «envoie des données» C est le dernier état, c est lui qui s occupe de l envoie des données du mail au serveur

8 III) serveur TCSMP et TPOP Dans la mesure où le service fournit par un serveur est basé sur une succession d'état, il s'est avéré pertinent d'utiliser le design pattern state afin de concevoir les différents serveurs. Les deux serveurs sont composés des sept états similaires à ceux du client. A) Serveur TCSMP (relais) Le serveur relais, est le serveur intermédiaire entre le client et le ou les serveurs finaux. Son but est de communiquer avec chacun des serveurs TPOP qui ont au moins un destinataire. Afin de mettre en pratique les avantages liés à l'utilisation des sélecteurs le serveur relais se résume à l'exécution de la thread main couplée à l'utilisation d'un sélecteur. Le choix de cette architecture impose de fait des lectures et écritures non-bloquantes. Notre protocole étant basé sur le concept de ligne, il a fallu s'assurer de récupérer des lignes complètes et donc de se munir d'un tampon. Le serveur TCSMP étant un relais, il fait office de serveur et aussi de client vis à vis du serveur TPOP. Sa partie client est très similaire à celle du client vue dans la partie II. Ce serveur ne transmet que les puzzles, il ne les vérifie et ne les résous pas. Il a par contre la charge - 8 -

9 de vérifier que les domaines des adresse de l'expéditeur et des destinataires sont valides. B) Serveur TPOP Le serveur TPOP est le serveur final. C'est aussi lui qui s'occupe du message une fois celui-ci transmis. Dans notre cas le message est affiché sur la sortie standard. Mais il est facile d'écrire dans un fichier pour simuler un vrai serveur TPOP. Contrairement au serveur relais, le serveur TPOP à la charge de générer des puzzles et de les transmettre. Il doit aussi vérifier la solution qu'on lui transmet, pour cela il vérifie que le puzzle est résolue, mais également que c'est le même. Contrairement au serveur relais, le serveur TPOP est multithreadé. Chaque client consomme une thread. Ce choix est motivé par la volonté de diversifier notre implémentation. Et ainsi de mettre en pratique plusieurs des techniques vues en cours

10 Conclusion Notre projet implémente donc notre RFC, et permet d'éviter de façon très efficace l'envoie de courrier électronique en grande quantité. De plus l'architecture du projet permet de modifier et/ou réutiliser chaque module très facilement. Ainsi cela lui permet une évolution aisée. De plus cela a permit de mettre en pratique nos connaissances techniques en Architecture et programmation réseau et en particulier la programmation de serveur et de client en java. Par ailleurs il s'agit d'un nouveau dossier qui nous permet de nous perfectionner dans la gestion de projet