TP noté - IR2
Programmation Réseau avec Java

28 avril 2009

Durée: 1 heure 30

Remarques importantes :

Prenez le temps de lire correctement les énoncés, y compris ces remarques pour ne pas répondre à côté de la question...

Le principe de ce TP noté est de vous faire réaliser des exercices en les corrigeant au fur et à mesure de leur réalisation. Dès que vous avez réalisé une partie d'un exercice (typiquement la réponse à une question indiquée par le symbole ), vous appelez le correcteur qui viendra vérifier la validité de votre travail.

Vous pouvez utiliser les entrées-sorties "classiques" (java.io et java.net) ou les "nouvelles" entrées-sorties (java.nio), mais toutes les implémentations se feront en mode bloquant (aucun code non-bloquant ne sera accepté).

Vous écrirez toutes les classes Java nécessaires à ce TP noté dans un paquetage fr.umlv.ir2.jr.tpnote. Vous respecterez les noms de classe spécifiés dans le sujet.

À la fin du temps de composition, lorsque l'examinateur vous le dira, vous enverrez par mail à votre examinateur l'ensemble des classes que vous avez codé, dans l'état où elles se trouvent (même avec des erreurs de compilation). Cela permettra d'ajuster votre évaluation par rapport à ce qui a été vérifié par l'examinateur en séance. N'envoyez aucun mail avant qu'on ne vous le dise, et en tout état de cause vous ne devrez envoyer qu'un seul mail contenant toutes vos classes.

Question 1. Un serveur TCP itératif qui affiche les entiers qu'il reçoit

On souhaite dans un premier temps écrire un serveur TCP très simple, que nous ferons ensuite évoluer. Ce serveur, sous la forme d'une classe TcpIterativeServer, se démarre en lançant la commande
prompt$ java fr.umlv.ir2.jr.tpnote.TcpIterativeServer <tcpPort>
où tcpPort est le port d'écoute du serveur.

Pour l'instant, ce serveur est itératif, c'est à dire qu'il n'accepte qu'une seule connexion de client à la fois: il ne peut accepter et traiter le client suivant que lorsque la connexion TCP avec le client en cours est fermée.

Dans cette question, le service effectué par ce serveur est le suivant: il affiche à l'écran tous les entiers qu'il reçoit du client connecté, un par ligne; on considère que les entiers sont des int sans se soucier de l'ordre des bytes (le serveur et les clients sont sur la même plateforme: localhost).

Pour tester ce serveur, vous utiliserez le client dont le bytecode est fournit à l'URL SimpleClient.jar. Ce client se démarre par la commande
prompt$ java -jar SimpleClient.jar <server> <tcpPort>
où <server> est l'adresse du serveur que vous devez développer (donc localhost) et tcpPort est le port d'écoute du serveur. Ce client envoie tous les entiers qu'il lit au clavier, un à un, vers le serveur sur la connexion TCP, et il s'arrête quand on tape Ctrl-D (fin de flot) ou Ctrl-C.

Développez la classe TcpIterativeServer. Vous la munirez d'un constructeur qui accepte le numéro de port en argument, d'une méthode launch() qui démarre le serveur et d'une méthode main() qui crée un serveur écoutant sur le port passé en argument sur la ligne de commande et le démarre. Tester qu'il permet d'accepter et de traiter successivement plusieurs clients SimpleClient.jar sur localhost.

Question 2. Un serveur TCP concurrent qui affiche les entiers qu'il reçoit et de qui il les a reçus

Sans modifier le serveur précédent (vous pouvez en faire une copie ou réutiliser ce qui vous intéresse), on souhaite maintenant écrire un serveur TCP concurrent dans une classe TcpConcurrentServer. Ce serveur rend le même service que le serveur précédent, mais en traitant en concurrence tous les clients qui se sont connectés à lui, dans la limite de maxClients clients simultanés: ce nombre de clients maximum sera passé en argument au lancement du serveur, et au delà de ce nombre, les clients tentant de se connecter devront attendre qu'un client actuel se déconnecte pour pouvoir être servi. En plus de l'entier reçu, le serveur affichera à l'écran l'adresse de la socket (adresse IP et numéro de port) du client de qui il a reçu cet entier.

Le serveur se démarre donc en lançant la commande
prompt$ java fr.umlv.ir2.jr.tpnote.TcpConcurrentServer <tcpPort> <maxClients>

Développez la classe TcpConcurrentServer. Vous la munirez d'un constructeur qui accepte le numéro de port et le nombre maximum de clients en argument, d'une méthode launch() qui démarre le serveur et d'une méthode main() qui crée un serveur écoutant sur le port passé en argument sur la ligne de commande et le démarre. Tester qu'il permet d'accepter et de traiter simultanément jusqu'à maxClients clients SimpleClient.jar sur localhost.

Question 3. Un serveur TCP concurrent qui fait la somme les entiers qu'il reçoit de ses clients

Sans modifier le serveur précédent (vous pouvez en faire une copie ou réutiliser ce qui vous intéresse), on souhaite maintenant écrire un serveur TCP concurrent dans une classe SumConcurrentServer.

