Vous êtes sur la page 1sur 4

Universit de Rennes 1

DESS Isa - 1998/99

TP REDI n1
But : apprentissage de l'interface de programmation (appel socket) propos par le systme dexploitation Unix pour raliser des applications communicantes en utilisant les protocoles de la famille Internet.
Latence [Petit Robert], n.f. : tat de ce qui est cach, latent. Temps de latence : dure s'coulant entre un stimulus et la raction.

1. Prsentation
On envisage de raliser une application (rpartie) permettant de mesurer le temps de latence des communications entre deux stations situes sur un rseau utilisant les protocoles de la famille Internet. L'interface de programmation de ces communications sous Unix sont des sockets. Dans un premier temps, on vous demande d'utiliser les fichiers excutables fournis puis de visiter le code propos, ceci afin de rpondre aux questions et ainsi concevoir au mieux votre application. Dans un deuxime temps, on vous propose de raliser cette application (en vous inspirant des fichiers mis votre disposition) afin de rpondre aux dernires questions. Pour faciliter votre comprhension puis le dveloppement de votre propre code, plusieurs fichiers sont mis votre disposition : des fichiers excutables et les fichiers de code correspondants. Ils se trouvent sous le rpertoire ~dessisa/unix/redi/TP1.

2. Apprentissage
On vous propose d'utiliser les fichiers du (sous-)rpertoire Demandeur-repondeur. Recopiez ces fichiers. Lisez le fichier README : pour comprendre le fonctionnement du programme, la gnration des excutables et l'utilisation des commandes qui vous sont proposs. Rpondez aux questions suivantes l'aide ces programmes (et de vos connaissances). 1- Quel est le temps de latence entre votre station et une des stations voisines ? Quel est le numro de port du rpondeur ? Quel est le numro de port du demandeur ? 2- Quels sont les protocoles utiliss (indice : la commande man et le cours !) ? 3- Vrifiez quil est impossible deux processus situs sur la mme machine dutiliser le mme port. Quel est le message gnr ? Vrifiez quil est possible au processus de demande de calculer le temps de latence en sauto-envoyant une demande. 4- Pourquoi a-t-on choisi de mesurer le temps de latence sur un aller-retour et non pas simplement un seul trajet ? (indice : mise l'heure et NTP)

5- Rptez plusieurs fois la mesure du temps de latence entre les deux mmes stations. On constate que l'environnement une influence sur ces mesures. Caractrisez prcisment les diffrentes constituants de cet environnement ? Est-il facile de corriger ces inconvnients ? 6- Lorsque vous tentez de calculer pour la toute premire fois un temps de latence vers une autre station, la dure obtenue est souvent plus importante que les fois suivantes. Pourquoi ? (Vrifiez laide de la commande arp que cest bien la toute premire fois). 7- Les mesures sont entaches d'un certain nombre d'erreurs. Quelles sont-elles ? Proposez quelques solutions pour amliorer vos mesures (indices : place de vos points de mesure dans le code, prcision de lhorloge). 8- Quand et comment devriez-vous lancer votre processus de rponse pour qu'il puisse ragir toutes sollicitations (indice : les processus deamon, la commande inetd) ? 9- Que pourrait-il se passer si plusieurs processus de demande situs sur des stations diffrentes accdent simultanment au mme processus de rponse situ sur la mme station (hypothse : la dure de traitement du message de demande est trs importante) ? Discutez de ce qui se passerait si la communication utilisait le protocole UDP (indice : la fonction fork()). Proposez une solution pour le protocole TCP (indice : les fonctions listen(), accept() et fork()). 10- Que pourrait-il se passer si plusieurs processus de demande situs sur la mme station accdent simultanment au mme processus de rponse situ sur la mme station ? Proposez une solution (indice : allocation dynamique). Y a t-il un problme si deux processus demandeur situs sur deux stations diffrentes utilise le mme port ? 11- Pourquoi arrive-t-il que le processus demandeur se bloque lorsque vous lancez un trs grand nombre dchanges et que le rseau est charg (indice : la commande perfmeter) ? Proposez une solution. 12- Est-il possible dutiliser le service standard dcho pour calculer la latence ? Quel est le numro de port associ un tel service ? Quelle diffrence y a t-il entre le service rendu par echo et celui du rpondeur ? 13- Mesurez linfluence de la longueur des messages changs sur la latence. On vous propose de faire plusieurs fois une dizaine dchanges pour des messages de 1, 1024, 10000, 20000, 40000 et 60000 octets. Effectuez vos mesures, entre deux stations diffrentes (prcisez lesquelles), puis sur une seule station en auto-envoi. Tracez les courbes (en retenant les valeurs significatives), proposez une quation, calculez le dbit utile.

