Projet 2
Ces projets sont l'application directe des notions vues dans la deuxième partie des cours de POD. Ils demandent d'implanter des des applications/applets graphiques et réseau clients/serveurs via des sockets ou en RMI.

Certains projets sont plus rapides à réaliser que d'autres. Il en sera tenu compte a la correction. Sauf indication contraire, chaque projet est à réaliser en binôme. Pour choisir les projets, la règle du bus sera encore une fois utilisée. Il n'y aura pas plus de 3 groupes sur un même projet.


Présentation du projet : lundi 14 decembre 1998



1  Liste des sujets

1.1  Robots en clients/serveurs

Le but de ce projet est de réaliser un monde de robots en RMI. Un monde est donc un objet accessible dans un serveur RMI. Les robots communiquent avec lui pour les déplacements. On reprend la classification des robots (fixe, amical, fou, poli, suiveur, ...) en ajoutant un robot manipulé au clavier/souris. Enfin différents mondes peuvent communiquer : il existe des portes pour passer d'un monde à l'autre. Tous les mondes sont sur le serveur RMI.


Ce projet est réaliser par groupe de 2.



1.2  Producteur-Consomateur

Le but de ce projet est de réaliser un producteur-consomateur en RMI. Ce sujet s'inspirera fortement du TP2. À la place du R(e)MI's bar, On s'intéressera au R(e)MI's restaurant. Le restaurant est une salle contenant des tables de différentes tailles (table de 2, de 4, de 6) pouvant être assemblées entre elles, de manière optionnelle. Un groupe de clients arrive pour dejeuner. Selon la place disponible Remi les place (de manière optimale?) ou leur indique un temps d'attente (selon le déroulement du repas des autres clients). Dans le cas où il y a de l'attente, le groupe de clients peut décider d'aller dejeuner ailleurs, ou de se mettre dans la file d'attente. Enfin si le temps indiqué est dépassé le groupe de clients impatient peut alors décider de partir de la file.