Ce serveur est très semblable au précédent mais au lieu d'afficher les entiers qu'il reçoit de ses clients, il doit en cumuler la somme dans un seul et unique compteur (un même compteur entier pour tous les clients d'un même serveur, qui au démarrage du serveur est initialisé à zéro, et pour lequel on ne se posera pas la question du débordement), et afficher à l'écran la valeur du compteur après chaque ajout d'un entier reçu d'un client.

Le serveur se démarre comme précédement en lançant la commande
prompt$ java fr.umlv.ir2.jr.tpnote.SumConcurrentServer <tcpPort> <maxClients>

Développez la classe SumConcurrentServer et testez-la en utilisant plusieurs clients SimpleClient.jar sur localhost.

Question 4. Un client un peu particulier

On veut maintenant définir notre propre client, pour modifier le comportement de SimpleClient.jar. On va donc écrire une classe Client4, qui se démarrera en lançant la commande
prompt$ java fr.umlv.ir2.jr.tpnote.Client4 <tcpServer> <tcpPort>
et qui devra réaliser les opérations suivantes:

• créer une socket UDP afin de connaître son numéro de port d'attachement, qu'on appellera ultérieurement udpListeningPort (pour l'instant, vous ne vous placerez pas en attente de réception sur cette socket UDP: vous avez seulement besoin de connaître son numéro de port d'attachement);
• créer une socket TCP afin d'établir une connexion avec le port tcpPort du serveur tcpServer;
• commencer par envoyer le numéro de port udpListeningPort sur cette connexion, sous la forme d'un entier (int) de sorte qu'il puisse être lu comme tel par le serveur;
• puis, tant que le flot sur l'entrée standard System.in n'est pas fermé, lire sur ce flot tous les entiers et les envoyer, un à un, en tant qu'entiers (int) sur la connexion vers le serveur.

Développez la classe Client4 et testez-la en utilisant plusieurs instances qui se connectent à votre serveur SumConcurrentServer démarré sur localhost.

Question 5. Le serveur reçoit les entiers en TCP et renvoit la somme globale en UDP

Toujours sans modifier le serveur précédent (vous pouvez en faire une copie ou réutiliser ce qui vous intéresse), on souhaite maintenant écrire une nouvelle version du serveur dans une classe Server5.

Sur la base du service que rendait le précédent serveur SumConcurrentServer, on souhaite que Server5 prenne désormais en compte les éléments suivants:

• le premier entier reçu d'un client qui se connecte est le numéro d'un port UDP sur le client: le serveur ne doit pas l'ajouter au compteur global. En revanche, tous les entiers suivants sur cette connexion sont à ajouter, comme avant, au compteur global;
• en plus d'afficher à l'écran, comme précédemment, la valeur du compteur après l'ajout de chaque entier reçu d'un client, le serveur doit maintenant envoyer la valeur du compteur à ce client, en UDP à destination du numéro de port que le client à transmis comme premier entier sur la connexion. Le compteur sera transmis sous la forme des octets codant la chaîne de caractères en ASCII représentant sa valeur. En résumé, à part le premier entier qui représente le numéro du port d'écoute UDP, chaque envoi d'un entier par un client sur la connexion TCP vers le serveur doit provoquer l'envoi par le serveur de la chaîne de caractères du compteur global incrémenté d'autant, vers le port UDP de ce client (les autres clients simultanément connectés ne reçoivent rien pour cet entier); ceci est bien sûr valable pour chaque client.
• Il est important que le datagramme UDP qui transporte le compteur du serveur vers un client C1 contienne la valeur du compteur immédiatement après ajout de l'entier que C1 a transmis au serveur en TCP. En particulier, on veut éviter que l'exemple suivant puisse se produire:
  - C1 envoie 10 en TCP au serveur
  - le compteur passe de 0 à 10
  - C2 envoie 5 en TCP au serveur
  - le compteur passe de 10 à 15
  - le serveur envoie 15 en UDP à C1
  - le serveur envoie 15 en UDP à C1.
  Avec les mêmes échanges, on préfère assurer l'un des deux séquencements suivant:
  - C1 envoie 10 en TCP au serveur
  - le compteur passe de 0 à 10
  - le serveur envoie 10 en UDP à C1
  - C2 envoie 5 en TCP au serveur
  - le compteur passe de 10 à 15
  - le serveur envoie 15 en UDP à C1.
  ou bien
  - C2 envoie 5 en TCP au serveur
  - le compteur passe de 0 à 5
  - le serveur envoie 4 en UDP à C2
  - C1 envoie 10 en TCP au serveur
  - le compteur passe de 5 à 15
  - le serveur envoie 15 en UDP à C1.
  

Développez la classe Server5. Vous ne pourrez la tester qu'après avoir réalisé la question 6 suivante.

Question 6. Le client envoit ses entiers en TCP et reçoit la somme en UDP

Sans modifier le client précédent (vous pouvez en faire une copie ou réutiliser ce qui vous intéresse), écrivez maintenant une nouvelle version du client dans une classe Client6 qui ajoute à la version précédente les fonctionnalités suivantes:

• la socket UDP dont le numéro de port d'attachement a été envoyée au serveur doit être placée en attente de réception de paquet UDP;
• à chaque fois qu'un paquet est reçu, le client considère qu'il contient les octets d'une chaîne de caractères en ASCII et il affiche cette chaîne de caractères à l'écran;
• cette activité d'écoute UDP et d'affichage à l'écran doit avoir lieu en concurrence avec l'activité de lecture depuis l'entrée standard les entiers qui sont envoyés au serveur sur la connexion TCP;
• lorsque la fin de flot (Ctrl-D) est rencontrée sur l'entrée standard, il doit être mis fin à l'activité d'écoute UDP afin que l'application s'arrête.

Développez la classe Client6. Testez-la avec l'application Server5.java.