version du 26/12

Evaluation du module PC2R - année 2006/2007

Pour tenir compte des remarques sur la charge de travail des étudiants de maîtrise, l'évaluation du module POD de cette année se décompose de la manière suivante :
Pour être dispensé de contrôle continu, il faut le demander au secrétariat du master STL.

Liste des projets du cours PC2R - année 2006/2007

Ces projets sont l'application directe des notions vues en cours de PC2R. Ils demandent d'implanter des applications/applets graphiques et réseau clients/serveurs via des sockets ou en RMI. Les langages d'implantation sont Objective Caml et Java.

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 2 groupes sur un même projet.

Présentation des projets : lundi 27 novembre 2006
Mise en ligne : mercredi 27 novembre 2006

Pour s'inscrire, envoyez un courrier à votre chargé de TD en cliquant ici et en indiquant dans le corps du message le projet choisi ainsi que les noms et logins des étudiants le réalisant.
Vous pouvez proposer un projet mais il doit être validé par le responsable du module.

Services et Outils Système

  1. Mini secure shell :
    On utilise une architecture client-serveur pour faire une connexion sécurisée à distance. La connexion se fera en 3 phases :
    1. échange de clés publiques via l'algorithme de Diffie-Hellman
    2. Une fois les clés publiques échangées, le serveur engendre deux clés secrètes triple-DES (ici aussi un petit polycopié sera distribué) et les envoie au client.
    3. Le client ayant recu la clé secrète, celui-ci peut envoyer ses instructions (comme le ferait rsh ou ssh) au serveur (en les cryptant avec la clé secrète). Ce dernier exécute les instructions en question et renvoie au client les messages écrits sur les sorties standard et erreur. Le client affiche alors ces messages. Le serveur est à écrire en O'Caml.

    Nombre de projets : 2 ou bien 1

Clients et serveurs de services existants

  1. serveur et client Ftp :
    Le protocole FTP (File Transfert Protocol) est décrit dans la RFC (Request For Comments) 959. Il est demandé d'écrire un serveur et un client pour ce protocole. Vous pouvez vous inspirez du serveur décrit au chapitre 8 de l'ouvrage Java et Internet. Le serveur est à écrire en O'Caml.
    Nombre de projets : 2 ou bien 1

Services de bureautique répartis

  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 :
    Nombre de projets : 2

  2. Planning de salles
    Le but de ce projet est de créer et maintenir un planning de salles commun à différents utilisateurs. Certains utilisateurs peuvent avoir de plus grande priorité par rapport à d'autres. On ne cherche pas à résoudre les différentes contraintes. On ne peut ajouter, ou enlever, des informations que si l'on est propriétaire de celles-ci ou si on a une priorité le permettant. Comme les différents utilisateurs peuvent être sur différentes machines, ils seront considérés comme client d'un serveur planning. Un client pourra demander les informations d'une salle sur une année, ou l'ensemble des salles sur une semaine.

    Nombre de projets : 2

  3. Une mini messagerie
    Réalisation d'une architecture client-serveur pour un petit service de messagerie.

    Le serveur doit tenir à jour une liste d'abonnés au service et, pour chacun d'eux la liste des messages qui leur sont destinés. Les clients peuvent abonner un nouvel utilisateur, consulter et maintenir (i.e. faire le ménage dans) la liste de ses messages et envoyer un message vers un ou plusieurs autres abonnés.

    Les transactions entre un client et le serveur concernent toujours un seul abonné (i.e. un client n'a accès qu'a ses propres messages).

    Nombre de projets : 2
  4. Dessin en groupe
    R?alisation d'une architecture client-serveur pour un petit logiciel de dessin
    Nombre de projet : 1

Serveurs de jeux

