3 Le processus gérant
3.1 Objectif
Une fois le serveur de jeu mis en oeuvre, on se propose d'implanter un
processus gérant, chargé de la gestion des joueurs et de la ``supervision'' du
jeu. En lançant ce processus gérant, l'administrateur peut à tout moment
intervenir pour espionner les prises de jeu, déconnecter un joueur, .... Le
processus gérant communique avec le processus serveur par IPC (Files de
messages). Dans le serveur, un thread est chargé de traiter d'éventuelles
requêtes de l'administrateur.
3.2 Les requêtes de l'administrateur
L'administrateur lance le processus gérant chaque fois qu'il veut effectuer une
requête (la requête est fournie en argument). Dans un premier temps, on suppose
que les requêtes sont effectuées séquentiellement, c'est à dire que
l'administrateur ne lance qu'un processus gérant à la fois. Les requêtes que
peut effectuer l'administrateur sont les suivantes:
-
lister_joueurs : afficher la liste des joueurs actuellement connectés.
- deconnecter <joueur> : Déconnecter le joueur dont le nom est <joueur>.
- scruter_recus : espionner les prises de jeu pour obtenir toutes les
prises de jeu sous la forme <numeros_grilleA> <numeros_grilleB>
type_prise. Les arguments désignent respectivement les numéros joués dans
la grille A, le(s) numéro(s) joué(s) dans la grille B et le type de prise
de jeu (bulletin ou Flash). L'espionnage ne se termine que lorsque
l'administrateur envoie le signal SIGINT en tapant CTRL-C.
- arreter_serveur : arrêter le serveur.
- aide : obtenir la liste des requêtes possibles.
Tout dialogue nécessaire entre le processus serveur et le processus gérant est
réalisé par des communications IPC (envoi et réception de messages).
3.3 Organisation modulaire
Pour garder l'organisation modulaire de votre projet, vous utiliserez les deux
répertoires :
-
Ipc : pour la bibliothèque libipc.
- Admin : pour le programme d'administration.
3.4 Réalisation
Les commandes sont passées en argument au processus gérant (donc pas
d'interface textuelle, mais une analyse des arguments au moyen de getopt_long).
Ce processus communique avec le serveur au moyen de 2 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
gérant. 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).