L'environnement du SHELL devient distribué et conservé sur un serveur. Différents clients implantent les fonctionnalités suivantes :
rget_var NOM : demande la valeur d'un symbole distant
rput_var NOM VAL : affecte à distance un symbole
rprint_env : donne l'environnement distant complet
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.
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.
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.
C'est le même principe que le programme précédent, mais à la place
de tester un lien, les différents fichiers de la hiérarchie sont transférés. Une fois ces fichiers récupérés, il est nécessaire de faire
une modification des liens pour qu'ils soient locaux. On utilisera la bibliothèque regexpr de O'Caml pour déterminer les ancres et les images.
mySQL est un serveur SQL du domaine public. Le but de ce projet est d'implanter un client O'Caml de requêtes SQL. Pour cela, le client établira une connexion avec un serveur mySQL et autorisera les différentes commandes SQL :
Il sera implanté sous forme de bibliothèque. Pour pouvoir généralisée cette connexion au serveur mySQL à d'autres serveurs SQL, on décrira une classe abstraite dont les sous-classes concrètes correspondront aux "pilotes" du serveur SQL. On pourra s'inspirer (fortement) de la bibliothèque JDBC de Java.
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 :
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.
En reprenant le module mini-max alpha-beta,
dont les sources sont sur la machine de 2eme cycle
et une application déjà réalisée sur un jeu (puissance 4,
othello, dames,
Stobe Henge, Nuba, Yucatan) au DESS GLA, on demande d'écrire un serveur
de jeux qui peut répondre à différentes requêtes en même temps (threads ou
forks).
Le client émet une requête (état du jeu + demande de prochain coup
pour un camp ou vérification si un coup est legal). Il attend la réponse.
On peut ainsi faire jouer un humain contre une machine, un humain contre
un autre (le serveur est seulement l'arbitre) et deux programmes l'un contre
l'autre.
On peut utiliser le temps entre 2 coups pour pré-calculer le prochain
coup d'un joueur qui sera identifié par sa machine.
Le serveur peut répondre à une
commande CGI (Common Gateway Interface). L'intérêt de l'architecture
serveur est de ne pas (trop) surcharger la machine si de nombreuses requêtes
sont
lancées.
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.
On cherche à effectuer une recherche de chemin entre deux points d'un graphe. On appliquera ce projet à la grille du campus Jussieu. Le serveur tient à jour une liste de positions. Les clients demandent au serveur si leur exploration n'est pas déjà effectué. Dès qu'un client atteint l'objectif (la sortie), il l'indique au serveur qui selon les cas peut arrêter les calculs en cours, ou attendre que tous aient fini pour déterminer le chemin de moindre coût.
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.
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.
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.
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, ....
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, écrire une stratégie pour une nouvelle équipe et tester la avec l'ancienne.
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.
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.