RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005

Transcription

1 Oussama ELKACHOINDI Wajdi MEHENNI RAPPORT DU PREMIER MINI PROJET «FORUM DE CHAT» Novembre 2005 Sommaire

2 I. Préliminaire : Notice d exécution et mode opératoire...4 II. Architecture globale de l application...5 A.Côté Client Architecture des clients Fonctionnalités des classes principales d un client.5 B.Côté Serveur Architecture du serveur Fonctionnalités des classes principales du serveur III. Les Tests de l application IV. Tests de la performance du serveur et interprétation...12 ANNEXES

3 INTRODUCTION Ce premier mini projet de forum chat a pour but de montrer notre capacité à utiliser les outils de bases des communications distantes. Le sujet est assez ouvert nous laissant ainsi libre de concevoir une application assez personnelle. Les seules contraintes du sujet sont d implémenter deux fichiers sources sock_client et sock_serveur permettant la communication à travers un forum chat, où le serveur diffuse les messages par l intermédiaire d un broadcast. Le choix du langage de programmation étant libre et ayant fait la majorité des travaux pratiques en C, nous avons opté pour une application en langage objet (JAVA). Nous avons inclus une interface graphique permettant ainsi aux clients une meilleure utilisation à la fois fonctionnelle et conviviale. Ce rapport a pour but d améliorer la compréhension de l architecture de notre programme. Pour cela nous avons fait le choix d expliciter une notice d utilisation permettant ainsi à l utilisateur d exécuter l application. Nous avons également décrit l architecture du côté client et du côté serveur en explicitant les classes les plus importantes et nous avons fourni un diagramme de classes simplifié. Pour finir vous trouverez les différents tests que nous pensions important pour le bon déroulement de l application. Ce mini projet ne se limitait pas à la création et au développement d une application, nous devions également étudier les performances de l architecture demandée. Pour cela nous avons implémenter des programmes C utilisant la librairie MPI permettant ainsi de tester les fonctions principales et de donner des conclusions. 3

4 I. Préliminaire : Notice d exécution et mode opératoire. Compilation : Pour compiler tapez «make». Première étape : L activation du serveur avant d activer les clients. Récupérer l adresse IP de la machine en exécutant la commande ifconfig sous Unix et ipconfig sous Windows Ouvrir un terminal et écrire la ligne de commande : java sock_serveur A ce moment précis le serveur est activé et peut donc recueillir les requêtes des clients. Deuxième étape : L activation des clients. Sur des machines distantes (également sur la machine où le serveur est présent) ouvrir un terminal et écrire la ligne de commande : java sock_client adresseipserveur Où l adresseipserveur a été récupéré à la première étape Apparition d une fenêtre. Entrer votre pseudonyme et cliquer sur envoyer. Apparition de deux fenêtre. L une affichera les personnes connectées L autre servira d interface pour communiquer avec les autres personnes connectées. 4

5 II. Architecture globale de l application A. Côté Client 1. Architecture des clients Un client est organisé selon le schéma ci-dessous : Thread Sock_client -gérer la connexion et la déconnexion du client. -organiser l envoi et la réception des messages. Thread : ThreadEntree -gérer la réception des messages. Thread : ThreadSortie -gérer l envoi des messages. -vérifier la disponibilité du serveur Thread : FenetreDaffichag edesconnectes -Afficher la liste des connectés. 2. Fonctionnalités des classes principales d un client Sock_client.java : C est le thread «principal» qui tourne au niveau du client. Il gère la connexion du client (de façon indirecte à travers la classe Pseudo), sa déconnexion (voir méthode «chat_leave») et l envoi et la réception de messages. Cette communication se fait à travers la socket «socketchat» : socketchat = new DatagramSocket(PORT_CHAT_CLIENT); Pour garantir l indépendance des messages reçus et envoyés, on lance au niveau du client deux threads: «ThreadEntree» qui gère les messages reçus et «ThreadSortie» qui gère les messages envoyés. La méthode «chat» permet d afficher "From <nickname> : message» sur les différents clients. La méthode «chat_leave» gère la déconnexion du client. Ceci se fait par l intermédiaire d une socket (socketdepart). Au moment de sa déconnexion, le client envoie sur cette socket son «nickname» au serveur. Celui-ci le retire de la liste des connectés. Pseudo.java : Cette classe représente l interface graphique permettant à l utilisateur de saisir son «nickname». Une fois saisi, celui-ci est envoyé au serveur par l intermédiaire d une socket. Ceci se fait au niveau de la méthode «chat_join» : 5

