Projet de programmation réseau avec Java
POL
Play On Line
Ce sujet peut être enrichi ou complété. Il est accessible à
l'adresse http://igm.univ-mlv.fr/~duris/TTT/pol.html
.
Le but du projet
Le but de ce projet est de fournir un couple de programmes, un client
et un serveur, permettant de simuler des « jeux en
lignes » très simples. L'idée est basée sur le
principe de questions basiques, posées aux clients, auxquelles
ceux-ci doivent répondre pour essayer de gagner. Voici les principes de
base de ce jeu :
- un serveur POL doit être installé quelquepart, et ses coordonnées
connues de tous les clients potentiels ;
- lorsqu'un client décide de jouer à POL, il doit se
connecter en TCP au serveur, en lui donnant un identifiant de
client (un « pseudo ») ;
- par la suite, plusieurs modes de jeu sont possibles :
- mode SOLO : le serveur pose une question au
client sur sa connexion TCP, en proposant un choix de réponses
(typiquement A, B, C ou D). Le client envoie sa réponse au
client, et le serveur lui répond s'il a gagné ou perdu.
- mode CROWD : le serveur pose des questions à
tous les clients connectés en utilisant leur connexion TCP, et
chaque client propose des réponses à des questions. Dans ce
cas, le serveur répond à chaque proposition de réponse
d'un client pour lui dire si c'est juste ou non, et s'il a gagné
ou non. En effet, dans ce mode, c'est seulement le nème client
ayant fourni la bonne réponse qui gagne (par exemple, le
10ème). De plus, dans ce mode, le serveur doit
pouvoir gérer simultanément plusieurs questions, les clients
ne répondant pas tous forcément à la même question.
- mode LAN : sur un même réseau local
(derrière le même routeur), le serveur pose des questions
à tous les clients en UDP sur un groupe (multicast), les clients
proposent des réponses en UDP unicast et, lorsque le
nème client avec la bonne réponse est atteint, le
serveur annonce en multicast sur le groupe l'identifiant du gagnant
avec la bonne réponse. Pour jouer dans ce mode, les clients
doivent être "éligibles", c'est-à-dire être dans le
même LAN que le serveur (pour pouvoir joindre le serveur en UDP,
et reçevoir ses paquets multicasts sans problème). Une
"négociation" entre le serveur et les clients qui souhaitent
jouer en mode LAN est donc nécessaire avant de pouvoir
jouer dans ce mode.
Pour les bases de données de questions et de réponses, vous
pourrez avantageusement imaginer un format de fichier en mode texte,
facilement éditable, que vous pourrez remplir et que le serveur
pourra "charger" en mémoire afin d'en disposer pour les proposer
aux clients.
La mise en œuvre
Pour réaliser ces programmes, vous devrez utiliser les protocoles TCP
et UDP, y compris en multicast pour le mode LAN. Dans ce dernier cas,
vous devrez utiliser des adresses de multicast (classe D) : il
est important, pour ne pas perturber le réseau de l'université,
de ne pas utiliser des adresses "de bord" comme 224.0.0.1 par exemple.
Utilisez plutôt des adresses de milieu de plage, comme
231.110.75.40 par exemple.
Même si vous êtes tentés par le développement
d'interfaces graphiques utilisateurs pour les clients, afin de
rendre leur utilisation plus conviviale, cela vous est fortement
déconseillé dans le cadre de ce projet. Ce qui doit être
mis en œuvre ici est exclusivement la partie
« réseau » et protocolaire, ainsi que la gestion des
données et des ressources. Le mode texte dans une console peut
facilement suffire à l'implantation de vos programmes.
La base et les options
Les fonctionalités de base des programmes à réaliser sont
volontairement assez simples et sont surtout graduelles.
- Le mode SOLO est extrêmement basique et peut être très
rapidement réalisé.
- Le mode CROWD demande de mettre en œuvre plusieurs threads
pour gérer les différentes connexions des clients, et
également l'accès concurrent à une même variable (le
compteur de bonne réponses), étant donnée une question. De
plus, plusieurs questions pouvant être "en cours" en même
temps, cela ajoute un niveau de difficulté qu'il faudra prendre en
compte dans l'architecture de votre implantation.
- Dans le mode LAN, il vous faut un peu plus réfléchir à
la partie réseau, à l'égibilité d'un client pour passer
dans ce mode, à la négociation qu'il devra mener avec le
client, etc. Pour cela, vous devez donc d'avantage réfléchir
à la partie réseau et afiner le protocole de mise en
œuvre du jeu.
- Enfin, il faut que le "packaging" de vos applications, du
côté serveur comme du côté client, permette d'utiliser
indifférement les différents modes (via des options de
lancement ou des choix interactifs proposés à
l'utilisateur). En effet, il n'est pas envisageable d'avoir 3
programmes clients différents et 3 programmes serveurs
différents pour les 3 modes. Vous devrez donc au maximum optimiser
votre conception de l'architecture des applications pour qu'elle
supporte facilement les 3 modes.
Lorsque les spécifications de bases seront réalisées et
fonctionnelles, on attend de vous que vous apportiez des
améliorations aux programmes. Voici quelques pistes d'options que
vous pourrez tenter d'apporter aux programmes de base.
- Gestion des "scores" ou des points pour les clients, palmarès,
etc...
- Choix interactifs ou accès à des niveaux de questions plus
ou moins difficiles par les clients, en fonction de leur score par exemple...
- possibilité de jouer en mode LAN même si on est pas dans le
même réseau local que le serveur principal. Dans ce cas, il
suffit de jouer en mode LAN avec un "proxy" (nouveau programme à
concevoir) qui lui est dans le réseau local avec les clients et
relaye les questions/réponses vers le serveur principal qui est distant...
- etc.
Ce que vous devez rendre
Ce projet est à réaliser en binôme (deux
personnes). Il doit être rendu au plus tard le lundi 26 mars
2007 à 10h00 sous la forme d'un fichier d'archive
ZIP (format obligatoire) contenant:
-
les programmes exécutables du client et du serveur
(préférablement sous la forme de fichier jar exécutables);
-
les fichiers sources
-
un rapport succint (une quinzaine de pages maximum) expliquant
comment installer le serveur et le client, comment s'en servir, les
choix de conception que vous avez fait et les problèmes que vous avez
rencontré.
Le fichier d'archive compressé (ZIP) contenant ces différents
documents sera envoyé par mail, à partir de votre adresse
mail @etudiant.univ-mlv.fr à
Etienne.Duris@univ-mlv.fr au plus tard le 26/03/2007 (la non
réception de mails envoyés depuis des comptes personnels est
fréquente et ne pourra souffir aucune contestation).
http://www-igm.univ-mlv.fr/~duris/TTT/
- © Université de Marne-La-Vallée - Février 2007