1 Description générale du projet
1.1 Objectif
L'objectif du projet est de concevoir et de réaliser un mécanisme rudimentaire
de conférences entre utilisateurs, contrôlable par un administrateur.
Un serveur maintient des canaux de communication auxquels les clients
utilisateurs peuvent s'abonner. En s'abonnant à un canal, un client connecté
au serveur par telnet ou nc, peut envoyer un message sur le canal.
Ce message est immédiatement transmis aux autres abonnés (les messages ne
sont pas mémorisés) et donc, un abonné "voit" tous les messages envoyés sur
le canal auquel il est abonné.
L'administrateur, chargé de la gestion des canaux et des utilisateurs, peut à
tout moment intervenir pour valider ou invalider un canal, espionner les
communications, déconnecter un utilisateur, ....
1.2 Architecture générale de l'application
L'application est constituée de 2 processus : le processus serveur et le
processus gérant. Pour permettre de traiter simultanément les requêtes de
plusieurs clients ainsi que celles de l'administrateur, le serveur doit
être multithreadé. Un thread est lancé pour chaque connexion de client,
ce thread est chargé de satisfaire les requêtes de ce client.
De même, un thread est chargé de traiter d'éventuelles requêtes de
l'administrateur. Pour chacune de ses requêtes, l'administrateur lance
le processus gérant. Celui-ci communique avec le processus serveur par
IPC (Files de messages).
1.3 Les requêtes client
Un client, ayant obtenu une connexion par nc <host> <port> peut
émettre les requêtes suivantes au serveur :
-
lister_canaux :
- lister les titres des canaux valides,
- créer <titre> :
- demande de création d'un nouveau canal nommé
<titre>. Si la demande est acceptée, le canal est créé mais non
validé. Seul l'administrateur peut vraiment le valider,
- quitter :
- déconnexion,
- abonner <n> :
- demande d'abonnement au canal numéro <n>
( le canal doit être valide et le client peut être abonné au plus à un
canal).
Un client abonné à un canal peut effectuer les requêtes suivantes :
-
envoyer <msg> :
- permet d'envoyer un nouveau message sur le
canal,
- lister_abonnés :
- obtenir la liste des clients abonnés au canal,
- censurer <utl> :
- filtrer les messages en lecture ; le client ne
verra plus les messages écrits par <utl>,
- quitter_canal :
- fin d'abonnement.
1.4 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_canaux :
- lister tous les canaux (valides et non-valides),
- valider <n> :
- valider le canal numéro <n>,
- invalider <n> :
- invalider le canal numéro <n>,
- libérer <n> :
- supprimer le canal numéro <n>,
- lister_utls :
- lister pour chaque canal valide, les clients
abonnés,
- déconnecter <client> :
- terminer la connexion du client,
- scruter_messages :
- espionner les canaux pour obtenir tous les
messages sous la forme <canal> <utl> <msg>. 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).
1.5 Le serveur
Le processus serveur tourne en tâche de fond. Il doit pouvoir traiter les
demandes de connexion des clients, les requêtes des clients connectés et les
requêtes du processus gérant. Pour cela, il lance un thread chargé de traiter
la file de messages dans laquelle sont déposées les requêtes du gérant et un
thread "client" pour chaque connexion sur son port d'écoute. Ce dernier
thread est chargé de traiter les requêtes du client connecté.