3 Un processus gérant
3.1 Objectif
Une fois le serveur d'enchères mis en oeuvre, on se propose
d'implanter un processus gérant, chargé de la gestion des utilisateurs
et de la ``surveillance'' des enchères. En lançant ce processus
gérant, l'administrateur peut à tout moment intervenir pour annuler
une vente, espionner les enchères, déconnecter un utilisateur, ....
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 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_produits :
- lister tous les produits mis en vente,
- retirer <n> :
- retirer le produit <n> de la vente,
- lister_utls :
- donner pour chaque produit mis en vente,
la liste des utilisateurs participant aux enchères,
- déconnecter <client> :
- terminer la connexion du client,
- scruter_messages :
- espionner les enchères pour obtenir toutes
les offres d'enchères sous la forme <produit> <utl> <enchère>.
L'espionnage ne se termine que lorsque l'administrateur envoie
le signal SIGINT en tapant CTRL-C,
- stopper :
- stopper 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
On ajoutera deux nouveaux répertoires au projet :
-
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).