Rapport de mini-projet : Chat Room over UDP

Rapport de mini-projet : Chat Room over UDP
Réalisé par : Sondes Larafa & Hechmi SOLTANI
Tests effectués
I. Tests côté client :
Connexion au serveur :
On lance le client dans l’un des cas suivants : serveur non démarré, numéro de port différent
du port d’écoute du serveur ou machine serveur inexistante. Le client envoie alors sa demande
de connexion au serveur et reste bloqué car il ne reçoit aucune réponse de ce dernier. Il faut
alors intervenir manuellement (Ctrl-c) pour stopper l’exécution.
Pour remédier à ce problème, nous avons imposé au client un délai maximal d’attente
d'
établissement de la connexion au delà duquel on rompt la tentative et on avertit l’utilisateur
avec un message d'
erreur en expliquant le problème et en suggérant de vérifier certains
paramètres de la connexion.
La valeur par défaut de ce délai est de 15 secondes. Il s'
agit d'
une valeur purement théorique
adaptée au cas d’un petit sous réseau de type 157.159.xyz.255. Pour pouvoir prendre en
compte les délais éventuels de latence dans les réseaux, nous avons ajouté la possibilité de
faire passer la variable délai maximal en ligne de commande. On lance alors la commande
suivante :
java Sock_client delai_max
Gestion des paramètres de connexion entrés par l’utilisateur :
Voici notre fenêtre de connexion au serveur de chat :
2
Les valeurs entrées sont vérifiées immédiatement quand on clique sur connexion : un pseudo
vide provoque un message d’erreur et une re-proposition de la fenêtre. Une machine serveur
inexistante provoque également un message d’erreur. Pour le numéro de port, nous vérifions
qu’il est bien un entier et qu’il est compris entre 1024 et 65536.
Gestion de la déconnexion brusque du client :
Au cas où un utilisateur ferme sa fenêtre de chat sans se déconnecter, le client demeure
connecté pour le serveur. Pour résoudre ce problème, nous avons rajouté une classe qui gère
l’évènement de fermeture de la fenêtre. Dans cette classe, le client envoie un message au
serveur pour l’avertir de sa déconnexion et se déconnecte.
Gestion des messages du client :
Quand le client n’est pas connecté, le client ne peut pas entreprendre d’envoi de messages
vers le serveur. Nous avons alors désactivé la zone de texte destinée à recevoir les messages
de l’utilisateur quand la connexion n’est pas établie.
Temps nécessaire pour se connecter au serveur :
Nous nous sommes proposés d’effectuer des tests sur le temps nécessaire à l’établissement de
la connexion d’un client. Pour cela nous avons utilisé le fichier de test :
TempsDemandeConnexion.java.
On lance le serveur tout d’abord, puis on lance la commande suivante :
java TempsDemandeConnexion <serveur> <port>
Ce programme fournit alors une mesure du temps qui s’est écoulé entre l’envoi de la demande
de connexion et la réception de la confirmation du serveur.
Résultats de ces tests :
Le fichier des tests obtenu est « testTempsConnexion.txt » pour une boucle de 50 demandes de
connexions.
Le tableau suivant illustre des résultats obtenus pour différents nombres de demandes :
3
Nombre de demandes
Temps (millisecondes)
50
7
100
4
1000
2
Temps nécessaire pour recevoir la liste des connectés :
Pour lancer ce test, on utilise le fichier « TempsDemandeReceptionChatList.java ». La
commande à exécuter est de cette forme :
java TempsDemandeReceptionChatList <serveur> <portServeur>
Le fichier « testTempsDemandeChatList.txt » contient les résultats correspondant à une
boucle de 50 demandes de liste de connectés. Dans ce cas, la moyenne est de 8 millisecondes.
II. Tests côté serveur :
Nombre maximal de requêtes « presque » simultanées que le serveur peut traiter :
Pour lancer ce type de test, on utilise le fichier « Bombarder_serveur.java ». La commande à
exécuter est de cette forme :
java Bombarder_serveur <serveur> <portServeur> <nombre_de_requetes>
Nous avons effectués plusieurs bombardements du serveur en modifiant à chaque fois le
nombre de requêtes envoyés vers le serveur, nous avons pu dressé le tableau suivant :
Nombre de requêtes
Nombre de requêtes
enregistrées par le
serveur
250
500
600
700
1000
10000
250
500
497
502
439
500
Nous constatons que le serveur accepte un maximum de 500 clients. Il y a donc des requêtes
qui se sont perdus en route. Cette perte est due au protocole UDP qu’on utilise qui n’est pas
aussi fiable que TCP.
Nous avons effectué une autre expérience qui consiste à bombarder le serveur par un millier
de requêtes et envoyer à partir d’un autre client une requête. Cette requête est alors rejetée et
une exception est levée.
L’explication de ce rejet est que notre serveur est un serveur mono tâche qui ne peut pas
exécuter simultanément plusieurs instructions. Pour remédier à ce problème, il faut faire un
serveur multi-tâches (multi-threads). Dans ce cas, chaque client sera pris en charge par un
thread du serveur et le problème des requêtes simultanées ne se posera plus.
4