2 Contrôleur, routeur et proxy http

2.1 Routeur

Celui-ci offre plusieurs services :

• demander d’ouvrir un flux vers le successeur ;
• demander d’ouvrir un flux vers un successeur identifié par un numero de session ;
• écrire sur le flux créé ;
• fermer le flux créé ;
• récupération des logs ;

2.1.1 Services proposés par le routeur

Les services que proposent le routeur sont accessibles par les clients avec les requêtes : SUIV, CONN FLUX, FERM et BKDR.

• SUIV : Le routeur se connecte alors sur le serveur situé à l’adresse et sur le port indiqué dans la partie donnée du paquet. Si la connexion réussie, le routeur renvoie au client COOK (COnnexion OK). Le routeur renvoi ERRC (ERReur Connexion) dans le cas où la connexion à échouée.

  À partir du moment où la connexion est acceptée, le routeur envoi vers son client tout ce qu’il reçoit de son successeur en encapsulant les données dans un paquet normalisé. La partie requête du paquet étant DATA.

  Voici un exemple de paquet pouvant être reçu par le routeur :

  

  Par convention j’écris entre guillements (") les valeurs codées sous forme de chaîne de caractères et sans guillemet les valeurs décimales. Par exemple le paquet précédent se voit de la façon suivante :

  Offset    ------------ notation hexadecimale -------------   ---- ASCII -----   00000000  00 53 55 49 56 00 18 72  6f 75 74 65 75 72 31 2e  | SUIV  routeur1.|   00000010  64 79 6e 64 6e 73 2e 6f  72 67 3a 39 30 39 31     |dyndns.org:9091|

  Un paquet de retour possible est :

  

• CONN : ce service sera appelé lorsque le routeur sera en bout de chemin et devra se connecter à un serveur. En plus de l’adresse et du port, les données contiendront un numero de session. Lorsque le serveur enverra des données, il faudra encapsulées celles-ci dans un paquet contenant aussi le numéro de session. En pratique le paquet est le suivant :

  

  Les paquets de retours comme COOK et ERRC doivent aussi être modifiés de la même façon.

• FLUX : lorsque le routeur reçoit cette requête, il envoi le message contenu dans la partie données du paquet à son successeur. Si la connexion à été créée avec la requête CONN plutôt que SUIV alors les 4 premiers octects des données sont un numéro de session ce qui permet de savoir à quel serveur envoyer les données.
• FERM : Le routeur fermera la connexion vers son successeur.
• BKDR : pour BacKDoor, lorsqu’un client envoi cette requête, alors le routeur envoi l’ensemble de ses logs au client. Cette requête permettra de pouvoir faire du deboguage, mais peu aussi servir de backdoor pour savoir qui s’est réellemnt connecté avec qui.

Si le sucesseur d’un routeur ferme la connexion alors, le routeur envoie à son client utilisant ce successeur la commande CLOS (CLOSed). Si la connexion a été obtenue avec CONN plutôt que SUIV alors le paquet contiendra aussi le n^∘ de session dans la partie données.

2.1.2 Contrôleur

Le contrôleur doit pouvoir fonctionner selon deux modes : un mode simulation de serveur et un mode proxy http .

• simulation de serveur, l’adresse et le port du serveur cible¹ est donné directement en paramètre lors du lancement du contrôlleur.
• proxy http , le serveur terminal est évalué lors des requêtes http .

Le routeur doit posséder les fonction internes suivantes :

• int nouveauChemin(int i) : cette fonction va créer un nouveau chemin de longueur i . Pour cela, il a à sa disposition une liste de routeurs disponibles. Il va vérifier que la connexion se fait bien jusqu’au dernier serveur. Si la connexion s’est correctement établie, la fonction renvoie 0 sinon elle renvoie le numéro du routeur auquel la connexion à échouée.
• supprimeChemin() : va fermer la connexion entre tous les routeurs qui forment le chemin courant.
• encapsule(string message) : cette fonction encapsule les données de façon à ce que le message encapsulé puisse être envoyé au sucesseur direct et soit compris par le dernier routeur du chemin.

De plus, pour le début du projet, nous considérons que le contrôleur possède la liste des routeurs accessibles ; soit dans une structure de données remplie manuellement, soit dans un fichier qui sera chargé à chaque démarrage du contrôleur. Ajouter un système de publication des routeur fera partie des dernières étapes du projet.

La conception du contrôleur sera très proche de celle des routeurs. Voici les requêtes que peuvent formuler les clients au contrôleur et les services qui leur sont alors fournis :

• CONN : Demande au dernier routeur de se connecter à l’adresse indiquée dans la partie données. Si l’adresse ne contient pas de port, alors c’est le port 80 qui sera choisi par défaut. Une fois la connexion établie, le contrôleur reçoit les données encapsulées du serveur cible, les désencapsules et les envois vers son client.
• FLUX : le contrôleur encapsule les données de façon à ce que les données soient envoyées au serveur cible.
• BKDR : il faut traiter cette demande de la même façon que pour les routeurs en envoyant la totalité des logs au client qui fait cette requête.
• <MOT CLE HTTP> http://adresse[:port]/chemin/vers/fichier ...\r\n : où <MOT CLE HTTP> est l’un des mots clé :
  • GET
  • HEAD
  • POST
  • PUT
  • DELETE

  Fait la même chose que CONN suivit de la requête FLUX qui transmet l’ensemble de la requête au serveur cible. Cette dernière requête est utile pour pouvoir utiliser un navigateur internet à travers le réseaux. Il suffira d’utiliser le contrôleur comme un proxy http .

2.2 Résumé et exemple

Pour résumer voici la table qui résume l’ensemble des requêtes pour les routeurs et les contrôleurs :

Pour le routeur :

Pour le contrôleur :

Pour fixer les idées nous donnons un exemple des paquets passant sur le réseaux. Le réseau concerné est le suivant :

• A est un client echo ;
• B est un serveur echo d’adresse serverecho.com:2000 ;
• C est le contrôleur d’adresse localhost:3000. Il a été lancé en mode simulation ; c’est-à-dire avec la ligne de commande : controleur 3000 serverecho.com 2000 ;
• R1 est le premier routeur d’adresse R1@dyndns.org:21222 ;
• R2 est le second routeur d’adresse 147.93.66.131:34500 ;

Sont écrit entre parenthèse les commande qui ne nécessitent pas d’entrée ou de sortie sur les sockets comme les connexions et les "close". Les paquets sont écrit selon la notation suivante : v."req".l."data" avec :

• v le numero de version en décimal (sur 1 octect) ;
• "req" la requête codée en ASCII (sur 4 octects) ;
• l la longueur en décimal (sur 2 octects) ;
• "data" les données codée en ASCII (sur l octects) ou nombre"data" ou nombre correspondra au numéro de session en décimal (4 octects) ;

Voir la figure 1 page §.

2.1.  Écrivez le même type de conversation en utilisant le même réseaux mais en ajoutant un deuxième client echo D qui se connecte en même temps à un autre serveur echo E.

(a)  Pourraient-ont se passer des numéros de session ? Si oui, quelles fonctionnalités du réseau anonyme perdraient-on ? Si non, expliquez en quoi ces numéros de sessions sont absolument nécessaires à la bonne utilisation du réseau anonyme.

Voici un autre exemple de dialogue possible entre un client http A et un serveur http B qui se parlent par l’intermédiaire d’un contrôlleur C et de deux routeurs R1 et R2. L’adresse IP de R2 est 147.94.66.131 l’adresse de B est servhttp.com et écoute sur le port 80.

Remarquez que la connexion entre R1 et R2 n’a pas été fermée.

2.2. Dans un premier temps programmez un routeur sans gérer la requête CONN.

(a) En utilisant telnet, vérifiez que vous pouvez vous connecter à travers plusieurs routeurs. Pour cela utilisez comme destination un serveur echo.

2.3. Programmez un contrôleur qui ne gére pas CONN et vérifiez que tout fonctionne. En particulier vérifiez, en utilisant ethereal, que les message sont bien ceux attendus. Essayez l’ensemble des cas suivants :

(a) contrôleur en mode simulation vers un serveur echo en utilisant un, deux et trois routeurs.

2.4. Ajoutez le service CONN au routeur et au contrôleur. Vérifiez que tout fonctionne correctement :

(a) Soit le tunnel suivant : un contrôleur sur 127.0.0.1:9090, le routeur sur 127.0.0.1:9091, un serveur echo sur 127.0.0.1:3000. En utilisant ethernet donnez les trames qui correspondent à la connexion de deux clients echo qui se connectent au serveur echo via le tunnel.

(b) Recommencez en ajoutant un second routeur, puis un troisième (toujours sur l’ordinateur local).

(c) Vérifiez que les connexions fonctionnent toujours même lorsque les ordinateurs sont différents.

2.5. Ajoutez la fonctionnalité mode proxy http au contrôleur.

(a) Vérifiez en vous connectant via le contrôleur vers votre site personnel ou sur n’importe quel site hébergé par daumier. N’oubliez pas de vérifier avec ethereal que les paquets sont bien envoyés via le contrôleur.