Les projets de cette section mettent en oeuvre des serveurs de jeux pour pouvoir jouer avec des correspondants distants. Une fois les joueurs connectés, le jeu peut démarrer.
  1. Jeu de dominos :
    À la connexion, les joueurs s'inscrivent (par nom) et recoivent 7 dominos (un domino (x,y) code par 10*x +y, (y,x) =10*y + x; x et y de 1 a 7=blanc). La grille est nxn n>=20 ; pour indiquer un positionnement du coup, le joueur indique 2 cases adjacentes (dont l'une est adjacente au jeu déjà pose). il peut "passer" ou "piocher (le serveur lui renvoie un domino non encore attribué). Les clients reçoivent le nom du prochain joueur, le coup précédent (domino posé et sa position ou passe). Le client peut donc mettre à jour sa copie de la grille de jeu. Une requête incorrecte est renvoyée à son émetteur. Seule une requête du "prochain joueur" peut être prise en compte. Le jeu se termine lorsqu'un joueur a épuisé tous ses dominos. L'affichage graphique de la grille de jeu est un plus (mais peut-etre un tableau d'entiers). Le serveur limite ses connexions à 5.

    Nombre de projets : 2

  2. BlackJack

    Nombre de projets : 2

  3. Jeu de cartes (Poker) Même sujet pour le jeu de BlackJack, avec la possibilité de faire jouer la machine.

    Nombre de projets : 2
  4. Ping-Pong / Billard Nicolas Implantation d'un ping/pong (ou billard Nicolas) à n joueurs.

    Nombre de projets : 2
  5. Dessiner c'est gagné
    Pour n joueurs.
    Nombre de projet : 2
  6. Questions pour un champion HAJY - MHOMA


  7. Bataille navale
    pour 2 à n joueurs

    les coups d'un joueur sont repercutes à l'ensemble des autres joueurs.

Calcul distribué

  1. 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 :
    Nombre de projets : 1 en Objective Caml Bruce Ricard

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.
    Nombre de projets : 3

  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.
    Nombre de projets : 3

  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, ....

    Nombre de projets : 3

  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 une équipe déjà écrite.

    Nombre de projets : 2

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 deux vers de terre se rencontrent les deux disparraissent. Il y a deux types de clients : les vers de terre programmes et les vers de terre humains. On effectuera l'affichage graphique sur chaque client humain.

    Nombre de projets : 2

  2. Tron (variante de VdT proposé par Julien FALCONNET)
    Ce jeu est une variante du ver de terre, inspiré du film Tron (1982, Steven Lisberger ). Le but du est de rester le plus longtemps possible dans l'arene. Chaque joueur se déplace constamment et ne peut décider que de la direction. Il laisse sur son passage une trace durable partout ou il passe. Un joueur qui rencontre les bords de l'arene ou une trace (la sienne ou celle d'un autre joueur) a perdu. Le vainqueur est le dernier en jeu. En réseau, chaque joueur est dirigé par un client différent et interagit avec les autres par le serveur.

    Nombre de projets :1
  3. 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 il y a 2 types de clients : le client joueur humain et le client dirigé par un programme.

    Nombre de projets : 3

  4. Quixx
    Quixx est un jeu où un petit bonhomme se ballade sur le périmètre d'un grand rectangle. Il peut suivre des lignes déjà tracées ou en tracer d'autres. Quand il crée une surface (une zone qu'il ferme) il peut alors choisir d'aller dans la direction qu'il désire (toujours en suivant des lignes). Les points correspondent à la somme des surfaces d'un joueur. Le bonhomme, comme dans beaucoup de jeux, a 2 poursuivants. Il ne doit pas les rencontrer. Donc la partie s'arrête quand toute ls surface du rectangle initial est couverte, soit quand le bonhomme rencontre un poursuivant.
    Ce jeu est à adapter en client-serveur. Deux options sont possibles :
    Si vous implantez les 2 options votre binôme peut se transformer en trinôme.

    Nombre de projets : 2

Rendu de projet

Vous rendrez le projet soit le jour de l'examen (18/12/2006) soit par courrier électronique au plus tard le jeudi 21/12/2006 à midi à votre chargé de TD :

un rapport contenant une brève description générale du problème, une description de la hiérarchie de classes ou des modules utilisés, 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.

Outils pour le développement des projets

Travail en groupe avec CVS

Pour le travail en groupe (à partir de 2) et à distance, il est conseillé d'utiliser CVS pour la gestion des sources. CVS est installé sur les machines du centre de calcul enseignements.

Vous trouverez aux liens suivants des informations s'y rapportant :

site tres complet sur CVS

une intro

C'est vraiment une bonne méthode si vous travaillez en binôme à distance (un à la montagne, un autre au quartier latin). Chacun travaille sur sa copie locale et met à jour l'archive commune quand cela est nécessaire.
Ce document a été traduit de LATEX par HEVEA