Les compagnies de téléphones mobiles Béton, ElleSaitPasFaire, et Bleue, ont monté un consortium afin de mettre au point un nouveau système de sms fondé sur les toutes dernières technologies. En particulier, on veut mettre au point une technique pour qu'un sms qui ne réussit pas à partir d'un téléphone essaie de repartir tout seul, évitant ainsi au propriétaire du téléphone de retaper tout un tas de touches au clavier. La première tâche est de proposer une architecture pour ce projet, et de le simuler.
Pour cela, après mûre réflexion, elles ont décidé de faire appel à vos services. Vous recevez le cahier des charges ci-dessous.
Il s'agit de faire communiquer entre eux un certain nombre de téléphones. Chaque téléphone sera modélisé par un processus indépendant, ne partageant donc pas de mémoire avec les autres téléphones.

Un téléphone n'a qu'un seul canal d'émission et de réception. Ce canal ne peut accepter qu'un seul sms à la fois; il ne peut pas émettre en même temps qu'il reçoit, et il ne peut pas recevoir plusieurs sms en même temps. Les messages qui sortent du téléphone ou qui y arrivent doivent donc attendre que le canal soit libre. On considère pour simplifier que les téléphones ont une mémoire infinie. Les téléphones ne communiquent pas entre eux directement. Ils passent par un central, qui reçoit les sms et les redirige vers le bon correspondant. Les sms arrivant en provenance d'un téléphone doivent attendre dans le central que le canal de réception et d'émission se libère.
Les limites suivantes sont fixées :

• Dans le central, N messages peuvent attendre qu'un téléphone donné soit disponible
• et dans un téléphone, M sms peuvent attendre de partir.

Question 1 (7 points)

La modélisation du comportement d'un téléphone et du central se fera sous forme de threads. Un téléphone est un processus qui passe son temps à attendre des messages ou à essayer d'en émettre. Des messages sont écrit (aléatoirement) par le propriétaire du téléphone, et ces messages vont attendre de pouvoir partir.
Le central est un processus qui passe son temps à attendre des messages, et à les réémettre vers les bons destinataires. Les téléphones et le central ne partagent donc pas de mémoire.

• Faites un dessin de ce qui ce passe.
• De combien de threads avez-vous besoin ?
• Potentiellement, combien de problème(s) de type producteur/consommateur peut-il exister ?
• On impose à la modélisation de contenir au moins un problème producteur-consommateur dans un téléphone (mais vous pouvez en mettre plus). En fonction de la discussion précédente, proposez une modélisation, et justifiez vos choix (en particulier le nombre de problèmes producteur-consommateur que vous allez utiliser).
  De combien de sémaphores avez-vous besoin ?
• Décrivez le fonctionnement d'un téléphone.
  Décrivez le fonctionnement du central.

Question 2 (3 points)

Quelles sont les possibilités qui s'offrent à vous pour effectuer le transfert d'un message depuis un des téléphones vers un autre téléphone ? Choisissez, après justification, une de ces possibilités.
Pour un exemple de générateur aléatoire de sms, vous pouvez télécharger le lien suivant. Pour le décompresser, tapez la commande 'tar zxvf sms.tz'.
Un message est une suite de caractères de longueur aléatoire. Proposez un "protocole de communication" pour pouvoir transférer proprement le message (en d'autres termes, vous ne pouvez pas vous contenter de transmettre juste la chaîne de caractère).

Question 3 (5 points)

Concevez un gestionnaire de type "ligne de commande" qui lancera les divers processus.
Le gestionnaire devra s'occuper de synchroniser les temps (les tours) des différents téléphones: chaque téléphone peut émettre ou recevoir au maximum un seul sms par tour (mais plusieurs sms peuvent vouloir arriver en même temps sur un téléphone donné). Cela veut dire qu'un téléphone va faire un certain nombre d'actions différentes, et qu'il va s'arrêter à un moment donné pour attendre que tous les autres téléphones aient fini leurs actions.
Que proposez-vous pour simuler ce mécanisme ? Discutez plusieurs possibilités, et choisissez (et justifiez) celle qui vous semble la meilleure.

Première programmation

• le nombre de téléphones présents sur le réseau,
• le nombre de sms pouvant être en attente dans un téléphone,
• le nombre de sms pouvant attendre dans le central pour un téléphone donné,
• le pourcentage de chance d'émettre un sms pour un téléphone (par tour).

• Commencez par programmer un téléphone, et testez le tout seul (comment faire ?).
• Programmez le central tout seul et testez le tout seul (comment faire ?)
• Programmez le gestionnaire pour lancer plusieurs téléphones et les synchroniser.
• Mettez le tout ensemble.

Question 4 (5 points)

Les téléphones peuvent être hors réseau. Dans ce cas un message ne peut pas arriver sur ce téléphone ni en partir. De même, le central peut être en maintenance, auquel cas, aucun téléphone ne reçoit de message, ni ne peut en émettre.
On simulera ce comportement en ajoutant un temps aléatoire à la date d'arrivée de chaque message.
Les usagers n'aiment pas que leurs messages mettent trop de temps à arriver. Proposez une manière de connaître pour chaque message, le temps passé depuis l'émission du message vers le central. Lorsqu'un message a passé trop de temps depuis son émission, il doit devenir prioritaire.

• Que signifie "être prioritaire" ? Discutez et proposez une définition.
• Quels mécanismes pouvez-vous mettre en oeuvre pour simuler ce comportement ?
• Choisissez, après justification, un des mécanismes proposés.

Deuxième programmation

• un temps T moyen de transmission
• un écart E par rapport à cette transmission

Bonus

Consignes :

• Vous devez m'envoyer avant le ?? janvier 2006 dernier délai une archive en tar.gz ou en .zip, contenant le code, le makefile, et le rapport du projet. Le rapport papier doit être déposé le même jour au secrétariat A2SI. Un barème de "moins deux points" par jour de retard sera appliqué. Une archive qui ne sera ni du tar.gz ni du .zip ne sera pas corrigée.
• Le projet devra se compiler en exécutant la commande make sur une machine tournant sous Linux. Un projet qui ne respectera pas cette consigne ne pourra pas être corrigé.
  Note: Le projet sera compilé et exécuté par votre correcteur sur une des machines de l'école. Assurez vous que le projet fonctionne donc correctement sur une de ces machines là.
• Il est souhaitable de rendre toutes les étapes de la programmation, afin qu'en cas de problème sur le programme final, on puisse vérifier que les étapes précédentes fonctionnaient correctement. De même, si vous rendez les tests que vous avez faits, il en sera tenu compte.
• Le rapport du projet décrira les diverses solutions aux différents problèmes rencontrés, et justifiera les solutions choisies.
• Votre note dépendra pour moitié de la qualité du rapport, et pour moitié de la qualité du code. Il est très fortement suggéré de programmer votre code en plusieurs fichiers, chaque fichier contenant une partie "indépendante". A chaque fichier de code C devra être associé un fichier d'en-tête ".h".
  Le barème prend en compte pour une part la rédaction de la réponse, et également l'écriture du code correspondant aux choix que vous aurez faits. Vous pourrez donc avoir des points si vous n'avez pas programmé vos propositions, mais vous n'aurez pas forcément tous les points si le code que vous aurez écrit n'est pas proprement justifié.
  
  Rappel: l'espionnage industriel est passible de la peine de mort. Je ne sais pas quelle sanction maximale peut-être décidée par le conseil de discipline de l'ESIEE, mais le conseil de discipline peut décider de l'exclusion définitive des étudiants fautifs.