Index Suivant

1   Liste des sujets : VERSION PROVISOIRE

1.1   Services et Outils Système

  1. Environnement SHELL distribué
    L'environnement du SHELL devient distribué et conservé sur un serveur. Différents clients implantent les fonctionnalités suivantes :


    Un serveur contient une liste de clients qui peuvent se connecter au serveur. Chaque client s'enregistre sur un serveur où il est autorisé. Les noms de variables peuvent être globaux ou locaux à une machine, ou à un utilisateur. On utilisera une notation "point" pour ces paramètres locaux : machine.VAR ou user.VAR ou machine.user.VAR. Une première application sera d'écrire un fichier de login (partagé via NFS entre différentes machines) et mettant à jour correctement les ressources (imprimante, ..) de la machine locale.


  2. Duplicateur de courrier
    Une difficulté d'avoir plusieurs adresses électroniques, sur différents sites, est la quasi impossibilité d'avoir des boites aux lettres cohérentes, i.e. avec le même contenu. En effet rien n'empêche d'écrire à l'une ou à l'autre des adresse valides. L'ajout de copie via les fichiers .forward n'est pas une solution car il risque de provoquer des cycles dans l'acheminement du courrier.
    L'idée est donc de "forwarder" tous ses mails sur une seule machine (dite cul de sac), de les dupliquer dès leur arrivée dans un serveur de duplication. Celui-ci permettra ensuite de demander un rapatriement sur un autre site d'une partie du courrier stocké.
    Le serveur tournera sur la machine cul de sac. On effectuera la copie en ajoutant au .forward la copie du courrier recu dans un fichier du serveur en en communicant avec lui. Le serveur connaøtra par ailleurs les noms des autres sites pouvant rappatrier le courrier en tenant compte de l'avancement de chacun.
    Le client principal sera get_mail [-l -t time] permettant de transférer sur une machine distante les nouveaux courriers en lui indiquant l'emplacement où les ranger, au lecteur de mail habituel de traiter cette nouvelle boite. L'option -l donne uniquement la liste des nouveaux messages, l'option -t time indique un transfert tous les time.

1.2   Clients de services existants

  1. Vérificateur d'URL
    On utilisera le protocole HTTP pour écrire un client "vérificateur d'URL". Le but étant de vérifier l'existence des différents liens locaux et distants d'un site.
    Le client prend en entrée l'URL d'une page d'un site, détermine les différentes URL de cette page, et répète ce processus en lançant 1 thread sur chaque nouvelle adresse. Si le lien est distant, il y a juste vérification de l'existence de l'URL distante.
    On trouvera une traduction du protocole HTTP à la page :
    http://www.eisti.fr/eistiweb/docs/normes/rfc1945/1945tm.htm
    Vous pouvez contacter Bastien Moinet du DESS GLA qui a réalisé l'an passé un projet d'aspirateur de sites Web, pour récupérer et améliorer son analyseur syntaxique du langage HTML.
  2. Mirroir de sites ftp
    On écrit un client ftp pour faire un mirroir d'un site ftp. Le protocole ftp est décrit à la page :
    http://www.eisti.fr/eistiweb/docs/normes/rfc959/959tm.htm

    Le client est paramétré par la hiérarchie du site à récupérer. Ses options sont :
    Le client vérifie si le fichier à transférer existe déjà. Si c'est le cas, il doit tester s'ils sont identiques (taille, droit et date de création) avant de le transférer.

1.3   Servlets

Un servlet est un ``module'' à intégrer dans une application serveur pour répondre aux requêtes des clients. Bien qu'un servlet ne soit pas spécifique à un protocole, on utilisera le protocole HTTP pour la communication. Dans la pratique le terme servlet correspond à un servlet HTTP.

Le moyen classique de construire des pages HTML dynamiques sur un serveur HTTP est d'utiliser les CGI (Common Gateway Interface) qui lance un programme, auquel on passe l'URL pouvant contenir des arguments provenant des formulaires, sur le serveur. L'exécution produit alors une page HTML qui est envoyée au client. On trouvera aux liens suivants la description du protocole HTTP et des CGI.
http://www.eisti.fr/eistiweb/docs/normes/rfc1945/1945tm.htm
http://hoohoo.ncsa.uiuc.edu/docs/cgi/overview.html
C'est un mécanisme un peu lourd car il lance à chaque requête un nouveau programme.

Les servlets HTTP sont lancées une fois pour toute, et peuvent tout aussi bien décoder les arguments du format CGI pour exécuter une requête. Les servlets permettent aussi de construire l'interface graphique d'une application.

