version du 30/11 soir
(anciennes mises à jour : 25/11/08 apres-midi, 22/11/08 soir, 21/11/08 soir, 19/11/08 matin)
Evaluation du module PC2R - année 2008/2009
Pour tenir compte des remarques sur la charge de travail des étudiants
de maîtrise, l'évaluation du module PC2R de cette année se décompose de la manière suivante :
-
Contrôle continu : 40% de la note finale
-
Epreuve écrite : 20% de la note finale
- Réalisation d'un projet : 20% de la note finale
- Examen final : 60% de la note finale
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 2008/2009
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, sauf variation
des langages d'implantation.
Présentation des projets : lundi 17 novembre 2008
Mise en ligne : lundi 17 novembre 2008
Pour s'inscrire, envoyez un courrier au responsable du module
en cliquant ici et en indiquant dans le corps du message le projet choisi (ou une liste de projets qui vous intéressent) 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.
nombre d'inscrits
au 19/11/2008 : 20
au 21/11/2008 : + 21
au 22/11/2008 : + 3
au 25/11/2008 : + 12
au 30/11/2008 : + 2
Clients et serveurs de services existants
-
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
-
2 projets en binôme (un avec un client O'Caml et un autre avec un client Java) : Cai, Ramine + 2 et Ortole + 1
- ou bien 1 projet en trinôme (1 serveur O'Caml - 1 client O'Caml - 1 client Java). : Bazzi - Savanni - Zouaoui
Services de bureautique répartis
-
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 :
-
enregistrer un PostIt pour lui-même, pour un autre utilisateur ou pour un plusieurs utilisateurs;
- effacer un PostIt qui a lui-même envoyé
- indiquer qu'il a effectué la lecture d'un PostIt;
- demander un rappel complet des PostIt le concernant.
Nombre de projets : 2
-
serveur en O'Caml et client en Java Milojevic, Mkhitaryan
- tout en Java avec RMI : Ould Amrouch, Kerkar + 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
-
serveur en O'Caml et client en Java
- tout en Java avec RMI : Zhan, ZengHao
- 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
-
serveur en O'Caml et client en Java : Luu + 1 - Lokman + 1
- tout en Java avec RMI : Alim, Zucarelli + 2 - Belkacemi + 1
- Dessin en groupe
Réalisation d'une architecture client-serveur pour un petit logiciel coopératif de dessins avec sauvegarde
Nombre de projets : 1
-
serveur en O'Caml et client en Java :
Serveurs de jeux de réflexion
-
Isketch : jeu de dessin multi-joueurs (
site iSketch)
Nombre de projets : 3
-
serveur en O'Caml et client en Java : Beaupuy-Mouret, Puig
- serveur en Java et client en O'Caml :
- tout en Java RMI :
- Implantation d'un billard Nicolas à 4 joueurs (
site wikipedia).
Nombre de projets : 3
-
serveur en O'Caml, client en Java
- serveur en Java, client en O'Caml
- tout en Java-RMI :
- 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 :
-
un serveur O'Caml et un client Java : underlineBiscaras, France + 2
- serveur/client en Java-RMI : Alaeitabar, Seladji + 2
- jeu de cartes Blacjack (voir site wikipediahttp://fr.wikipedia.org/wiki/Blackjack
Pour 1 à n joueurs
Nombre de projets 2 :
-
un serveur O'Caml et un client Java :
- client/serveur en Java RMI : Geraud, Sebaratnam
- même sujet que le BlackJack pour le Poker (voir site wikipediahttp://fr.wikipedia.org/wiki/Poker
Pour 1 à n joueurs
Nombre de projets 2 :
-
un serveur O'Caml et un client Java : Huot, Sabadady + 2
- un serveur Java et un client C : Joseph, Lesaux
- client/serveur en Java RMI : Camier, Pillon + 2
- même sujet que le BlackJack pour le Uno (voir site wikipediahttp://fr.wikipedia.org/wiki/Uno
Pour 1 à n joueurs
Nombre de projets 2 :
-
un serveur O'Caml et un client Java : Tran + 1
- client/serveur en Java RMI : Bittan, Collet
- jeu d'échec
-
- un joueur arrivant sur le serveur peut créer une ou plusieurs nouvelles parties
- - un joueur peut rejoindre une ou plusieurs parties de joueurs en attente
- - un client tiers peut assister à une partie déjà lancée entre deux joueurs
- - A chaque fenêtre d'une partie est ratachée une sous-fenêtre de dialogue (tchat) permettant aux personnes connectées de communiquer.
Nombre de projets 2 :
-
un serveur O'Caml et un client Java : Ye, Zhu
- client/serveur en Java RMI : Bhavsar, Huynh
Serveurs de jeux de stratégie et de simulation
Cette sous-section comprend différents réalisation autour des jeux de
stratégie. Un jeu de stratégie en ligne permet à plusieurs (dizaines,
centaines, milliers) de joueurs de s'affronter dans un monde
particulier. Par exemple le jeu Travian crée un univers antique
mellant romains, gaulois et teutons; le jeu Ogame a un univers
de science-fiction. En règle générale il y a une gestion des
ressources qui permettent d'apporter des évolutions du point de vue
économique, militaire ou autre.
- à la manière de Travian ou Ogame, gérer la production locale, l'envoi
d'éléments sur d'autres destinations, la résolution des conflits sans gestion d'alliances. Pour chaque variante (Ogame ou Travian) :
Nombre de projets 4 :
-
un serveur O'Caml et un client Java : Ghoora, Giouicem + 2
- client/serveur en Java RMI : Diouf, Reynaud + 2 et Hao + 1
- serveur Web :
- serveur JSP :
Calcul distribué
- 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&
où 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 :
-
Les différents modules paramétrés pour la gestion de la communicatin et
de la queue de travail.
- Une petite application calcul numérique. On part d'une liste
importante de matrices caréées, et on profite de l'associativité du produit
pour effectuer le produit 2 à 2. Pour une liste de 100 matrices,
Nombre de projets : 1 en Objective Caml
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.
-
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
-
tout en O'Caml
- serveur en O'Caml et client en Java
- tout en java avec RMI :
- 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
-
tout en O'Caml : Bodin + 1
- serveur en O'Caml et client en Java
- tout en java avec RMI (plusieurs stratégies de joueurs) : Gaudel, Petit, Vassord + 3
- 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
-
tout en O'Caml
- serveur en O'Caml et client en Java
- tout en java avec RMI : Bensmaine, Bouzidi + 2
jeux d'action rapide
- Tank Attack
Implantation du jeu Tank attack :
des petits tank (caracteres ascii) evoluent au sein d'une aire de jeu
de taille variable comprise en 80x80 et 240x240 des obstacles
apparaissent aleatoirement sur l'aire de jeu.
Chaque tank peu tirer pour degager son chemin.
L'objectif est de rester le dernier tank.
Nombre de projets : 2
-
Implantation d'un client serveur dans deux langages differents :
- serveur/client en Java-RMI :
- Tron
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 : 3
-
serveur en O'CAML et client en Java : Coupe (recherche complement binome) :
- serveur en Java et client en O'CAML : Makhlouf, Toklu + 2
- serveur/client en Java-RMI : Stavrev, Todorova ou tank Attack + 0 - Zahreddine + 1
- 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
-
serveur en O'CAML et client en Java : Jabeur + 1
- serveur en Java et client en O'CAML :
- serveur/client en Java-RMI :
Un jeu d'action rapide complètement spécifié
proposé par Philippe Wang
Ce projet proposé par Philippe Wang consiste à implanter un jeu vidéo de << tir au pistolet >>.
Il se divise en deux parties principales : le client
graphique et le serveur de jeu.
-
le client graphique s'occupe de l'interface
homme-machine,
- le serveur de jeu s'occupe des scores et << guide >> le
client (donc fait << tous les calculs >>).
Client graphique
Le client est composé de deux éléments clefs :
-
l'afficheur : un interprète de langage graphique
- le gestionnaire d'événements (i.e. celui qui repère les clics)
Interprète de langage graphique (Afficheur)
On se donne un mini langage comportant des instructions d'affichage
graphique. Une instruction standard tient sur un octet. (Une
instruction spéciale tient sur un nombre arbitraire d'octets.)
La figure 1 donne les spécifications du langage,
et la figure 2 donne un exemple de code.
(Les spécifications doivent être respectées mais peuvent être étendues.)
Instructions
| code |
nom |
arité (taille en octets) |
arguments |
action |
| 00 |
Color |
1 (4) |
couleur RGBA |
change la couleur courante |
| 01 |
MoveTo |
2 (2×2) |
A, O |
change le point courant |
| 02 |
Dot |
0 (0) |
– |
dessine un point au point courant |
| 03 |
LineTo |
2 (2×2) |
A, O |
dessine une ligne jusqu'au point donné |
| 04 |
Rect |
4 (4×2) |
A, O, L, H |
dessine un rectangle |
| 05 |
FRect |
4 (4×2) |
A, O, L, H |
dessine un rectangle plein |
| 06 |
Square |
3 (3×2) |
A, O, C |
dessine un carré |
| 07 |
FSquare |
3 (3×2) |
A, O, C |
dessine un carré plein |
| 08 |
Ellipse |
4 (4×2) |
A, O, RA, RO |
dessine une ellipse |
| 09 |
FEllipse |
4 (4×2) |
A, O, RA, RO |
dessine une ellipse pleine |
| 0A |
Circle |
3 (3×2) |
A, O, R |
dessine un cercle |
| 0B |
FCircle |
3 (3×2) |
A, O, R |
dessine un disque |
| 0C |
Poly |
1+n (1+2×n×2) |
T, n × (A, O) |
dessine un polygone |
| 0D |
FPoly |
1+n (1+2×n×2) |
T, n × (A, O) |
dessine un polygone plein |
| 0E |
Rec |
0 (0) |
– |
enregistre une macro |
| 0F |
Store |
2 (1+n) |
T, N |
stoppe et nomme la macro courante |
| 10 |
Load |
2 (1+n) |
T, N |
charge une macro |
| 11 |
LineWidth |
1 (1) |
L |
change la largeur des lignes |
| 12 |
Clear |
0 |
– |
efface la zone de dessin |
| 13 |
Dummy |
0 |
– |
ne fait rien |
|
Légende
| A |
abscisse (horizontal) |
| O |
ordonnée (vertical) |
| RGBA |
red, green, blue, alpha : 4×8=32 bits |
| L |
largeur |
| H |
hauteur |
| C |
(longueur du) côté |
| R |
rayon |
| T |
taille - 1 (en nombre d'octets) |
| N |
nom (limité à 256 caractères) |
| RA |
radius abscisse |
| RO |
radius ordonnée |
| macro |
séquence d'instructions |
|
Remarques
-
Les nombres sont des entiers non signés (positifs).
- L'unité de mesure graphique est le pixel.
- Les nombres sont en représentation décimale, sauf pour la
colonne code où ils sont en hexadécimal.
- L'arité est le nombre d'arguments.
- Le canal alpha (composante pour la transparence des couleurs)
est ignoré sauf pour ceux qui veulent aller plus loin.
- La taille par défaut pour la fenêtre est 800×600.
- Le point de coordonnées (0, 0) est en bas à gauche.
|
Figure 1: Instructions de l'afficheur graphique
Le code
|
en représentation assembleur :
Color(00000000);
FSquare(0000,0000,01FF);
Color(FF000000);
MoveTo(0000,0000);
LineTo(01FF,01FF);
MoveTo(0000,01FF);
LineTo(01FF,0000);
|
ou |
en représentation hexadécimale :
0000000000070000000001FF00
FF00000001000000000301FF01
FF01000001FF0301FF0000
|
dessine un carré noir plein de côté 511 pixels avec ses diagonales en rouge.
Figure 2: Exemple de code
Guetteur d'événements
La fenêtre graphique une fois dessinée doit guetter les événements
du joueur : clic avec la souris ou frappes sur le clavier.
En cas de clic avec la souris ou de frappe sur le clavier, il faut
envoyer les coordonnées du point cliqué au serveur.
L'attente d'événements avec Graphics peut être implantée, par
exemple, à l'aide de
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Graphics.html#6_Mouseandkeyboardevents.
Instructions
| code |
nom |
arité (taille en octets) |
arguments |
action |
| 00 |
Mouse |
2 (2×2) |
A, O |
Transmet un clic |
| 01 |
Keyb |
2 (1+n) |
T, K |
Transmet un caractère |
Légende
| A |
abscisse (horizontal) |
| O |
ordonnée (vertical) |
| T |
taille du caractère |
| K |
caractère entré au clavier |
|
Remarques
-
La taille des caractères dépend de l'encodage utilisé. Par
exemple, en UTF-8, la taille est variable (un ou plusieurs
octets) ; en iso-8859-1 ou en ascii, elle est fixée à 8 bits (1
octet).
|
Figure 3: Transmission des événements
Noyau : le serveur de jeu
L'implantation du noyau consiste à implanter un gestionnaire de scores
ainsi que le générateur de graphiques.
Lorsqu'un client est connecté au serveur, le serveur doit être capable
de connaître le score du client jusqu'à son départ. Comme le client se
contente d'afficher naïvement tout ce que demande le serveur, c'est au
serveur de se charger des calculs de dessins.
(Génération ou Gestion des) Cibles
Il faut maintenant s'occuper des cibles. Une cible doit ressembler à
une cible (i.e. ne pas être invisible). C'est au serveur de dire au
client (par voie d'affichage) si une cible a été touchée ou non.
Remarques :
La complexité minimale de la forme des cibles est un
rectangle.
Il sera préférable
que la forme des cibles soit au moins circulaire. Cependant il vaut
mieux avoir un jeu qui fonctionne avec des cibles simples qu'avoir un
programme qui ne fonctionne pas du tout.
Il faut au moins une dizaine de niveaux de difficulté différents. Le
niveau peut varier en fonction de nombreux critères, dont la taille
des cibles, leurs durées d'apparition, leurs formes, la taille des
projectiles, la taille de leurs impacts, etc.
Gestionnaire de scores
Les règles du jeu (i.e. comment les points sont attribués) devront
être décrites en détail dans le rapport. Une brève description de
l'implantation devra les accompagner.
Système de tirs et Périphérique de saisie
C'est ici que se joue l'interprétation des événements envoyés par le
client au serveur.
On considère que l'interface entre l'utilisateur et la machine
comprend une souris qu'on peut utiliser comme périphérique de contrôle
du jeu.
Cependant, pour ceux qui préfèrent le clavier à la souris, il est
possible d'implanter un système de tirs au clavier,
voire d'implanter les deux...
Tirs rectilignes
Une simplification des trajectoires des tirs consiste à les considérer
rectilignes et même (quasi) instantanés.
Dans ce cas, il n'y a pas de difficulté à calculer le point d'impact.
Tirs (pseudo-)paraboliques
Un système de tir plus réaliste (et plus compliqué) consiste à prendre
en compte la gravité, la vitesse du projectile, etc.
Communications (entre le client et le serveur)
Le client reçoit les ordres du serveur dans le langage présenté
plus haut. Le serveur reçoit les événements perçus par le client dans
le second langage présenté plus haut.
Nombre de projets : 4
-
serveur en O'Caml et client en Java :
- serveur en O'Caml et client en O'Caml :
- serveur en Java et client en O'Caml :
- serveur en Java et client en Java :
Rendu de projet
Vous rendrez le projet soit le jour de l'examen (décembre 2008) soit par
courrier électronique au plus tard le jeudi 18/12/2008 à 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 wikipedia sur CVS
une intro
Ce document a été traduit de LATEX par HEVEA