:: Enseignements :: ESIPE :: E4INFO :: 2011-2012 :: Applications réseaux ::
![[LOGO]](http://igm.univ-mlv.fr/ens/resources/mlv.png) |
Qroxy... test
- Correction |
Ce TD est l'occasion de réaliser un serveur HTTP en mode non-bloquant ainsi qu'un client simple utilisant des URLConnection... qui vont nous servir à tester le projet Qroxy.
Exercice 1 - Un serveur HTTP de données aléatoires
On souhaite réaliser un serveur HTTP chargé de renvoyer des fichiers contenant des données pseudo-aléatoires. Les URLs demandées au serveur suivront le format suivant :
http://monserveurhttp/path/?seed=x&period=y&length=z
. x désigne un entier utilisé comme graine pour initialiser le générateur pseudo-aléatoire. Une donnée temporelle sera également utilisée avec la graine de telle sorte que la séquence d'octets générée soit différente toutes les y secondes (on pourra récupérer un générateur pseudo-aléatoire avec
new Random(x + System.currentTimeMillis() / y)
). Enfin z indique la longueur du fichier demandé au serveur.
On prendra soin :
- de renvoyer un type MIME spécifique application/random;
- de ne pas oublier d'indiquer la date de dernière modification du fichier et sa date d'expiration (en fonction de la période);
- de pouvoir traiter en concurrence plusieurs demandes de fichiers pseudo-aléatoires en utilisant des nIOs non-bloquantes;
- et d'indiquer le débit d'envoi de chacun des fichiers demandés pour tester si la limitation de débit du proxy est bien mise en oeuvre.
On pourra ensuite implanter sur le serveur la mini-RFC de limitation de débit à l'envoi.
Exercice 2 - Un client HTTP récupérant des images aléatoires
On écrit maintenant un client HTTP chargé d'interroger le serveur de fichiers pseudo-aléatoires. Celui-ci prend pour paramètres l'hôte, le port, le chemin, la graine, la période et la longueur du fichier. On notera que l'on pourra utiliser des chemins variables, qui ne seront pas pris en compte par le serveur mais qui permettront de discriminer les ressources sous différentes règles par le proxy. En particulier, on cherchera :
- à indiquer le débit de réception des données pour vérifier le fonctionnement du mécanisme de QoS;
- et à tester si le mécanisme de cache fonctionne correctement : une ressource fraîche ne doit pas être retéléchargée sur le serveur ; à l'inverse une ressource périmée doit l'être.
On est autorisé à utiliser la classe URL pour construire l'URL de requête puis obtenir ensuite une URLConnection afin de récupérer le fichier. Il faudra indiquer que l'on souhaite emprunter un proxy intermédiaire :
cette page liste les différentes manières d'y parvenir.
Pour finir, on suppose que les données envoyées par le serveur représentent en fait les pixels d'une image : on souhaite donc pouvoir traiter cette image par notre client. Pour cela, on créé une ContentHandlerFactory que l'on fournit à l'URLConnection et qui sera chargée de retourner un objet java.awt.Image pour le type MIME application/random. Bien sûr, cela ne nous dispense pas d'afficher des informations de débit concernant la récupération des données. Pour fabriquer l'image, on suppose que celle-ci est de dimension carrée et comprend des séquences de triplets d'octets (R,G,B). Le côté de l'image est donc de (int)Math.sqrt(len/3) pixels (on ignore les octets surnuméraires). On pourra ensuite afficher cette image ou l'enregistrer dans un fichier au format de son choix.
© Université de Marne-la-Vallée