« INFO625 : Réseau » : différence entre les versions
Ligne 41 : | Ligne 41 : | ||
Vous pouvez changer le port avec l'option <tt>--port numero_de_port</tt> si vous voulez pouvoir faire des salles de discussions séparées (chaque numéro de port correspondra à une salle différente). |
Vous pouvez changer le port avec l'option <tt>--port numero_de_port</tt> si vous voulez pouvoir faire des salles de discussions séparées (chaque numéro de port correspondra à une salle différente). |
||
Ce programme d'un peu moins de 200 lignes contient quelques fonctions auxiliaires qui n'ont pas grand chose à voir avec le réseau et d'autres fonctions qui s'occupe de la communication. Voici un synopsis du mécanisme de communication via les '' |
Ce programme d'un peu moins de 200 lignes contient quelques fonctions auxiliaires qui n'ont pas grand chose à voir avec le réseau et d'autres fonctions qui s'occupe de la communication. Voici un synopsis du mécanisme de communication via les ''sockets'', dans le cas particulier d'UDP/IP: |
||
# On crée un socket avec la fonction <tt>socket</tt>. Un socket est un descripteur de fichier (un entier donc) dans lequel on peut lire et écrire, mais ces lectures et écritures correspondent respectivement à des |
# On crée un socket avec la fonction <tt>socket</tt>. Un socket est un descripteur de fichier (un entier donc) dans lequel on peut lire et écrire, mais ces lectures et écritures correspondent respectivement à des réceptions et émissions sur le réseau. On peut changer quelques options de ce socket avec la fonction <tt>setsockopt</tt>. |
||
# On relie ce socket |
# On relie ce socket à notre propre adresse, cela est indispensable car la même machine peut avoir beaucoup d'interfaces réseaux différentes (ethernet, wifi, bluetooth, ...), utilisant des protocoles de communications parfois différents. |
||
# En UDP, on peut alors lire et écrire dans le socket avec les fonctions <tt>sendto</tt> et <tt>rcvfrom</tt> car le mode UDP est sans connexion. |
# En UDP, on peut alors lire et écrire dans le socket avec les fonctions <tt>sendto</tt> et <tt>rcvfrom</tt> car le mode UDP est sans connexion. |
||
Identifiez les différentes fonctions de notre programme s'occupant du réseau et tentez à l'aide des pages de manuels des fonctions citées ci-dessus d'anaysez ce qu'elles font, de manière assez surperficielle, car il y a de nombreux détails subtiles ... '''Notez vos conclusions.''' |
Identifiez les différentes fonctions de notre programme s'occupant du réseau et tentez à l'aide des pages de manuels des fonctions citées ci-dessus d'anaysez ce qu'elles font, de manière assez surperficielle, car il y a de nombreux détails subtiles ... '''Notez vos conclusions.''' |
||
* '''Quel est la convention |
* '''Quel est la convention utilisée pour les messages sur le réseau ?''' |
||
* '''La taille maximum des messages n'est pas garantie. |
* '''La taille maximum des messages n'est pas garantie (<tt>MAX_MSG</tt>). Trouvez l'origine de ce problème et corrigez le.''' |
||
=== Gestion distribuées de la fiabilté === |
=== Gestion distribuées de la fiabilté === |
Version du 2 décembre 2010 à 21:08
Plan détailé du cours
Non encore disponible
TP 1
Objectifs Globaux
Il s'agit de comprendre la programmation d'applications réseau utilisant les protocoles TCP et UDP d'IPv4 (on ne s'intéressera pas malheureusement à IPv6 faute d'infrastructure réseau sur le site ... Il est pourtant possible d'adapter le code pour qu'il marche sur IPv4 et IPv6)
L'application sera une messagerie instantanée de paire-à-paire (Peer-to-Peer instant messagerie) utilisant UDP et implémentant la fiabilité de manière distribuée. On utilisera TCP pour la connexion initiale aux salles de discussion et, si le temps le permet, pour enregistrer les salles de discussions sur un serveur web afin de les rendre visibles.
Vous serez évalué sur un compte-rendu répondant aux questions (en gras) de ce document et le rendu de votre programme par mail.
ATTENTION : si votre programme ne compile pas vous serez noté seulement sur le compte-rendu. De plus, chaque warning avec les options -Wall -pedantic -std=c99 enlève 1 point.
Préliminaires
Utiliser les commandes Unix ifconfig, route et arp -a pour connaître la configuration de votre machine. Utiliser ping et traceroute entre les machines fixes de la salle et les portables en vpn pour découvrir une partie de l'achitecture réseau de l'université. Notez vos conclusions.
Compilation et analyse du programme initial
Le programme initial est constitué d'un seul fichier p2pchat.c que vous pouvez compiler avec la commande:
$ gcc -o p2pchat -Wall -pedantic -std=c99 p2pchat.c
Lorsque vous lancez le programme en tapant
$ ./p2pchat mon_pseudo_favori
Tout ce que vous tapez est vu par les autres sur le même sous-réseau et vice-versa (les messages sont envoyés ligne par ligne. Pour terminer la conversation, il faut taper Ctrl-D qui ferme le fichier d'entrée standard stdin.
Vous pouvez changer le port avec l'option --port numero_de_port si vous voulez pouvoir faire des salles de discussions séparées (chaque numéro de port correspondra à une salle différente).
Ce programme d'un peu moins de 200 lignes contient quelques fonctions auxiliaires qui n'ont pas grand chose à voir avec le réseau et d'autres fonctions qui s'occupe de la communication. Voici un synopsis du mécanisme de communication via les sockets, dans le cas particulier d'UDP/IP:
- On crée un socket avec la fonction socket. Un socket est un descripteur de fichier (un entier donc) dans lequel on peut lire et écrire, mais ces lectures et écritures correspondent respectivement à des réceptions et émissions sur le réseau. On peut changer quelques options de ce socket avec la fonction setsockopt.
- On relie ce socket à notre propre adresse, cela est indispensable car la même machine peut avoir beaucoup d'interfaces réseaux différentes (ethernet, wifi, bluetooth, ...), utilisant des protocoles de communications parfois différents.
- En UDP, on peut alors lire et écrire dans le socket avec les fonctions sendto et rcvfrom car le mode UDP est sans connexion.
Identifiez les différentes fonctions de notre programme s'occupant du réseau et tentez à l'aide des pages de manuels des fonctions citées ci-dessus d'anaysez ce qu'elles font, de manière assez surperficielle, car il y a de nombreux détails subtiles ... Notez vos conclusions.
- Quel est la convention utilisée pour les messages sur le réseau ?
- La taille maximum des messages n'est pas garantie (MAX_MSG). Trouvez l'origine de ce problème et corrigez le.
Gestion distribuées de la fiabilté
le protocole UDP/IP ne gère par la fiabilité. On pourrait utiliser TCP/IP, mais on perdrait la possibilité de demander les messages à non reçu quelqu'un de proche de nous ... Voici donc une proposition de gestion distribuée de la fiabilité :
- Stocker les messages dans un dossier local, avec un fichier associé à chaque pseudo. Il faudra ajouter une option pour contrôler le nom de ce dossier. Cela permet deux choses, garder trace des discussions anciennes et réexpédier n'importe quel message qui aurait été perdu par une machine. Conseil: sauvegarder les messages avec une taille fixe, ce qui perd un peu de place mais permet d'accéder directement au message numéro n avec fseek. (rappel les fonctions pour manipuler les fichiers dont vous aurez besoin sont fopen, fclose, fseek, fwrite, fread . Pour déterminer la taille du fichier (et donc le nombre initial de messgages, on pourra utiliser fseek et fpos ou bien stat. Remarque : on ne cherchera pas à ouvrir tous les fichiers au départ; on ouvrira le fichier corrspondant à un pseudo uniquement à la reception d'un message provenant de ce pseudo. De plus, il ne faut pas laisser trop de fichiers ouverts, donc on prendra soin de refermer les fichiers après usage.
- On détectera les messages perdus grâce au numéro de message de l'émetteur. Une fois détectée la perte d'un message, on le redemande à une machine prise au hasard sur le réseau de discussion, qui répond seulement si elle a le message. On fait cela avec un timeout. Voici le code permettant de générer un appel de fonction après un certain temps :
sighandler