6 paquetnickname = new DatagramPacket(buffNickname, buffnickname.length, addressnickname, PORT_NICKNAME); socketnickname.send(paquetnickname); Cette socket communique avec un thread lancé au niveau du serveur : «EnregistrementClient.java». Ce thread vérifie si le nickname choisi existe ou pas. Dans le premier cas, il répond le client par un booléen égal à «true» et le thread «Client» se lance. Dans le deuxième cas, il répond par «false» et une alerte se déclenche indiquant que le nickname choisi existe déjà et qu il faut le changer. En outre, au niveau de cette méthode, on vérifie si le serveur est disponible ou pas. Dans le premier cas, la méthode «chat_join» retourne un entier égal à 1. Dans le deuxième cas, cette méthode retourne un entier égal à 0 et une alerte s affiche au client lui indiquant l indisponibilité du serveur. FenetreDaffichageDesConnectes : C est un thread qui tourne au niveau du client. Il permet de recevoir un tableau contenant la liste des connectés du serveur, à travers une socket. La connexion est établie par l envoi d un «Ping» au serveur sur cette socket. Une fois la liste des connectés reçue, leurs «nicknames» sont affichés sur le poste client à l aide de la méthode «chat_list». ThreadEntree : C est un thread sur le client qui reçoit les messages de discussion envoyés par le serveur et les affiche sur l interface graphique du client. ThreadSortie : C est un thread tournant au niveau du client et permet d envoyer les messages saisis par l internaute au serveur sur la socket «socketenvoi». Ce thread vérifie avant d envoyer un message que le serveur est disponible à l aide de la méthode «tester» (cette méthode communique à travers la socket «sockettestconnexion» avec le thread «TestConnexionServeur» tournant sur le serveur). 6

