Rapport du Projet de Chat Basé sur les socket UDP I. But du projet ...

Rapport du Projet de Chat Basé sur les socket UDP
I. But du projet:
• mettre en oeuvre les mécanismes de diffusion fournis par les interfaces socket.
• Construire un chat simplifier en utilisant les datagramme UDP et en utilisant la fonction broadcast.
Pour ce faire nous avons deux fichiers un pour le client et le second pour le serveur.
I. Quelques indications sur le mode de programmation du client et du serveur.
• Le code du client est multi­threads en effet:
• Un thread écoute en permanence les messages venant du serveur pour les afficher sur l'écran du client .
• Un thread traite les envois du nickname et autres types de messages.
Pour la nature des messages envoyés on a au début envoyé une structure de données qui contenait trois champs un champ
identifiant la nature du message (demande de joindre le chat, d'avoir la liste des membres ...) et on a exécuté notre
programme ce cette façon. On a ensuite opté pour un deuxième choix qui consiste a envoyer une seule chaîne de caractère
pour tous les types de messages émis et ceci afin d'accroître les performances de notre chat. Et du coté du serveur, il y a
traitement de la chaîne reçu et reconstitution de toutes les données nécessaires en connaissant la nature du message en
déchiffrant seulement le premier caractère de la chaîne .
La première façon était plus facile a programmer mais plus gourmande en terme de ressources mémoire.
* Pour le stockage des nicknames on a choisi la liste chaînée pour profiter du fait qu'on était en C et parce que c'était à notre
avis une élégante façon de faire au lieu de les rentrer dans un fichier ou bien dans un tableau dont on connait pas la taille
d'avance.
• Dans une première étape le serveur avait un seul fil d'exécution. En effet il traitait les messages un par un.
Mais l'inconvénient de ce type d'architecture c'est que comme on est en UDP s'il y a un message qui arrive au serveur
alors que celui ci était en train de traiter le le buffer en cours, la perte immédiate de ce message s'en suit.
Une des solutions possibles et de dupliquer le serveur (avec des fork ou des threads).On a pensé au début a créer autant de
fils qu'il y avait de client dans notre salon de chat mais on s'est vite rendu compte que ce serait très gourmand en ressource
en effet si le client n'était pas très actif on lui aurait réservé des ressources qu'il n'était pas entrain d'exploiter efficacement.
Donc une des architectures qu'on a voulu faire était la suivante :
Le programme
principal réceptionne
Un thread qui
qui traite
le message
reçu
Réception du message
aussitôt les nouveaux
messages

A chaque fois que le serveur reçoit un buffer il crée un thread qui va s'occuper de traiter l'information reçu. Ainsi dans le
cas ou le serveur ne reçoit aucun message il y aura un seul fil d'exécution et au dans l'autre cas extrême si tous les clients
envoient au même temps il y aura autant de threads s'exécutant en parallèle que de clients dans le chat.
On a réalisé cette architecture uniquement pour les messages que veulent broadcaster les client dans le sous réseau car c'est
le message le plus fréquent reçu par le serveur et on optimisera ainsi ce traitement .
Au début pour créer plusieurs fils d'exécution on travaillé avec des fork et on a aussitôt changé pour les threads pour
l'unique raison que le fork duplique le processus, alors que le thread crée un ensemble d'instructions qui s'exécutent en
parallèle dans le même processus. ce qui nous permettra d'accroître les performances.
Mode d'utilisation des fichiers:
Nous disposant de deux fichiers c
Compilez les fichiers avec make.
Dès que vous lancer le client on vous demande de rentrer votre nickname. Le serveur vérifie que le nickname n'est pas déjà
existant et établit votre connection au chat. Dans le cas ou le nickname est déjà existant il vous demande de rentrer a
nouveau un nouveau nickname.
Par la suite vous pouvez chater avec tous les client qui sont connectés au serveur est qui se trouvent dans le sous réseau.
Vous disposez de deux fonctions en dehors de celle d'envoi et de réception de messages.
La première est la fonction chat_list:
cette fonction nous permet de visualiser l'ensemble des personnes connectées au serveur.
La seconde fonction fournie est chat_leave:
cette fonction nous permet de nous déconnecter du serveur et du coup informera tous les clients du nickname déconnecté.
I. Les Tests:
Les Test:
Dans cette partie nous allons effectuer différents types de tests afin de connaître les limites de notre programme et de
montrer les améliorations qui pourrais y être intégrer.
1. Le fichier client_nick.c:
Pour cette partie nous allons essayer de nous connecter au serveur avec plusieurs clients. Pour ce faire nous allons envoyer
au serveur plusieurs Nickname ( Plus de 20000) est nous allons constater les perte de datagrammes et la limite du serveur
on constant la saturation de ce dernier.
Il suffit pour effectuer ce test de compiler le fichier client_nick.c en tapant la commande make. Puis en tapant make
client_nick. Il faut que le serveur soit déjà lancer au auparavant bien évidement.
Résulats des test:
nous remarquons que le seuil de saturation est d'environs 1000 client connecté. Sachant qu'il y a plusieurs requête qui ont
étés ignorer ou pas pris en compte par le serveur.
Exemple:
dans le fichier client_nick.c nous faisons une boucle for pour envoyer 10000 demande de connections au serveur. Le
serveur sature au bout de 4800 demande de Nickname et le nombre de personne qui on effectivement reçus leur nickname
sont de l'ordre de 1080. Ce qui fait plus de 77% de tentative de connections non réussite.
1. Le fichier client_nick_time.c:
Pour ce test nous allons essayer de calculer le temps de réponse du serveur avec biensur les containtes du réseau mis a
disposition. Ces résultats peuvent donc varier en fonction de ce dernier.
Pour ce faire nous allons utiliser le fichier client_nick_time.c la compilation s'effectue avec la commande make
client_nick_time. Le serveur doit être lancer au auparavant bien évidement.
Nous allons prendre le temps que mais le système pour effectuer le chat_join.
Nous obtenant le résultat suivant:
Vous pouvez regarder le résultat en tapant la commande gnuplot et puis tapez: « load ''plot.gpl'' »
on remarque dans le graphe que le temps de réponse augmente proportionelement au nombre de personnes connectées.
Cela s'explique car le serveur doit vérifier l'existence du nickname dans le buffer avant de l'enregistrer. Plus la taille du
buffer est grande plus ça prend de temps.

• Le fichier client_broad_bombard.c:
Ce test a pour but de vérifier la capacité du serveur a supporter un envoie massif de messages par les clients. Pour ce faire
nous envoyons plusieurs messages sans attendre la réponse du serveur pour saturer ce dernier.
Résultat du test:
Nous avons remarqué qu'il existait deux cas de figures. Le premier cas consiste à la saturation pure est simple du serveur et
de sont arrêt par conséquent. Le deuxième cas consiste a l'ignorance d'une grande partie des messages envoyés a ce dernier.
• Le fichier client_broad_temp.c:
Ce test nous permet de connaître le temps de traitement du braodcast d'un message d'un client vers tous les autres clients
connectés au serveur et se trouvant dans le sous réseau de ce dernier.
Le temps de traitement est calculé et s'affiche a l'ecran du client: on mesure environ 1500 microsecondes.
• Le fichier client_chat_list.c:
Nous allons entrer 6 personnes dans le chat et nous allons lancer la commande chat_list pour obtenir la liste des connectés
au serveur. Le test mesure le temps temps d'exécution de cette commande.
Résultats: on mesure une valeur d'environ 1180 micro­seconde.
• Le fichier client_leave_chat_time.c:
Dans ce test nous allons exécuter la commande du chat_leave cette derniere enlève une personne du tableau de nickname et
informe tous les client connecté du départ de la personne du chat.
Le temps pris par cette commande est de 1093 micro­seconde.
Conclusion:
Suite au différents tests que nous avons pu effectuer nous pouvons constater que le serveur ne peut supporter un grand
nombre de messages entrant simultanément car cela provoquera soit son plantage pur est simple, soit la perte des messages.
Les temps de reponse des différentes fonctions du chat reste très correcte pour l'usage du chat. Reste a savoir si le résultat
serais le même pour des machines ne se trouvant pas dans le même sous réseau( surement pas!).