Deux projets sont proposés sur ce thème.

  1. Servlet de base
    Écrire le mécanisme de base de décodage des requêtes (URL + arguments à la CGI) et construction de la page HTML correspondante. Vous devez pouvoir répondre
    Les liens suivants peuvent être utiles à la réalisation de ce projet :
    http://caml.inria.fr/hump.html
    http://www-spi.lip6.fr/ emmanuel/Public/enseignement/JOcaml/index.html
    Vous pouvez fournir cette bibliothèque par un foncteur dont le module paramètre contient la fonction de traitement des arguments (passés sous forme d'un tableau de chaînes) ou par une hiérarchie de classes. Vous testerez votre bibliothèque sur d'une part un mini-serveur Web et d'autre part

  2. Hiérarchie Objet pour la construction de l'interface.
    Les formulaires HTML permettent de décrire une interface à une application. Le but de ce projet est de faciliter la vie du programmeur en lui fournissant une hiérarchie de classes pour la construction de son interface. Les éléments de base sont les champs de saisie, les boutons à cliquer, les zones à éditer, et les images cliquable, ..., ainsi que des structures plus complexes comme les tabelaux d'éléments.

    Seuls boutons et les images à cliquer déclenchent l'envoi d'une requête vers le serveur avec tous les paramètres du formulaire. Pour tenir compte de l'environnement, il peut être utile de pouvoir masquer des champs qui contiennent une information précédente.

    Il peut être utile de tester votre application avec le projet précédent.

1.4   Services de bureautique

  1. PostIt de groupe
    Le but de ce service est de pouvoir avoir un rappel (sous forme d'une fenêtre) d'un événement proche dans le temps (soit en début de journée, soit peu de temps avant cet événement). Un serveur contient une liste de clients autorisés (machine - login) et la liste des PostIt à délivrer. Un client s'enregistre auprès du serveur. Le client ensuite autorise le serveur à lui envoyer des fenêtres de rappel. Les fonctionnalités du client sont :
  2. Planning de salles
    Le but de ce service est de pouvoir gérer en groupe un ensemble de salles, comme par exemple els salles machines de l'UFR. Un serveur contient la liste des salles à gérer et les réservations déjà effectuées. Une réservation comprend l'identificateur de la salle, le demandeur et le créneau horaire.

1.5   Calcul distribué

  1. Jeu de la vie
    On cherche à réaliser le jeu de la vie de manière distribuée. Le serveur correspond au monde et maintient sa cohérence selon le nombre de clients (en fait selon la puissance de calcul disponible) connectés. Le serveur prépare une queue de travail pour les différents clients (il est judicieux de préparer plus de taches que de clients permettant ainsi plusieurs calculs par client et de tenir compte des connexions/déconnexions des clients).
    Chaque client, en fait un programme prêt à calculer, demande une partie du travail à effectuer, calcule la nouvelle génération de sa partie et renvoie le résultat au serveur.
    Quand tout est fait, le serveur l'indique, et peut ensuite passer a une nouvelle génération. Il peut être utile si un client est trop long de proposer sa tache aux autres clients.
  2. Queue de travail réseau
    Le but de ce projet est de fournir la mécanique de base pour un calcul réalisé par plusieurs machines. Un serveur construit une queue de travail. Un client qui se connecte à ce serveur lui indique qu'il est prêt à effectuer une partie du travail et récupère une des taches à effectuer. Une fois le calcul fini sur le client, il renvoie le résultat au serveur et peut prendre une autre tache.

    Pour simplifier la communication clients/serveurs, les taches sont représentées par des fermetures. Elles sont envoyées du serveur vers le client en sérialisant (voir le modufle Marshal) la fermeture. Pour que cela puisse se réaliser, il est nécessaire que le client possède cette fermeture, en particulier le pointeur de code. La seule manière possible de la faire en O'Caml est que le programme client soit le même que le programme serveur. Ainsi le code de la fermeture sera à la bonne adresse. On discrimenera le serveur du client sur le nom de la commande :
    serveur.exe port&
    client.exe machine port&
    
    serveur.exe et client.exe sont les mêmes exécutables/

    Voici un exemple d'utilisation du module Marshall :
    module type ST =
      sig type t val to_string : t -> string val from_string : string -> t end
    ;;
    
    module G = 
      struct 
         type t = {x:float; y:float}
         let to_string (x:t) = Marshal.to_string x [Marshal.Closures] 
         let from_string s =  ((Marshal.from_string  s 0) : t)
      end;;
    
    module F (P:ST) = struct
      module L = P
    end;;
    
    module H = F (G);;
    # let u = {G.x = 3.14; G.y = 88.9};;
    val u : G.t = {G.x=3.14; G.y=88.9}
    # let s =  H.L.to_string u;;
    val s : string =
      "\132\149\166\190\000\000\000\018\000\000\000\001\000\000\... "
    # let v = H.L.from_string s;;
    val v : H.L.t = {G.x=3.14; G.y=88.9}
    
    
    Il est demandé d'écrire :

1.6   Coopération et Concurrence : Robots dans la cour de récréation

Cette sous-section comprend différents sujets de simulation d'une cour de récréation où les robots jouent à un des jeux classiques suivants. Ces projets comportent une partie affichage graphique sur les clients, les serveurs jouant le rôle d'arbitre. Une extension possible est d'introduire un client humain qui contrôle au moins un joueur et peut changer de joueurs pour les jeux d'équipe. Si vous implantez cette extension vous pouvez passer de 2 à 3 pour l'équipe de développement, en séparant bien les parties réalisées par chacun.

  1. Renards, Poules, Vipères
    La zone de jeu comprend 3 bases, une par équipe. Chaque équipe doit attraper les joueurs d'une autre équipe et peut se faire attraper par la dernière équipe. Un renard chassera une poule, qui chasse une vipère qui attrape un renard. Chaque équipe comprend plusieurs joueurs. Le jeu s'arrête dès qu'une équipe n'a plus de joueur. Le gagnant étant l'équipe restante possédant le plus grand nombre de joueurs actifs.
    Un joueur attrapé doit rejoindre par ses propres moyens la base de l'équipe qui l'a attrapé. Il restera en contact avec cette base ou en contact avec un autre joueur déjà attrapé formant ainsi une chaîne. Cette chaîne peut être libérée par un joueur de sa propre équipe au contact.
  2. l'Épervier
    La zone de jeu comprend est un rectangle où règne un épervier. À un signal donné, les joueurs partent d'un bord et doivent rejoindre le bord opposé sans se faire prendre par l'épervier. Ceux qui sont pris, deviennent éperviers ce qui augmente au fur et à mesure de la partie leur nombre. La partie s'arrête quand tous les joueurs sont pris. Le dernier attrapé devient épervier pour la partie suivante.
  3. Balle au priso
    La zone de jeu est découpée en 2 parties. Chaque partie comprend la zone où évolue l'équipe et à l'arrière une zone de prisonniers. Le jeu démarre avec la balle dans un camps. Le but est d'atteindre les joueurs de l'autre équipe avec la balle, sans qui l'attrape. Pour cela chaque robot regarde dans toutes les directions. Un robot rattrape une balle s'il regarde dans la direction d'où vient la balle, à + ou - 10 degrés, et est touché dans les autres cas. Si un joueur attrape la balle il a 3 secondes pour la relancer. Si un joueur est touché, il s'en va rejoindre les prisonniers de son équipe, le ballon est alors relancé par son équipe. Si la balle atteind l'enclos des prisonniers, ceux-ci peuvent renvoyer la balle sur l'équipe adverse avec les mêmes règles. Si un prisonnier touche un adversaire, alors il est libéré et rejoint son camp.
    Différents lancers de balle peuvent être programmés : lob, tir, ...et différents robots aussi selon des caractéristiques de vitesse de déplacement, force de tir, ....
  4. Robots footballeurs
    En reprenant la bibliothèque déjà écrite en projet d'année de maîtrise qui permet de communiquer avec un le serveur de RobotCup
    http://ci.etl.go.jp/ noda/research/kyocho/soccer/server/index.html, écrire une stratégie pour une nouvelle équipe et tester la avec l'ancienne.

    On pourra donc comparer son équipe avec l'équipe déjà écrite. Pour obtenir l'équipe précédente, vous pouvez contacter Frabrice Bouchaud au DESS GLA.

1.7   Serveurs de jeux d'action rapide

  1. Ver de terre en réseau
    Le but du jeu est de faire grandir un ver de terre le plus longtemps possible. Celui-ci grandit avec le temps sauf s'il touche une case contenant soit un obstacle, soit une partie de lui même. L'intérêt de l'adapter en réseau est donc d'avoir plusieurs vers de terre, dirigé chacun par un client différent, qui interagissent. Quand eux vers de terre se rencontrent les deux disparraissent. On effectuera l'affichage graphique sur chaque client.
  2. Course de voitures
    On reprend le thème de la course de voitures sur des feuilles petits carreaux. Les voitures sont placées sur la ligne de départ (il peut avoir plusieurs lignes si le nombre de voitures est important). Chaque voiture à un instant donné peut augmenter ou réduire sa vitesse d'un carreau et/ou réduire ou augmenter son angle d'un carreau. Une voiture connaît tout le circuit et peut en partie construire une stratégie par rapport aux autres voitures.

    C'est une application client/serveur où le serveur accepte les inscriptions pour le départ, indique le départ de la course et valide les mouvements des voitures. Les clients donnent leurs intentions de mouvement, les envoient au serveur qui soit accepte le mouvement qui est alors répercuté aux autres clients, soit le refuse car il y a un accident. Un accident handicape pendant un léger temps la ou les voitures fautives.

    Là aussi un client joueur humain est une extension intéressante qui sera alors réalisée en trinôme.

Index Suivant