7 B. Côté Serveur 1. Architecture du serveur : Un serveur est organisé selon le schéma ci-dessous : Thread : Sock_serveur -recevoir les messages envoyés par les clients et les diffuser. -gérer la liste des connectés. Thread : EnregistrementClient -reçoit les «nickanmes» des nouveaux clients et les enregistre. Thread : DepartClient -reçoit les «nicknames» des clients déconnectés et les retirent de la liste des connectés Thread : TestConnexionServ eur -reçoit des «ping» des clients et y répond lorsque le serveur est disponible. 2. Fonctionnalités des classes principales du serveur Sock_serveur.java : Cette classe représente le serveur. La méthode «run» se charge de recevoir les messages envoyés par les clients et de les diffuser sur tout le groupe : while (true) { InetAddress PORT_CHAT_CLIENT); } paquetrequetepourbroadcast = new DatagramPacket( donneesrequetepourbroadcast, donneesrequetepourbroadcast.length); serveur.receive(paquetrequetepourbroadcast); adressebroadcast = new String( extraireadresse(paquetrequetepourbroadcast)); paquetreponsepourbroadcast = new DatagramPacket( paquetrequetepourbroadcast.getdata(), paquetrequetepourbroadcast.getlength(), serveur.send(paquetreponsepourbroadcast);.getbyname(adressebroadcast), La méthode «list» permet d envoyer la liste des connectés au client (au thread FenetreDaffichageDesConnectes). Les «nicknames» des connectés sont sauvegardés dans un vecteur statique qui est «Internautes». Les méthodes «ajouterinternautes» et «retirerinternautes» permettent d enregistrer ou de retirer le nom d un internaute lors de sa connexion ou de sa déconnexion d un utilisateur. EnregistrementClient.java : Cette classe représente un thread qui tourne au niveau du serveur. Celui-ci reçoit par l intermédiaire d une socket le «nickname» du nouveau internaute connecté : paquetnickname = new DatagramPacket( donneesnickname, donneesnickname.length); socketnickname.receive(paquetnickname); 7

8 Il appelle par la suite la méthode «ajouterinternaute» de la classe «sock_serveur» pour enregistrer cet internaute. DepartClient : C est la classe équivalente à la précédente sauf qu elle gère les départs des internautes. Elle reçoit des messages de déconnexion du client (par l intermédiaire de la méthode «chat_leave») et appelle la méthode «retirerinternautes», de la classe Serveur, pour enlever le «nickname» de l utilisateur déconnecté de la liste des connectés. TestConnexionServeur : C est le thread qui reçoit les demandes de vérification de la disponibilité du serveur envoyés par les clients (envoyés au moment de l enregistrement et par le thread «ThreadSortie» au moment de l envoi d un message). Ce thread répond sur la socket «sockettestconnexion» par le message «pingserveur» pour annoncer la disponibilité du serveur : While (true) { byte[] donneesrequetetestconnexion = new byte[8]; paquetrequetetestconnexion = new DatagramPacket( donneesrequetetestconnexion, donneesrequetetestconnexion.length); sockettestconnexion.receive(paquetrequetetestconnexion); paquetreponsetestconnexion = new DatagramPacket("pingserveur".getBytes(), "pingserveur".length(), paquetrequetetestconnexion.getaddress(), paquetrequetetestconnexion.getport()); } sockettestconnexion.send(paquetreponsetestconnexion); 8

9 III. Les Tests de l application Vérification de l existence du nickname : Lors de l entrée du nom du client, le serveur vérifie (avant d ajouter le client dans son vecteur) si ce pseudo existe déjà. Si c est le cas alors un message d alerte apparaît afin de prévenir l utilisateur, et une fois que ce message d alerte est fermé l application cliente se ferme également. Vérification de la validité du nickname : L utilisateur doit saisir un nickname différent du caractère vide et du caractère (espace). Dans le cas contraire, une alerte s affiche en lui demandant de saisir un bon nickname. 9

10 Vérification de l existence du serveur en cours de discussion : Si le serveur a été déconnecté lors de l envoie du message d un client au serveur, un message d alerte apparaît et la fenêtre du client se ferme. Vérification de l existence du serveur au moment de la connexion : Si le serveur n est pas disponible au moment de la connexion d un client, un message d alerte apparaît et la fenêtre du client se ferme. 1

11 Vérification de l appartenance à la liste des connectés : Un client ne faisant pas parti de la liste des connectés ne peut pas envoyer ou recevoir des messages d autres clients membre d un chat (même s il est sur le même réseau local) : chaque groupe de clients est associé à un unique serveur. IV. Tests de la performance du serveur et interprétations Principe: Le principe de ces tests est de mesurer la performance du serveur lorsqu il est soumis à plusieurs demandes simultanés dans le cadre de ses fonctionnalités principales: chat_join(), chat_leave(), chat_list() et chat(). Test1: étudier la réaction du serveur face à des demandes simultanées d enregistrement par les clients: Nous avons implémenté un programme serveur «test_chat_join_serveur.c» dont le rôle est de simuler l action d enregistrement des clients sur le serveur de chat. Nous avons implémenté aussi un autre fichier «test_chat_join_client.c» qui se base sur MPI et qui permet de lancer plusieurs demandes d enregistrement vers un serveur fixé. NB: pour des mesures de facilité, nous avons fixé au préalable le serveur (poste6.int-evry.fr) et le nickname correspond au rang du processus. Ce test nous a montré que plus le nombre de demande d enregistrements augmente, plus le temps de service (le temps séparant le moment où le client envoie sa requête et le moment où il a reçu la réponse du serveur) augmente. Dans le tableau ci-dessous, on expose les résultats que nous avons eu: Nombre de processus (clients) Temps de service maximum des clients(en ms)

12 Test2: étudier la réaction du serveur face à des déconnexions simultanées des clients: Nous avons implémenté un client dont la seule tâche est d envoyer une requête de déconnexion. Ces clients vont envoyer des requêtes simultanées grâce à MPI. Le serveur a pour seul rôle de recevoir ces requêtes et de retirer l utilisateur de la liste des connectés. Comme le cas précédent, nous avons constaté que plus le nombre de demandes augmentent plus le temps de service de chaque client augmente. Le tableau suivant montre les résultats obtenus: Nombre de processus (clients) Temps de service max des clients (en ms)

13 Test3: étudier la réaction du serveur face à plusieurs envois simultanés de messages par les clients. Nous avons implémenté un programme serveur «test_chat_serveur.c» dont le rôle est de recevoir plusieurs messages de différents clients puis de renvoyer les message sur le sous réseau par l intermediare d un broadcast. Nous avons implémenté aussi un autre fichier «test_chat_client.c» qui se base sur MPI et qui permet de lancer plusieurs messages de clients différents Comme les cas précédents, nous avons constaté que plus le nombre de clients envoyant les messages est grandt plus le temps de service de chaque client augmente. Le tableau suivant montre les résultats obtenus: Nombre de processus (clients) Temps de service max des clients (en ms) 2 0, ,09 4 1,33 5 1,55 6 1,79 7 2,04 8 2,08 9 2,92 1

14 Conclusion Ce projet nous a permis de pouvoir manipuler d importantes notions de la programmation distante telles que les sockets et les threads, et nous avons pu ainsi nous rendre compte de certains problèmes de synchronisation. Le sujet nous avait été donné avant les travaux pratiques sur le protocole RPC et donc nous avons fait le choix de travailler uniquement avec des sockets. Mais il semble être plus pratique pour l affichage des clients connectés d exécuter directement une fonction du coté serveur, ce léger contretemps nous a ainsi permit de trouver par nous même une solution un peu plus complexe effectuant la même tâche. Les tests sur la performance du serveur, basés majoritairement sur nos connaissances de la librairie MPI, montre de manière explicite que l application entière (comportant les fonctions chat_join(), chat_leave(), chat_list() et chat()) se dégrade lorsque le nombre de clients augmente. Ces résultats semble logique car il est clair que la performance d un serveur n est pas linéaire et plus les applications sont nombreuses plus le temps passé à l'exécution d une requête est long du fait de la gestion des autres processus (attente, collision eventuelle...). 1

15 ANNEXES 1

16 FenetreDAffichage DesConnectes Fournir liste connectes Sock_serveur Ajouter nouveau internaute Supprimer un internaute PseudoFrame Fournir interface Lire le nickname saisi Ecouteur Envoyer nickname DepartClient EnregistrementClient Pseudo Alerte Echanger des messages Sock_client Sock_serveur ThreadSortie ThreadEntree Gérer messages recus Gérer messages envoyés Diagramme de classes simplifié.

17 1