Projet : ETERMAILTTT

Attention : cette page peut être modifiée à tout moment ! il faut venir la consulter régulièrement. Dernière modification : samedi 28 mars 2009 (15h)

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 :

1. X veut écrire à Y@BINIOU
2. X contacte son propre serveur d'envoi POUET
3. POUET trouve l'adresse du serveur BINIOU et lui demande un puzzle
4. BINIOU fournit un puzzle
5. POUET transmet ce puzzle à X
6. X résout le puzzle et envoie la solution à POUET
7. POUET envoie le mail de X et la solution du puzzle à BINIOU
8. 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. 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.

Dans un premier temps, il vous est demandé :

• de réfléchir aux protocoles nécessaires à la mise en place de ce principe : communications entre le client et le serveur d'envoit ETERMAIL, entre le serveur d'envoit ETERMAIL et le serveur ETERMAIL distant. Ces communications devront être spécifiés dans un document .txt en vous inspirant du formalisme des RFC. Voir le site IETF et par exemple la RFC 1350 ;
• de réfléchir à l'architecture des classes dont vous avez besoin : nom des classes, nom et rôle des méthodes publiques et privées qu'elles contiennent...

Ceci consitituera un premier rendu par mail. Le mail contiendra :

• en objet "ETERMAILTTTR1"
• en corp "noms et prénoms des deux binômes"
• en pièce jointe, le document RFC (de préférence en anglais) et un document au format pdf décrivant vos classes et explicitant vos choix (!! pas de code !!). Un diagramme UML dans ce document sera le bienvenu.
• DATE du premier rendu : 9 mars 2009

Note : vous n'avez pas besoin de savoir comment fonctionnent les puzzles eternity pour ce rendu !!

Dans une deuxième temps, vous devrez implanter les classes que vous proposez. Vous rédigerez alors une documentation expliquant les différences entre vos deux rendus. Une autre documentation devra expliquer comment lancer les différents programmes composant votre projet. Une troisième expliquera les éventuels bugs dans votre projet.

Voici un squelette pour la partie concernant les puzzle :

		public class Puzzle{
			private static final SIZE = ...; 
			private final byte[] puzzle;
			public Puzzle(int difficulty){
				// ce constructeur doit en principe générer le puzzle en fonction de
				// la difficulté (taille du mail par exemple)
				// mais on simplifie par :
				puzzle = new byte[SIZE]; 
			}
			public byte[] getByte(){
				return puzzle;
			}
			@Override
			public boolean equals(Object o){
				if(o instanceof Puzzle){
					Puzzle p = (Puzzle)o;
					return Arrays.equals(p.getByte(), puzzle);
				}
				return false;
			}
		}
	

Dans votre serveur :

		public void sendPuzzle(Puzzle p,Socket service)throws IOException{
			service.getOutputStream().write(p.getByte());
		}
		public boolean isCorrect(Puzzle p, Puzzle answer){
			// en principe cette méthode doit vérifier que answer 
			// contient bien les mêmes pieces que p et qu'elles sont 
			// bien ordonnées pour respecter les règles eternity.
			// on simplifie par : 
			return p.equals(answer); 
		}
	

dans votre client :

		public void sendAnswer(Puzzle p, Socket server){
			// en principe, le client doit résoudre le puzzle, 
			// on simplifie par :
			server.getOutputStream().write(p.getByte());
		}
	

Le problème est simplifié. En bonus, vous pouvez modifier ces méthodes pour coder leur vrai comportement.

Le deuxième rendu est officielement pour dimanche 29 mars. Les binomes qui le souhaitent peuvent avoir 1 semaine de délais à condition de me le faire savoir par mail.

Il vous est demandé une archive ZIP appellée NOM1_NOM2.zip contenant :

• les SOURCES de votre projet dans un répertoire src
• les documentations demandées (doc développeur, doc utilisateur et rapport de bugs) dans un répertoire docs
• un fichier build.xml permettant, à l'aide de l'utilitaire ant de :
  • ant : compile le programme et place les .class dans un répertoire bin
  • ant jar : produit deux fichiers server.jar et client.jar permettant de lancer respectivement un serveur et un client. Ces fichiers seront placés dans le repertoire bin.
  • ant javadoc : génère la javadoc et la place dans le répertoire docs/javadoc
  • ant clean : efface le contenu des répertoires bin et docs/javadoc