IMA4 2016/2017 ECP1 - Historique des versions

Hdelatte : /* remarques */

2017-09-04T18:59:22Z

‎remarques

Hdelatte : /* remarques */

2017-09-04T18:58:56Z

‎remarques

Rex : /* Points ajoutés */

2017-08-29T11:04:16Z

‎Points ajoutés

Rex : /* points ajoutés */

2017-08-29T10:57:16Z

‎points ajoutés

Rex : /* points revus */

2017-08-29T10:57:04Z

‎points revus

Hdelatte : /* Tests */

2017-08-23T19:28:51Z

‎Tests

Hdelatte : /* Tests */

2017-08-23T18:47:33Z

‎Tests

Hdelatte : /* Compléments du projet suite au jury du 6 juillet */

2017-08-23T18:23:05Z

‎Compléments du projet suite au jury du 6 juillet

Hdelatte : /* Documents */

2017-08-23T16:45:23Z

‎Documents

Hdelatte : /* Rendu projet final */

2017-08-23T16:42:23Z

‎Rendu projet final

@@ Ligne 670 : / Ligne 670 : @@
 ==remarques==
 [[Fichier:Projet final.zip]]
 [[Fichier:Serveur revu.zip]]

@@ Ligne 670 : / Ligne 670 : @@
 ==remarques==
 [[Fichier:Projet final.zip]]
 == Sources ==

@@ Ligne 601 : / Ligne 601 : @@
 ===Points ajoutés===
-J'ai mis à jour la lecture et l’écriture sur mon interface virtuelle. J'utilise toujours la fonction sprintf pour pouvoir transformer la trame reçue sous forme de String, pour quelle soit comprise par mon simulateur. J'ai enlevé plusieurs lignes de code que j'ai réussi à simplifier.
+J'ai mis à jour la lecture et l’écriture sur mon interface virtuelle. J'utilise toujours la fonction sprintf pour pouvoir transformer la trame reçue sous forme de String, pour qu'elle soit comprise par mon simulateur. J'ai enlevé plusieurs lignes de code que j'ai réussi à simplifier.
 Pour pouvoir envoyer les trames de réponse sur mon interface virtuelle, j'ai dû les modifier pour qu'elles soient compréhensibles par le système d'exploitation. Ne trouvant pas de fonction adaptée, j'ai créé une fonction moi-même s’appelant "conv", qui permet de placer les trames de type string dans un tableau de caractère avec un chiffre hexadécimal par case. Je peux donc renvoyer ce tableau de caractère au système d'exploitation qui comprend à présent les réponses ARP ou ICMP qu'il reçoit.
@@ Ligne 613 : / Ligne 613 : @@
 Toutefois, je dois préciser l'option -W 30 lors du ping afin que le système attende plus longtemps les réponses qui prennent un temps plus long à circuler dans le simulateur.