3. Application
3.1- Prsentation On vous propose maintenant de raliser votre propre programme. Attention : ne tenez compte que des remarques qui sont essentielles au bon fonctionnement de votre programme et qui vous ont t formules travers certaines des questions prcdentes. Il est inutile (dans un premier temps) d'envisager un programme trop sophistiqu : vous ferez par exemple l'hypothse qu'il n'y a pas de perte, etc. Ce programme, inspir de celui qui vous est propos dans le (sous)rpertoire Demandeur-repondeur, devra utilis l'autre protocole de la famille Internet. 3.2- Conception L'application sera forme de 2 processus : un processus de demande et un processus de rponse. Le processus de demande est excut chaque fois qu'un utilisateur dsire mesurer le temps de latence entre une des stations du rseau munie d'un processus de rponse et la station

TP de Redi- DESS Isa

locale sur laquelle est excut le processus de demande. Le processus de rponse devra tre prsent, et lanc pralablement toute tentative de calcul du temps de latence, sur chaque station susceptible de devenir une extrmit rpondante de l'application. Le processus de demande met un message de demande vers la station munie du processus de rponse et note l'heure d'mission. Le processus de rponse lors de la rception du message de demande, met (retourne) le message reu vers la station ayant mis le message de demande. Le processus de demande, lors de la rception du message de rponse (s'il correspond bien son message de demande), note l'heure d'arrive. La diffrence des deux heures est, bien entendu, gale au temps de latence. 3.3- Spcification de linterface La commande associe au processus de rponse aura un paramtre optionnel permettant de prciser le numro du port utilis. La commande associe au processus de demande aura un premier paramtre permettant de dterminer le nom de la station distante et des paramtres optionnels dfinissant la longueur du message change, le nombre de messages changs, le numro de port du rpondeur et celui du demandeur. Le processus de demande doit afficher le nom de la station locale, le nom de la station distante suivi des temps de latence minimum, moyen et maximum en microseconde. En cas de problme, un message d'erreur explicite doit tre affich. La valeur de retour de la commande devant tre ngative. 3.4- Dveloppement On vous propose de dvelopper les versions suivantes : 1.0 : version simple (une seule connexion traite la fois) 1.1 : version 1.0 avec envoi multiple de messages 1.2 : version 1.1 avec longueur variable des messages 1.3 : version 1.2 avec sous-serveurs 1.4 : version 1.3 avec temporisateur Testez compltement et chaque fois votre version avant de passer la suivante. Noubliez pas de sauvegarder le code avant de passer la version suivante. Pour assurer l'interoprabilit entre les processus des diffrentes quipes (un processus de demande dvelopp par une quipe devant tre compatible avec un processus de rponse d'une autre quipe), nous vous proposons d'utiliser les constantes et les formats prdfinis dans le fichier latence.h, puis de vrifiez cette interoprabilit. 3.5- Questions A l'aide de votre propre programme rpondez aux trois premires questions, puis la dernire. I- Donnez la latence minimum, moyenne et maximum pour changer un octet entre deux stations proches. Prcisez le nom de ces deux stations et les paramtres de l'exprience. II- Donnez la latence minimum, moyenne et maximum pour changer un octet entre deux stations plus loignes. Prcisez le nom de ces deux stations et les conditions de l'exprience. III- Comment le rpondeur sait-il que le demandeur a termin la communication ? Vrifiez que les connexions que vous tablissez sont correctement fermes. A laide de la commande netstat, indiquez quels sont les diffrents tats que prend vos connexions. A quoi correspondent-ils ? Quels sont les tats qui apparaissent lorsque le rpondeur na pas ferm son extrmit alors que le demandeur la fait (du cot rpondeur et du ct demandeur).

TP de Redi- DESS Isa

IV- Quelles diffrences (protocoles employs, services) y a-t-il entre votre application et celle associe la commande ping ?

4. Les rponses
Vous devez fournir les rponses aux question I IV et le code de la dernire version correcte de votre application, sous forme lectronique, dans le (sous-)rpertoire Reponses. Consultez le fichier _README, pour plus de prcisions.

TP de Redi- DESS Isa

Vous aimerez peut-être aussi