Un chat

L’objectif de ce projet est d’implémenter un chat en utilisant un processus par client et un processus comme contrôleur/répartiteur (baptisé par abus de langage serveur). L’objectif principal de ce projet et de mettre en évidence les difficultés d’écrire du code système correct/propre. Même si vous n’êtes pas capable d’arriver à la fin du projet, nous accorderons une importance capitale à la propreté du comportement (appels système testé, fichiers nettoyées, etc.).

Principe général

SCHEMA

L’architecture proposé est la suivante :

  • Un tube nommé (0), crée par le serveur et partagé par tous les clients, pour envoyer un message. Le format des messages est spécifié dans la partie protocole.

  • Un tube, crée par chaque client, pour recevoir les messages du serveur (au final des autres clients).

Chaque client lors de son démarrage se choisira un identifiant parmi les non utilisés et créera son tube. Il notifie le serveur de son existence en envoyant un message HELLO. Le serveur vient se connecter sur le tube du client.

Tous les fichiers seront crées dans un dossier (éventuellement configurable via la ligne de commande), par exemple /tmp/chat.

Les questions à vous poser sont (par exemple) les suivantes :

  • Comment garantir que l’identifiant choisi est réellement non utilisé ? (atomicité)
  • Dans quel cas y a-t-il (risque) inter-blocage.
  • Comment terminer proprement un client.

Protocole

  • Identifiant du client
  • Taille du message
  • Le message (payload)

Nous définissons un message spécial : HELLO. Si un message a une taille nulle, on considère qu’il s’agit d’un message spécial de bienvenue. Le contrôleur essayera de se connecter au tube correspondant.

Paliers intermédiaires

La base line
Un exécutable pour le contrôleur, un exécutable pour le client. Il ne doit pas y avoir d’inter-leaving dans les messages reçus.
Un peu mieux
Le client déclenchera le contrôleur, s’il n’existe pas déjà. Enfin quand on dit un peu mieux, il s’agit en fait de beaucoup mieux. Le faire fonctionner dans tous les cas peut s’avérer compliqué.
Gestion des signaux
Pour terminer le contrôleur, on se propose de lui envoyer le signal SIGINT.
Le controlleur en tâche de fond
Essayer de lancer le contrôleur en tâche de fond (daemon).
Des threads
On pourra utiliser des threads à la place des processus en interne dans le client.
Un protocole un peu plus founky
Vous pouvez étendre le protocole afin qu’il fasse ce qui vous parait bien. Probablement l’idée la plus sympa serait de rajouter la notion de canal, seuls les membres d’un canal voient les messages sur ce canal. Le canal zéro peut représenter le broadcast.
Poste-restante
Utilisation de file de message pour faire un système de poste restante …

Rendu

  • Votre code (via votre dépôt git). Le code devra obligatoirement contenir un Makefile valide qui construira TOUS les exécutables de votre projet.
  • Un rapport de 1 à 3 pages (en pdf) sur les fonctionnalités gérées par votre implémentation, les fonctionnalités non gérés (les cas pathologiques) et le pourquoi vous n’avez pas réussi.