:: Enseignements :: ESIPE :: E4INFO :: 2009-2010 :: Java Réseau II - Applications réseaux ::

FCD-ProxIR : a Filtering and Cache Distributed HTTP Proxy

Le projet consiste à implanter un proxy pour HTTP capable de réaliser du filtrage et une gestion cache distribué des pages accédées.

Description du sujet

Le projet consiste à implanter un proxy pour HTTP capable de réaliser

du filtrage
- sur les requêtes: par exemple, sur le nom du serveur web, son domaine, son adresse IP, le numéro de port utilisé, une variable transmise dans l'URL, ou plus généralement sur n'importe quel élément de la requête (ligne de requête ou champs d'en-tête), mais également sur le corps éventuel de la requête (e.g. s'il s'agit d'une requête POST)
- sur le contenu: outre les filtres sur la ligne de status ou les champs d'en-têtes, votre proxy devra être capable d'analyser une page web ou un fichier dont il réalise le transfert pour y détecter des éléments qu'on souhaite bloquer, remplacer ou plus simplement reporter.
- Noter que "filtrer" n'est pas un synonyme d'"exclusion" ...
une gestion cache des pages accédées.
- L'accès à une page doit prioritairement se faire en cache afin d'améliorer les temps d'accès.
- Ce cache doit être distribué ; à savoir, que, à tout moment, l'ensemble des pages en cache n'est pas stocké sur une seule machine.
- En effet, une page peut (i) soit être en cache sur le proxy en question, (ii) soit être en cache sur un autre proxy, (iii) soit n'être dans aucun cache actuellement.
- Dans le cas (i), la page est renvoyée directement par le proxy
- Dans le cas (ii), la page est renvoyée par le proxy l'ayant en cache via le proxy actuel au client
- Dans le cas (iii), la page est renvoyée et mise en cache par le proxy
- La stratégie de gestion du cache doit permettre de bonnes performances ; cela sous-entend que les startégies suivantes ne sont a priori pas bonnes : (a) chaque proxy met tout en cache, (b) chaque proxy innonde le réseau dès qu'il veut accéder une page.

Vous serez jugés sur votre capacité à implanter un proxy pratique et puissant: le choix de la manière dont est réalisé et spécifié le filtrage, et l'interface de paramétrage du proxy, sont laissés à votre appréciation. Il va sans dire, par exemple, que le proxy devra être paramétrable au moins par un utilisateur non programmeur.

En ce qui concerne la gestion du cache, vous proposerez une stratégie précise et décidable. Cette dernière devra garantir des performances en temps d'accès et en terme de "fraicheur" des pages. Par ailleurs, vous fournirez une RFC relative à la mise en place de votre système de cache (e.g. les acteurs de ce système et les détails et formats d'échanges d'informations entre ces derniers).

Vous pouvez tester votre proxy en indiquant à votre client (e.g. un navigateur internet) que les requêtes http doivent passer par votre proxy. Comme il n'est pas possible de modifier le proxy utilisé par le firefox installé sur les machines étudiantes, vous pouvez utiliser Galeon.

Votre proxy devra pouvoir servir plusieurs clients simultanément. Il n'est pas obligatoire de réaliser un proxy en utilisant les fonctionnalités non blocantes des E/S de Java; cependant, vous serez jugés aussi sur la capacité de votre serveur à tenir la charge ainsi que sur son efficacité.

L'implantation du pipeline (http pipelining on wikipedia) est optionnelle. Pensez à avoir une base de projet propre et qui fonctionne bien avant de vous lancer dans des extensions complexes. Par exemple, vous pourrez commencer à développer un proxy HTTP 1.0 puis, une fois qu'il fonctionnera, le continuer par l'implantation de HTTP 1.1.

Bien sûr, votre proxy devra être implanté en utilisant avec soin les concepts objets et les différents éléments de la bibliothèque.

Quelques questions à se poser

Voici quelques questions ouvertes qui vous guideront pour la réalisation de ce projet.

Comment fonctionne un cache non distribué ?
Quels mécanismes du protocole HTTP permettent de déterminer la "fraîcheur" d'une donnée et si cette dernière ne doit pas être mise en cache (e.g. le résultat d'une recherche sur google)?
Lors de la mise en cache d'une ressource, que se passe-t-il si cette dernière est demandée par un autre client ?
Comment sont gérées les ressources ayant des tailles très petites ou très grandes ?
Le filtrage de ressources volumineuses est-il possible et si oui à quel prix ?
Existe-il un moyen de limiter les communications entre les proxys lors de l'identification du proxy ayant une ressource donnée ? (petite aide : le hachage)
Comment gérer la panne/le retour d'un proxy ?
...

Remise du projet

Ce projet est un travail à faire en binôme. On rappelle qu'un binôme est constitué d'exactement deux personnes travaillant de manière équitable sur le projet. La note des deux membres du binôme pourra être différente à l'appréciation du correcteur, s'il juge que le travail n'a pas été justement partagé.

Le projet consiste à programmer ce qui est demandé. La correction sera basée sur (i) la version préliminaire de votre RFC, (2) les codes sources de ce que vous avez fait, (3) la qualité de votre soutenance et (4) sur un rapport qui devra contenir entre autres :

un rappel sur le sujet,
un mode d'emploi du programme,
des exemples d'exécutions,
une documentation technique du code (hiérachie des classes, etc.),
une reflexion générale sur le projet,
une section sur la répartition du travail entre les deux membres du binôme.

Votre code source devra être correctement organisé :

un fichier par classe/classe abstraite/interface, de même nom que la classe/classe abstraite/interface qu'il contient,
les classes/classes abstraites/interfaces seront organisées en paquetages,
chaque fichier contiendra des commentaires documentants le type dont il contient la définition.

Votre projet sera également accompagné d'une documentation au format javadoc.

Les modalités de rendu sont à venir. A priori, une zone de dépôt...

Le projet doit être déposé dans un fichier zip le 2 juin à 23h59 au plus tard sur un dépôt sur etudiant :
/home/shares/igm/prof/XXXX qui vous sera bientôt précisé . Le zip contiendra

un fichier jar exécutable
la documentation
le rapport
les sources
les classes compilées
un fichier build.xml permettant de
- compiler les sources (target compile)
- creer le jar (target jar)
- generer la javadoc (target javadoc)
- nettoyer le projet (target clean)

(bref, tout ce qui concerne le projet). Le zip aura un nom formé à partir de vos noms (par exemple, si vous vous appelez Toto et votre binôme Tatenpion, TotoTartenpion.jar). L'extraction de cette archive devra créer un répertoire du nom de l'archive pour contenir tous les éléments demandés ci-dessus (par exemple, un répertoire TotoTartenpion).

Cas de pénalités :

projet non effectué en binôme (i.e. 2 personnes !) sans l'accord préalable de l'intervenant de TD
projet rendu après la date (1 point + 1 point par demi-heure de retard)
Récéption d'une archive qui n'a pas le nom demandé
Extraction du zip ne produisant pas le répertoire demandé

FAQ

Le cache distribué doit-il fonctionner sur plusieurs machines physiques ? Si oui, doit-on (/peut-on) supposer que ces proxys se trouvent dans le même réseau LAN ? : oui, ils doivent pouvoir fonctionner sur plusieurs machines identifiées par des adresses IP+port (donc pas forcément sur le même LAN).