Description du sujet : un serveur de surnoms

Dans la lignée de services très utiles tels que ceux offerts par les serveurs de noms (DNS...) et les serveurs de clés, nous vous proposons de mettre en place un serveur de surnoms. Ce serveur stocke le nom associé au surnom d'un étudiant ou d'un enseignant de l'ESSI. Deux personnes différentes ne peuvent pas avoir le même surnom mais une personne peut être affublée de plusieurs surnoms. Il doit être  possible par exemple d'enregistrer un nouveau surnom et un nom associé, de modifier l'enregistrement, de lister les noms et surnoms enregistrés dans le serveur. Le service offert ne sera pas persistant : il initialise les associations surnom - nom au lancement et perd les nouvelles associations lorsqu'il est arrêté.

Modalité des TPs

4 séances encadrées sont consacrées à ce travail.
Vous devez travailler en binôme.
Vous pouvez vous référencer à
    aux cours RMI et Sockets
    aux tutoriaux Java
    et aussi le cours de Conclusion
 

Vous devez rendre à la fin du module réseau au plus tard
sous ~pinna/www/Internet/ReseauESSI2 dans un répertoire que vous allez créer avec vos noms de binômes

Pour la partie RMI + Sockets vous devez fournir :

Un document contenant les informations suivantes : vos noms, le nom des étudiants avec lesquels vous avez collaboré, les réponses au 2 et aux questions de recul posées dans chaque partie.

Le code fait chaque semaine : pensez à le commenter.

Une démo sera faite dans le cadre de la dernière séance de la dernière semaine.

Les questions à rendre seront complétées par Jean Yves Tigli concernant les cours suivants
 

Partie RMI (1séance encadrée)

Vous allez tester et appréhender la communication réseau par RMI
Le but est juste de pouvoir envoyer une requête du client vers le serveur
Il s'agira de mettre en place côté serveur un accusé de réception d'une requête.
Quelque soit la requête envoyée , le client doit recevoir en retour du serveur une chaîne de caractère contenant "Requête reçue - exécution de la méthode m".
Tester seulement sur une requête de test.
 

1. Accusé de Réception des requêtes en RMI

Code

1. Créer un  Objet Distant de type "AccuséDeReception" qui  supporte une méthode  "String confirmer(String s)" qui renvoie la concaténation de "Requête reçue - exécution de la méthode" et de la  chaine passée en paramètre (nom d'une méthode à exécuter).  un serveur d'objet distant "Surnoms" qui  crée l'objet "AccuséDeRéception" et l'enregistre dans le registry
2. Créer un programme client qui obtient une référence vers l'OD "AccuséDeReception" et qui invoque sa méthode "confirmer" en lui passant une chaine et en affichant le résultat de l'invocation
3. Déployer les classes sur le client et le serveur.

• Quels sont les codes indispensables côté client et côté serveur ?
• Que faut il mettre en œuvre et comment pour limiter le déploiement de code côté client ?.
• Que contiennent et à quoi servent les stubs générés ?

Partie Sockets (3 séances encadrées)

2. Définition du protocole d'application

1. Lister l'ensemble des requêtes offertes par votre serveur. Vérifier que cela permet d'offrir un service complet, suffisant et correct.
2. Donner la structure de données qui permet de gérer votre serveur.
3. Travailler en accord avec un autre binôme afin de permettre une communication entre votre serveur et leur client et réciproquement.

Code

1. Implémenter  le code du serveur qui implémente les services que vous avez listés au 1. Le serveur n'est pas multi clients dans un premier temps.
2. Ecrire le code d'un client qui teste l'ensemble des requêtes offertes dans votre serveur.
3. Tester votre serveur avec votre client.
4. Tester à distance votre client avec le serveur développé par  le binôme choisi au 1.3.

• Quelles sont les hypothèses minimales à faire pour qu'un client puisse dialoguer avec le serveur écrit par un autre binôme ?
• Comment rendre le serveur multi-clients ?
• Comment concevoir le serveur afin de pouvoir simplement réutiliser du code si le type de communication change ?

Code

1. Implémenter  le code du serveur qui implémente les services que vous avez listés au 1. Le serveur gère une communication en mode UDP.
2. Ecrire le code d'un client qui teste l'ensemble des requêtes offertes dans votre serveur.
3. Tester votre serveur avec votre client.
4. Tester à distance, votre client avec le serveur développé par  le binôme choisi au 1.3 et réciproquement.

• Avez vous été amenés à modifier le protocole d'application choisi au 1 et utilisé au 2, si oui pourquoi ?
• Quelle parties de code développée dans la partie 2 avez-vous pu réutiliser dans le 3 ?
• Pensez-vous qu'une conception différente de votre code aurait pu vous permettre d'en ré-utiliser davantage ?
• Quels sont les principaux avantages et/ou inconvénients d'une communication par messages pour ce type de service ?

Supposons que le serveur de surnoms soit un serveur très important pour l'école et que nous soyons amené à mettre en place des serveurs esclaves qui soient des copies de ce serveur. Pour simplifier nous utiliserons une communication en mode multicast dans laquelle tous les serveurs esclaves sont des clients du serveur principal. Via cette communication le serveur principal informe régulièrement (délai de temps) les serveurs esclaves de son état.
 

Code

1. Implémenter  le code du serveur multicast.
2. Ecrire le code d'un client.
3. Tester votre serveur avec vos clients

• Quel est le protocole d'application que vous avez mis en place pour cette partie ?
• Comment faire évoluer le code du client et du serveur afin de mixer les services offerts au 4 et au 5 ?

• Expliquer comment le service de surnoms avec accusé de réception intégré aurait-il pu être développé en RMI ?
• Quelles auraient été les limites et/ou inconvénients et/ou avantages ?
• Quelle partie de vos codes se rapprochent le plus du code généré dans les stubs ? Pourquoi et Comment ?