2 Organisation du travail
2.1 Généralités
Il est fortement conseillé de suivre les étapes proposées ci-après pour réaliser le travail.
2.2 Organisation modulaire
Le projet est constitué du programme Arduino, de 3 bibliothèques et des programmes
serveur de jeu et client d'administration. Chacune de ces entités est développée
dans un répertoire propre. On gère donc les six répertoires suivants :
-
Costume -
- pour les sources du programme chargé sur la plate-forme
Arduino Lilypad ;
- Communication -
- pour les sources de la bibliothèque contenant les fonctions
de gestion réseau et série libcom ;
- Threads -
- pour les sources de la bibliothèque contenant les fonctions
de gestion des threads libthrd ;
- IPC -
- pour les sources de la bibliothèque contenant les fonctions de
gestion des communications inter-processus libipc ;
- Jeu -
- pour l'application de gestion des costumes et du jeu ;
- Administration -
- pour le client d'administration.
Cette arborescence et quelques squelettes de fichiers sont disponibles sous forme
d'un fichier au format tar et compressé à l'URL
http://www.plil.net/~rex/Enseignement/Systeme/Tutorat.IMA4sc.Mouton/mouton.tgz.
Transférez ce fichier dans votre compte Polytech'Lille et décompressez-le avec
la commande tar xvzf mouton.tgz. Vous pouvez constater que très peu de code
est fourni concernant l'application de gestion des costumes et du jeu :
-
quelques fonctions d'affichage dans la bibliothèque Communication pour impulser
l'affichage de déverminage ;
- le code des fonctions d'ouverture et de fermeture du port série.
Cependant, le répertoire créé contient déjà un fichier Makefile global et des Makefile
annexes dans chaque sous-répertoire. Vous avez un exemple de Makefile permettant de générer
un exécutable et un exemple de Makefile permettant de construire une bibliothèque. Appuyez
vous sur ces deux exemples pour compléter les autres Makefile. Le projet doit pouvoir être
généré par la simple commande make exécutée dans le répertoire principal du projet. Il doit
être aussi possible de regénérer complètement le projet par la commande make clean all lancée
du même répertoire.
Vous constaterez aussi la présence d'un répertoire Tests contenant des scripts PHP qui vont
vous permettre de tester la conformité de votre code aux spécifications. Plus de détails à ce propos
vous sont donnés dans la suite de ce document. Enfin un dernier répertoire XBee contient un
utilitaire qui peut vous aider pour configurer vos modules XBee. Le code de cet utilitaire
est suffisament clair pour que vous puissez en comprendre le fonctionnement en le lisant.
On prévoira de pouvoir compiler les différents sources avec un drapeau DEBUG (option
-DDEBUG de gcc), permettant un affichage conditionnel d'informations de déverminage
des programmes.
2.3 Sockets et serveur TCP
Il s'agit dans cette étape de réaliser un serveur TCP basique à l'aide de
l'interface de programmation des sockets.
Ecrivez dans le module libcom.c (répertoire Communication), les deux
fonctions suivantes :
-
int initialisationServeur(short int); Cette fonction prend en
paramètre le port sur lequel il faut écouter et retourne la socket de
lecture. Il vous est demandé d'activer l'option de réutilisation
d'adresse sur la socket d'écoute ainsi que de désactiver les tampons
TCP.
- int boucleServeur(int, void (*)(int)); Cette fonction effectue
l'écoute sur la socket passée en premier argument et lors d'une
connexion, exécute la fonction passée en second argument. Cette
fonction passée en argument doit être une fonction qui prend une socket
en unique paramètre. Lors d'une connexion de client, la fonction
boucleServeur lance donc cette fonction avec la socket de dialogue
en paramètre.
Testez cette bibliothèque en écrivant un programme jeu.c (répertoire
Jeu) qui l'utilise et dont la fonction de traitement des connexions
(celle appelée par boucleServeur) effectue juste une écriture de message
dans la socket et clôt la connexion. Pour écrire, et plus tard lire, sur la
connexion utilisez les fonctions classiques comme fgets ou fprintf.
Pour y arriver vous devez transformer le descripteur de socket en une structure
de fichier par la primitive fdopen.
Ce programme peut prendre des arguments : -p <port> ou --port <port>
pour spécifier un numéro de port différent de celui par défaut (port
4000). Pour traiter les arguments, utilisez la fonction
getopt_long (voir la page de manuel correspondante). Si les arguments
sont incorrects, on doit afficher un message qui précise la syntaxe.
Pour plus de clarté, l'analyse des arguments et l'affichage de la syntaxe
seront écrits dans des fonctions séparées.
Modifiez la fonction de traitement des connexions afin qu'elle ne ferme la
connexion qu'après le traitement des commandes pseudo et mode.
Testez votre serveur avec plusieurs commandes nc simultanées. Conclusion ?
Maintenant que vous avez écrit un embryon de serveur TCP, passez au client TCP.
Ajoutez les fonctions nomVersAdresse et connexionServeur dans
libcom. Réalisez un exécutable temporaire utilisant ces deux fonctions
pour se connecter sur le serveur jeu en envoyant les commandes pseudo
et mode.
2.4 Un serveur de jeu à base de processus légers
Pour que votre serveur de jeu puisse traiter plusieurs connexions simultanément,
vous allez lancer un processus léger (thread) par connexion. Pour cela, implémentez
la fonction publique de libthrd (répertoire Threads) :
int lanceThread(void (*)(int),int);
Cette fonction doit avoir comme action de lancer un thread dans le mode
détaché. Ce thread doit exécuter la fonction passée en paramètre. La dite
fonction prenant elle même comme paramètre le second paramètre de
lanceThread. Il vous est conseillé d'utiliser une fonction intermédiaire
récupérant un pointeur vers une structure comprenant les deux paramètres de
lanceThread.
Testez votre fonction lanceThread en créant une nouvelle fonction dans
jeu.c qui appelle votre fonction de traitement des connexions
via lanceThread. Utilisez la nouvelle fonction comme paramètre de
boucleServeur. Pour plus de clarté, ce serait une bonne idée de déplacer
les fonctions de traitement de connexions du fichier jeu.c vers
le fichier gestionConnexions.c.
Vérifiez que votre serveur est maintenant capable de gérer plusieurs
connexions simultanément (avec votre exécutable client TCP ou avec l'utilitaire
nc).
La fonction lanceThread est utilisée dans 4 situations différentes. Tout
d'abord comme expliqué plus haut pour gérer les connexions TCP ; dans ce cas
l'entier passé à la fonction paramètre est un descripteur de socket de dialogue.
La fonction lanceThread est aussi utilisée pour démarrer le processus léger
de gestion de la file de message d'administration, le processus léger de gestion
du costume et le processus léger de gestion de jeu.
2.5 Structure de données du serveur de jeu
La structure de données du serveur de jeu doit principalement permettre de gérer
les joueurs qui se connectent.
Définissez cette structure de données dans le fichier entête jeu.h et
écrivez sa fonction d'initialisation.
La structure des clients d'administration est plus à sa place dans le fichier entête
gestionAdmin.h.
2.6 Analyse des opérations sur la structure de données
Analysez les opérations nécessaires sur les structures de données afin de
déterminer celles qui nécessitent l'utilisation de sémaphores.
Implantez dans votre bibliothèque libthrd les deux fonctions publiques :
void P(int) ;
void V(int) ;
Ces fonctions cachent totalement le fait que vous utilisez des verrous
d'exclusion mutelle pour threads POSIX. En particulier, les verrous sont
représentés par une constante.
En implantant dans le module algorithmeMouton.c les fonctions nécessaires
à la gestion du jeu et dans le module commandesAdmin.c les fonctions
nécessaires à la gestion du client d'administration vous prendrez soin
d'y ajouter les poses et levées de verrous nécessaires.
2.7 Le client d'administration
Il vous faut implanter le client d'administration et le processus léger chargé
de traiter les requêtes de l'administrateur dans le serveur.
Les commandes sont passées en argument au client d'administration (donc pas
d'interface textuelle, mais une analyse des arguments au moyen de
getopt_long). Ce processus communique avec le serveur au moyen
de deux files de messages : une pour les commandes et une pour les réponses.
La file des commandes est créée par le serveur à l'initialisation. Un thread,
lancé par le serveur est chargé de scruter en permanence cette file. La file
des réponses est créée par le client d'administration.
La bibliothèque libipc contiendra toutes les fonctions permettant de
cacher le fait que la communication est implantée par IPC (selon le même
principe que celui utilisé pour les sémaphores).
Le processus léger de gestion des requêtes est lancé par la fonction lanceThread
de la bibliothèque libthrd. Cette fois le second paramètre n'est pas utile,
vous pouvez passer une valeur quelconque.
Lorsque que le serveur se termine, tous les clients d'administration
en mode de scrutation ou de reniflage doivent se terminer aussi.
2.8 Le serveur de jeu
Vous pouvez maintenant vous attaquer à l'écriture du code concernant le
serveur de jeu. Il vous est conseillé d'utiliser les fichiers suivants :
-
jeu.h : fichier des structures de données ;
- jeu.c : programme principal et analyse des arguments ;
- gestionAdmin.c : fonction de lecture de la file de message et
d'analyse des requêtes du client d'administration ;
- commandesAdmin.c : une fonction de traitement pour chaque type
de requête du client d'administration ;
- gestionConnexions.c : la fonction de gestion des demandes de
connexion des gestionnaire de costumes ;
- algorithmeMouton.c : implantation de l'algorithme de gestion
du jeu du mouton (gestion du costume et du jeu).
Détaillons le comportement du serveur de jeu :
-
lors de la connexion d'un gestionnaire de costume, le serveur de jeu
le signale en lui demandant d'allumer la LED du costume, initialement
éteinte, et de la passer à la couleur bleue ;
- en début d'étape, le serveur de jeu signale les gestionnaires de costumes
connectés, en demandant de passer leur LED à la couleur verte ;
- après un court instant, le serveur signale aux joueurs de se mettre en
position en leur demandant d'émettre un mi sur les buzzers et en
demandant aux vibreurs une activation courte ;
- quelques secondes après, les positions des joueurs sont relevées et les
gestionnaires de costumes sont signalés pour émettre un sol
sur les buzzers et lancer une autre vibration courte ;
- l'état des joueurs est mis à jour, les costumes des éliminés sont signalés
pour passer les LED en rouge et pour générer une vibration longue, les
costumes des gagnants sont signalés pour passer les LED en blanc et pour
émettre un la ;
- le serveur de jeu relance une étape si nécessaire.
Comme le protocole sur les connexions TCP est au format ASCII, le fonctionnement
du serveur de jeu peut être testé en lançant plusieurs nc, en lançant
manuellement la commande pseudo puis en répondant, toujours manuellement,
aux requêtes du serveur de jeu.
Pour réaliser la déconnexion d'un joueur, une solution consiste à ajouter un tube
(pipe) en variable globale. Le processus léger de gestion de costume se met alors
en écoute sur la connexion TCP vers le serveur de jeu et sur le tube (primitive
select). Si l'activité est détectée sur le tube, le processus léger se termine
sinon la commande du serveur de jeu est lue. L'arrêt d'un processus léger de gestion de
costume peut ainsi s'obtenir par simple écriture dans son tube.
Faites de même pour permettre l'arrêt du jeu en cours. La primitive select
est alors utilisée pour écouter sur un second tube tout en lançant le minuteur
utilisé en fin d'étape.
2.9 Tester votre application
Le répertoire Tests présent dans l'archive fournie contient deux programmes vous
permettant de tester votre application. Pour tester la gestion du costume et votre
programme Lilypad, lancez le script serveur.php. Connectez ensuite votre joueur
sur ce serveur (il écoute sur le port 4444). Vous verrez alors que le serveur lance
des commandes sur votre costume pour tester la bonne réceptions des commandes. Quand
vous aurez implanté votre algorithme de jeu, vous pourrez le tester avec le script
clients.php. Il suffit de le lancer après avoir lancé votre application. Le
script simule des clients se connectant sur votre serveur. Si vous démarrez le jeu,
le script affichera toutes les commandes reçues par les clients avec leurs réponses.