:: Enseignements :: Master :: Master TTT :: 2012-2013 :: Programmation réseau en Java ::

Tagger

Nous disposons d'une base de médias pour lesquels nous souhaitons affiner les métadonnées associées. Dans cet objectif, nous désirons étiqueter chaque média par des étiquettes (tags) qui pourront par exemple servir par la suite au développement d'un moteur de recherche. Nous voulons rendre la tâche d'étiquetage ludique : à cet effet nous proposons un jeu accessible aux internautes au cours duquel ils fourniront les tags des médias.

Merci de consulter régulièrement cette page qui peut faire l'objet de mises à jour. Les discussions sur le projet sont les bienvenues sur cette page de wiki.

Principe général du jeu

Le jeu d'étiquetage est grandement inspiré de l'ESP game qui a lui même donné naissance à Google Image Labeler (actuellement fermé). Son principe consiste à organiser des parties de jeu au cours desquelles deux joueurs se voient proposer un média (livre, film, CD...) ; ils doivent alors chacun proposer en parallèle des tags s'appliquant à ce média en un temps limité. Lorsque les deux joueurs proposent deux tags similaires, celui-ci est validé et stocké en base pour être associé au média. La proposition concomitante du même tag par deux joueurs indépendants nous permet de nous assurer de la pertinence de celui-ci. Le score des deux joueurs est augmenté pour les récompenser. À l'issue du temps limité, la partie est terminée et le score gagné est rajouté au score global des deux joueurs qui reviennent peupler une réserve de joueurs disponibles prêts à redémarrer une nouvelle partie.

Détails d'implantation

L'implantation du jeu nécessite de développer deux applications : un serveur de jeu utilisé pour distribuer les médias, récolter les tags et gérer les scores des joueurs et un client chargé de mettre en relation un joueur humain avec le serveur afin qu'il puisse jouer en soumettant ces tags. La communication est régie par un protocole qu'il conviendra de définir.

Le protocole

Le protocole de communication entre client et serveur est un document préalable devant être rédigé préalablement à l'implantation du client et du serveur. Il définit comment les clients et serveur dialoguent ensemble. La seule connaissance de la documentation du protocole doit pouvoir permettre d'implanter des clients compatibles avec un serveur suivant le protocole. On utilisera un protocole de transport IP (UDP et/ou TCP) et on décrira tous les messages échangés, leurs formats (binaire, textuel avec indication d'encodage...) ainsi que les scénarios de dialogues et comportements des clients et serveurs (y compris en cas d'erreurs et événements exceptionnels : déconnexion d'un client en cours de partie, extinction du serveur...). On essaiera si possible de proposer un protocole relativement compatible avec l'utilisation de clients derrière un dispositif de NAT.

Le serveur

Une fois le protocole bien défini, le serveur peut être implanté. Celui-ci accueille des joueurs qui doivent préalablement s'inscrire puis s'authentifier (avec nom et mot de passe) afin de retrouver leur score global issu des parties antérieures. Lorsqu'un joueur se connecte, il est mis dans une file d'attente du serveur. Lorsque deux joueurs sont disponibles en file, ceux-ci sont sélectionnés pour démarrer une partie : un média est choisi aléatoirement en base dont les caractéristiques sont communiquées aux clients avec un temps limite de réponse. Des tags interdits sont également spécifiés et communiqués aux joueurs : il s'agit de tags proposés à de nombreuses reprises lors de parties précédentes sur ce média. Les joueurs n'ont pas le droit de proposer un tag interdit (au risque d'une pénalité). Le serveur reçoit les propositions des joueurs : les tags proposés conjointement par les deux joueurs sont validés : ceux-ci peuvent être ou non déjà présents en base. Le score de confiance du tag est incrémenté en base ; les joueurs se voient attribuer des points inversement proportionnels au score de confiance (afin de plus récompenser la trouvaille de tags difficiles par rapport aux tags évidents). On note que lorsque le score de confiance d'un tag dépasse un seuil prédéfini (définissable dans un fichier de configuration), celui-ci devient un tag interdit.

Le serveur doit permettre le déroulement de plusieurs parties d'étiquetage simultanées (il n'est pas question de faire attendre un joueur si un autre partenaire libre existe en file d'attente). Un administrateur doit avoir la possibilité à tout moment d'arrêter le serveur qui informera avec courtoisie les clients connectés de sa fermeture.

Si le protocole de communication utilisé est basé sur des échanges de lignes de texte (plutôt que des données binaires), tester le serveur devrait être possible avant l'implantation du client graphique en utilisant un client texte (tel que netcat).

Le client

Le client est chargé de communiquer avec le serveur pour permettre au joueur de s'inscrire, s'authentifier et participer à une partie en proposant des tags. Le joueur doit interagir avec le client au moyen d'une interface graphique Swing agréable. Celle-ci informe le joueur des caractéristiques du média à tagger, du temps limite de la partie, des mots interdits ainsi que des mots gagnés proposés conjointement avec l'autre joueur. Les scores du joueur et de son partenaire sont également affichés. Il est également possible d'afficher un palmarès des meilleurs joueurs avec leurs scores globaux.

Consignes générales

Voici quelques consignes qu'il est très vivement conseillé de suivre afin de mettre de bonne humeur le correcteur.

Le projet doit être réalisé en binôme.
On cherchera à implanter le projet par étapes. Il est ainsi préférable de rendre seulement un serveur fonctionnant parfaitement et utilisable avec un client en mode texte plutôt que de chercher à tout implanter (serveur, client graphique) avec de nombreux bugs.
Le code source doit être clair (bonne indentation, noms de variables intelligibles, architecture logique, découpage en paquetages hiérarchiques, pas de redondances de code...) et commenté judicieusement.
Une documentation de développement (au format PDF) doit être rédigée décrivant l'architecture globale du projet, difficultés rencontrées et solutions apportées.
Un fichier texte décrivant le protocole de communication doit être fourni. Le style de rédaction de ce document doit s'inspirer de celui des RFCs (exemple parmi d'autres de RFC : RFC 1436).
Un script de compilation doit être inclus. Il peut s'agit d'un Makefile ou d'un build.xml (pour Ant).
Un fichier texte LISEZMOI doit être fourni avec des informations à destination de l'utilisateur afin qu'il puisse exécuter et configurer client et serveur sans avoir à consulter le code source (on proscrira notamment toute constante de configuration en dur dans le code source). Les programmes doivent être exécutables depuis un terminal sans l'aide d'un environnement de développement (Eclipse, Netbeans...).
La copie de code ou de documentation externe est interdite (copie depuis un autre groupe, sur Internet...) et sera sanctionnée par une note nulle.
Le rendu doit être effectué dans une archive zip nommée tagger-login1-login2.zip (les logins sont à remplacer par ceux du binôme) envoyée avant l'échéance fixée par email (sujet : [tagger-m2ttt] login1 login2) depuis le webmail de l'université à chilowi at univ-mlv.fr et mlandsnet at yahoo.fr.
Toute question à propos du projet doit être posée sur cette page de wiki.