-Avant de mettre en place la gestion des messages ICMP 5, j'ai du créer un nouveau scenario '''routeur_s4.html'''. En effet, dans le scénario s3 il n'y avait qu'un seul routeur. Or, pour pouvoir utiliser la redirection de route, il me fallait au moins deux routeurs sur le même réseau. Mon nouveau scénario reprend donc le scénario s3 en ajoutant un routeur relié au réseau 192.168.1.0/24 et au nouveau réseau 192.168.3.0/24 composé que d'une seule station"station 5". Comme vous pourrez le constater, ma station 1 ne connaît pas l’existence de ce nouveau routeur. Ici le but est d'ajouter à sa table de routage les chemins lorsque c'est nécessaire .
+Avant de mettre en place la gestion des messages ICMP 5, j'ai du créer un nouveau scenario '''routeur_s4.html'''. En effet, dans le scénario s3 il n'y avait qu'un seul routeur. Or, pour pouvoir utiliser la redirection de route, il me fallait au moins deux routeurs sur le même réseau. Mon nouveau scénario reprend donc le scénario s3 en ajoutant un routeur relié au réseau 192.168.1.0/24 et au nouveau réseau 192.168.3.0/24 composé que d'une seule station"station 5". Comme vous pourrez le constater, ma station 1 ne connaît pas l’existence de ce nouveau routeur. Ici le but est d'ajouter à sa table de routage les chemins lorsque c'est nécessaire.
 J'ai mis en place plusieurs fonctions afin de permettre un ajout à la table de routage. la fonction '''redirection''' ,déclenchée lorsque qu'un message arrive au niveau d'un routeur, permet de vérifier si le destinataire de ce message est dans le même réseau que l’émetteur. Si c'est le cas, le routeur continue de transmettre le message normalement et envoie de plus un message ICMP 5 de redirection à la station émettrice. Lorsque la station émettrice reçoit ce type de message, elle ajoute le nouveau routeur à sa table grâce à la fonction '''route_add_entry'''. Pour éviter que cette manipulation d'ajout se déclenche plusieurs fois, j'ai créé une fonction nommée '''route_check_entry''' qui vérifie, avant un ajout, si la table ne contient pas déjà cette route. Évidemment, le but du projet était aussi d'envoyer ce message au système qui ajouterait lui même à sa table, la route en question. Je fais donc circuler le message ICMP5 via mon serveur de façon à ce que cela se fasse. Après cela, lors de l'envoie d'un ping, je constate que le message ne passe plus par la gateway mais directement par le '''routeur 2'''.

@@ Ligne 599 : / Ligne 599 : @@
 Pour terminer, j'ai relu l'ensemble des lignes de codes que j'avais implémentées afin de corriger les possibles erreurs.
-===points ajoutés===
+===Points ajoutés===
 J'ai mis à jour la lecture et l’écriture sur mon interface virtuelle. J'utilise toujours la fonction sprintf pour pouvoir transformer la trame reçue sous forme de String, pour quelle soit comprise par mon simulateur. J'ai enlevé plusieurs lignes de code que j'ai réussi à simplifier.

@@ Ligne 587 : / Ligne 587 : @@
 *optimisation du code.
-===points revus===
+===Points revus===
 J'ai tout d'abord repris le squelette du serveur WebSocket que mon professeur m'avait proposé où j'ai réimplémenté mon interface virtuelle qui n'a fait l'objet d'aucune remarque du professeur. J'ai veillé à bien utiliser la fonction callback pour l'envoi et la réception de données dans le navigateur.

@@ Ligne 647 : / Ligne 647 : @@
 [[Fichier:Video1 delatte.MP4]]
 Dans la seconde vidéo, nous envoyons un ping à la station 192.168.3.1 qui se situe donc dans un réseau différent de ma station émettrice. Le système, qui ne connaît pas le chemin vers ce réseau, envoie son message ICMP à son routeur par défaut, que j'ai configuré comme étant le routeur 192.168.1.1. Le routeur par défaut, ayant dans sa table de routage l'information nécessaire, transmet le message ICMP au routeur 2 qui pourra enfin router ce message vers la station dans le réseau 192.162.1.3. Le message de réponse est renvoyé directement vers la station 1 et apparaît dans le terminal.
@@ Ligne 654 : / Ligne 653 : @@
 Lorsque le premier message de réponse est reçu par le terminal, j'envoie un nouveau ping à la même station. On constate cette fois que cette requête ne passe plus par le routeur par défaut mais directement par le routeur 2. Cela confirme l'ajout de la route optimale dans la table de routage du système.
 ===consignes===

← Version précédente		Version du 23 août 2017 à 18:47
Ligne 645 :		Ligne 645 :

	Dans la première vidéo, on envoie un ping à l'adresse 192.168.1.200. On voit tout d’abord un message ARP passer qui remplit la cache ARP du systeme, qui envoie ensuite un message icmp, que l'on visualise sur le simulateur. La station en question répond à ce message. On voit ensuite, dans le terminal, que nous recevons bien un paquet ICMP de réponses.		Dans la première vidéo, on envoie un ping à l'adresse 192.168.1.200. On voit tout d’abord un message ARP passer qui remplit la cache ARP du systeme, qui envoie ensuite un message icmp, que l'on visualise sur le simulateur. La station en question répond à ce message. On voit ensuite, dans le terminal, que nous recevons bien un paquet ICMP de réponses.
		+
		+	[[Fichier:Video1 delatte.MP4]]

@@ Ligne 580 : / Ligne 580 : @@
 =Compléments du projet suite au jury du 6 juillet =
+[[Fichier:Projet final.zip]]
 ===Demandes du professeur===
 *reprise du serveur websocket et utilisation de la fonction callback pour l'envoi et la réception de données dans le navigateur.
@@ Ligne 666 : / Ligne 666 : @@
 ==remarques==
 == Sources ==

← Version précédente		Version du 23 août 2017 à 16:45
Ligne 481 :		Ligne 481 :
	valid_lft forever preferred_lft forever		valid_lft forever preferred_lft forever

−	~~== Documents ==~~
−	~~[[Fichier:Serveur.txt]]~~
	=Rendu projet pour le 6 juillet=		=Rendu projet pour le 6 juillet=

@@ Ligne 483 : / Ligne 483 : @@
 == Documents ==
 [[Fichier:Serveur.txt]]
-=Rendu projet final=
+=Rendu projet pour le 6 juillet=
 C'est ici que vous trouverez le rendu de mon projet en pièce jointe. Il y aura un dossier nommé "serveur" qui contiendra le dossier "serveur.c" et un fichier "réseau" qui contiendra tous les fichiers relatifs au simulateur (la majorité des fonctions se trouve dans reseau.js). Je vais de plus essayer de détailler les différentes fonctions que j'ai modifiées ou créées, et d'indiquer où elles se trouvent pour que vous puissiez vous retrouver dans les différentes pages de code. J'ai partagé mon travail en plusieurs parties sur lesquelles je travaillais en parallèle. Ces parties sont listées ci dessous. Il est important de préciser que j'ai fait mes tests qu'avec la page html "routeur_s3".