Le restaurant sera un objet du serveur RMI. Les groupes de clients invoqueront ses méthodes distantes. On ajoutera un client spécial, le ``visualisateur'', qui affichera, sous forme graphique, létat du restaurant (tables occupées et libres, file d'attente). Si vous avez le temps vous pourrez implanter plusieurs restaurants selon le même schéma. Les clients passant d'un restaurant à l'autre sont de moins en moins difficiles par rapport à l'attente.

Ce projet est pour un groupe de 2 personnes.



1.3  Serveur d'Applets

Le but de ce projet est de réaliser un serveur d'applets. L'idée est de sauvegarder l'état d'une applet sous forme d'un persistant pouvant être rechargée par la suite. On définit une classe pour ces applets qui permet de sauver l'etat de l'applet sur le serveur et la recharger. Pour la recharger, il est nécessaire de se resynchroniser.
Il est demandé décrire un serveur générique pour cette classe et de faire une mini-application pour un monde de robots avec seulement quelques robots animés implantés.

Ce projet est à réaliser à 2.



1.4  Equilibrage de charge

Le but de ce projet est de simuler un calcul parallèle avec équilibrage de charge. Pour cela un calcul est découpé. Un calcul est découpé en groupes de threads tournant sur plusieurs machines. Chaque machine a un serveur acceptant le départ ou l'arrivée d'un ou plusieurs threads. Le choix d'un départ peut être la charge de la machine sur laquelle le processus travaille, c'est à dire le temps que le processus met pour un calcul de base.


On applique ce principe au calcul des générations du jeu de la vie. Une thread speciale demande aux serveurs de threads le résultat

du calcul pour une génération donnée. Chaque thread est synchronisée sur celle-ci pour récupérer le travail accompli par les autres. Enfin un client graphique affiche létat d'avancement de chacune des threads et leur localisation.


Ce projet est à réaliser à 2 ou 3 selon la complexité du client graphique.



1.5  Robots autonomes

Le but de ce projet est de manipuler des robots autonomes. Un robot possède des capteurs : rencontre d'un obstacle, timers, lecture optique de marques (au sol) ...Un robot ne sait faire que quelques actions simples : se déplacer, changer de direction, ...Deux modes sont à implanter : l'un où le robot envoie les informations de ses capteurs à un programme de contrôle du robot qui décidera des actions à effectuer, l'autre mode où le robot est complètement autonome : des actions simples sont indiquées pour traiter des évènements provenant des capteurs.
On appliquera ces robots à la sortie d'un labyrhinte. Le suivi du robot sera une applet.

Ce projet est à réaliser à 3 si les 2 modes sont implantés.



1.6  Agents mobiles et routage

Le but de ce projet est de définir un mécasnime de routage pour des agents mobiles. Pour cela on définit des applications routeur (soit en sockets+ persistant, soit en RMI) qui au début connaissent les positins (adresses) de chaque agent. Un agent se trouve toujours sur un routeur. Quand un agent migre, il indique au routeur de sa position de départ où il va, puis lui confirme son arrivée. les 2 routeurs se mettent à jour. Chaque routeur connait un début de chemin pour atteindre chaque agent. Ceux-ci comuniquent entre eux. Chaque routeur connaissant la position initiale de chaque agent, une requête est envoyée à ce routeur.Si l'agent destinataire est encore là, il transmet le message, sinon il le renvoie au routeur où l'agent est parti et le mécanisme se répète.
Un message peut donc passer par un certain nombre de routeurs avant d'atteindre son destinaire. Ce projet se divise en 2 selon les options choisies pour la conservation des routes.

  1. Un routeur ne connait qu'un seul autre routeur pour acheminer un message. Quand un agent passe par lui, il met à jour sa table de routage.
  2. Un routeur connait la route complète vers un agent. Pour cela chaque déplacement est confirmé à tous les routeurs. Attention dans ce cas, il peut avoir 2 messages de confirmation de déplacement dún même agent au même routeur. Il faut alors ajouter une marque (de temps ou de numero de deplacement) aux confirmations.
Dans les 2 cas un message ne peut atteindre un agent que si l'agent a bien confirmer son déplacement. S'il ne l'a pas fait, les messages pour cet agent sont en attente sur le routeur.


Ce projet est à réaliser par groupe de 2 (pour chaque option) avec +1 par type d'applications implantées.


Les applications proposées sont :
  1. livreur de Pizza : Quelques agents sont des pizzerias, les autres sont des programmeurs qui mangent des pizzas. Quand un porgrammeur a faim, il commande une pizza à une des pizzerias. Celle-ci doit lui livrer la pizza dans un temps raisonable. Le programmeur est un programmeur qui se déplace très souvent, au livreur de l'atteindre rapidement. Un programmeur peut changer de pizzeria si sa pizzeria habituelle est trop lente à livrer.
  2. Interpol : Un agent est recherché par un ou plusieurs autres agents. Pour attraper le premier un des agents de recherche doit être physiquement sur un routeur quand le premier arrive.

1.7  Graphisme

  1. Editeur de circuits

    Le but de ce projet est d'écrire un éditeur structuré de boites. Une boite est représentée par un certain nombre de fils d'entrée et de sortie. A partir de boites de base, on construit un circuit qui peut contenir plusieurs boites dont certains fils sont reliés entre eux. Les fils libres deviennent les entrées et les sorties de cette nouvelle boite. Cette nouvelle boite, une fois sauvée, peut etre utilisée pour l'édition d'une autre.
    Il y a 2 visions pour une boite : une vision extérieur où seuls les fils d'entrée et de sortie sont visibles et une vision interne où l'on regarde à l'interieur.
    Une application directe est par exemple l'édition de circuits logiques.
    Une extension directe est de simuler l'état du circuit : pour certaines valeurs initiales (des fils d'entrée (et de sortie)) les valeurs se propagent dans tout le circuit avec visualisation.
    Une deuxième extension est de faire un serveur RMI des composants déjà définis.


    Ce projet est à réaliser à 2 personnes + 1 personne par extension.

  2. Applet Graphics pour O'Caml

    Le but de ce projet est d'interfacer au niveau du graphisme O'Caml et Java. L'applet Java et l'appliation O'Caml communiquent via des sockets. Quand O'Caml veut exécuter un ordre graphique, il envoie une chaine de caractères 0à une applet Java. Quand un évènement survient dans l'applet Java, il est envoyé sous forme texte à l'application O'Caml. Pour cela Il est demandé de définir un protocole texte pour la communication. D'écrire un nouveau module Graphics qui redéfinit les différentes fonctions O'Caml en fonction du protocole définit. Par exemple la fonction open_graph établira une connexion avec l'applet et demandera d'ouvrir un composant graphique.


    Ce projet est à réaliser à 3 personnes si vous implantez toute la bilioth`eque graphique (1 pour le protocole, 1 pour la partie Java et 1 pour la partie O'Caml). Une quatrième personne peut s'intégrer au groupe pour construire différents jeux dessai conséquents dont les sources seront fournies : jeux à 2 joueurs, robots joueurs ...

    .

2  Rendu de projet

Vous rendrez courant janvier 1999 au cours ou en TD du module Programmation Objet et Distribution un rapport contenant une brève description générale du problème, une description de la hiérarchie de classes utilisées, des principaux algorithmes et des protocoles de communications, un listing commenté, un petit manuel d'utilisateur et des jeux d'essai. Pour pouvoir tester votre programme il est demandé d'installer, dans un catalogue de votre compte sur les machines Linux de l'UFR,les binaires et les sources du projet. Les sources doivent être compatibles avec le compilateur JDK installé et le compilateur O'Caml 2.01 installé sur les machines de maîtrise.

This document was translated from LATEX by HEVEA.