TP Noté 2019 : Picross collaboratif

1. Contexte et consignes

1.1 Introduction

Dans ce projet, nous réalisons un serveur et client TCP pour la gestion d'un jeu de « Picross » collaboratif.

Un Picross est un jeu où il faut trouver une image pixel par pixel grâce à des indices fournis sur chaque colonne et chaque ligne de l'image. Il n'est pas utile de comprendre les règles de ce jeu pour réaliser ce TP. Vous devez juste savoir que la fenêtre du jeu se divise en trois zones :

• en haut, les indices sur les colonnes ;
• à gauche, les indices sur les lignes ;
• au centre, la grille de jeu où le joueur clique pour noircir ou blanchir un pixel.

Habituellement, ce jeu se joue en solitaire. L'architecture d'un programme avec interface graphique doit alors contenir trois parties :

• le modèle du jeu qui implémente les règles (module Picross) ;
• l'interface graphique qui dessine le jeu ;
• entre les deux, une API qui permet à l'interface graphique d'obtenir et modifier les données.

Le but de ce TP est de rendre ce jeu collaboratif en réunissant sur le réseau plusieurs joueurs sur la même grille. L'architecture du nouveau programme ressemble donc à la figure suivante :

Vous devez écrire les modules client et serveur de ce modèle. Les autres modules sont déjà écrits et fournis.

Tous les échanges réseaux doivent être mis en œuvre avec la bibliothèque JAVA NIO.

La qualité de votre code fait aussi partie de l'évaluation : il doit être lisible, indenté, commenté, et conforme aux exigences SpotBugs (niveau 15) et Checkstyle (fichier fourni pour ce module).

1.2 Consignes

Vous disposer de 3h pour réaliser ce TP. Vous avez le droit aux documents suivants :

• vos notes de cours et les programmes que vous avez développés durant ce module ;
• le site du cours et tous les liens qu'il contient ;
• la page moodle du module (avec tous les corrigés) ;
• l'API de JAVA ≥ 8.

Pour installer le sujet :

• télé-chargez et décompressez l'archive Maven ;
• renommez dans le fichier pomx.xml le champ artifactId en tpnote-NomPrenom ;
• exécutez la commande « mvn clean install » ;
• importez ce projet Maven dans Eclipse.

Le barème est donné à titre d'indication.

En fin de TP :

1. si ce n'est pas déjà fait, ajouter au fichier readme.txt les informations à destination des correcteurs ;
2. vérifiez la conformité de vos fichiers aux exigences de SpotBugs ;
3. vérifiez la conformité de vos fichiers aux exigences de Checkstyle ;
4. exportez votre projet Eclipse sous la forme d'une archive :
   • cliquez avec le bouton droit sur votre projet ;
   • puis, choisissez export ;
   • ensuite, dans general, choisissez archive ;
   • donnez le nom de l'archive. Eclipse complète le nom du fichier par le suffixe .zip ;
   • cliquez sur finir ;
5. déposez le fichier sur moodle comme devoir ;
6. vérifiez avec l'enseignant présent dans la salle que le fichier téléchargé est correct.

2. Présentation du sujet

2.1 Introduction

L'objectif est d'écrire les classes qui implémentent le protocole entre le serveur et les clients TCP. Pour cela, vous devez compléter les quatre classes suivantes :

• ConnexionAsynchrone : elle contient des méthodes pour gérer une lecture en mode asynchrone (mode du serveur) ;
• AppliSwing et ThreadClient : elles contiennent les méthodes du client chargées de la réception et du traitement des messages venant du serveur ;
• ServeurPicross : elle contient les méthodes pour un serveur asynchrone multiclient réalisant le protocole pour les échanges nécessaires au jeu.

Une dernière question indépendante consiste à modifier l'énumération Protocole.

2.2 Les messages échangés

Tous les messages échangés entre le serveur et les clients sont des trames de taille fixe (MessageProtocole.BUFFERSIZE octets) qui contiennent exactement quatre entiers. Le premier entier correspond au type du message, et les trois autres à des paramètres. Il y a 7 types de messages possibles entre le serveur et les clients. Ils sont listés dans l'énumération Protocole :

1. TAILLE_GRILLE :
   • émis par le serveur pour le client ;
   • signification : taille de la grille de jeu (voir la figure 1) ;
   • premier paramètre : largeur de la grille ;
   • deuxième paramètre : hauteur de la grille ;
   • troisième paramètre : sans usage, doit être mis à zéro ;
   • contrainte protocolaire : ce message est toujours le premier message envoyé par le serveur au client ;
2. TAILLE_INDICES :
   • émis par le serveur pour le client ;
   • signification : tailles des zones d’indices (voir la figure 1) ;
   • premier paramètre : la largeur de la zone des indices sur les lignes ;
   • deuxième paramètre : la hauteur de la zone des indices sur les colonnes ;
   • troisième paramètre : sans usage, doit être mis à zéro ;
   • contrainte protocolaire : ce message est toujours le deuxième message envoyé par le serveur au client ;
3. INDICE_COLONNE :
   • émis par le serveur pour le client ;
   • signification: position et valeur d'un indice sur les colonnes (voir la figure 1) ;
   • premier paramètre: colonne où placer la valeur dans la zone d'indices ;
   • deuxième paramètre: ligne où placer la valeur dans la zone d'indices ;
   • troisième paramètre: la valeur de l'indice ;
   • contrainte protocolaire: ce message peut être envoyé à tout moment par le serveur après les deux premiers ;
4. INDICE_LIGNE:
   • émis par le serveur pour le client ;
   • signification : position et valeur d'un indice sur les lignes (voir la figure 1) ;
   • premier paramètre : colonne où placer la valeur dans la zone d'indices ;
   • deuxième paramètre : ligne où placer la valeur dans la zone d'indices ;
   • troisième paramètre : la valeur de l'indice ;
   • contrainte protocolaire : ce message peut être envoyé à tout moment par le serveur après les deux premiers ;
5. VALEUR_GRILLE_SERVEUR :
   • émis par le serveur pour le client ;
   • signification : position et valeur d'une case de la grille de jeu (voir la figure 1) ;
   • premier paramètre : colonne où placer la valeur dans la grille ;
   • deuxième paramètre : ligne où placer la valeur dans la grille ;
   • troisième paramètre : la valeur de la case ;
   • contrainte protocolaire : ce message peut être envoyé à tout moment par le serveur après les deux premiers ;
6. GAGNE :
   • émis par le serveur pour le client ;
   • signification : la grille a été résolue et c'est la fin de la partie ;
   • premier paramètre : sans usage, doit être mis à zéro ;
   • deuxième paramètre : sans usage, doit être mis à zéro ;
   • troisième paramètre : sans usage, doit être mis à zéro ;
   • contrainte protocolaire : ce message peut être envoyé à tout moment par le serveur après les deux premiers ; mais, il est le dernier message émis avant sa déconnexion ;
7. VALEUR_GRILLE_CLIENT :
   • émis par le client pour le serveur ;
   • signification : position et valeur d'une case de la grille de jeu (voir la figure 1) ;
   • premier paramètre : colonne où placer la valeur dans la grille ;
   • deuxième paramètre : ligne où placer la valeur dans la grille ;
   • troisième paramètre : la valeur de la case ;
   • contrainte protocolaire : ce message peut être envoyé à tout moment par le client.

Les messages du protocole sont construits par la classe MessageProtocole. Elle contient deux constructeurs :

• le premier constructeur permet de construire un message à partir du type de message et des trois paramètres. Le buffer de la trame à envoyer sur le réseau s'obtient alors par la méthode getBuffer() ;
• le second constructeur permet de construire un message à partir du buffer contenant la trame reçue du réseau. Le type du message et les paramètres du message s'obtiennent avec les méthodes getType(), getVal1(), getVal2(), et getVal3().

Voici un exemple d'usage pour obtenir un buffer prêt à être envoyé sur le réseau :

Voici un exemple d'usage pour obtenir les informations du message à partir d'un buffer reçu du réseau :

L'action à réaliser à la réception d'un message du protocole est fixée par l'énumération Protocole. Son constructeur associe à chaque énumérateur une instance d'une classe qui implémente l'interface ProtocoleAction. Cette interface demande l'implémentation de la méthode void realiser(PicrossApi picrossApi, int val1, int val2, int val3). Cette méthode doit contenir l'action à faire lors de la réception du message de ce type.

Les classes qui doivent recevoir et traiter les messages ont toutes un attribut (déjà initialisé par le code qui vous est donné) picrossApi contenant la référence à passer en premier paramètre de la méthode realiser(). Le traitement d'un message du protocole se fait donc avec l'appel de la méthode realiser() avec un code qui doit ressembler à ce qui suit : ProtocoleMessage message = ... // la méthode de réception du message. // ici les vérifications que ce message est cohérent avec le contexte du protocole. ... // si c'est ok, action à réaliser: message.getType().getProtocoleAction().realiser(picrossApi, message.getVal1(), message.getVal2(), message.getVal3());

3. Les 8 questions du sujet

3.1 Introduction

Il y a 8 questions :

• 3 méthodes à écrire dans la classe ConnexionAsynchrone (3 pt) ;
• 2 méthodes à écrire dans la classe ThreadClient (7 pt) ;
• 2 méthodes à écrire dans la classe ServeurPicross (8 pt) ;
• l'énumération Protocole à modifier (2 pt).

Le barème est donné à titre d'indication.

Les 7 premières questions doivent être faites dans l'ordre, mais la dernière question est indépendante et peut être faite à tout moment.

Des tests sont fournis pour les six premières questions. Dans l'archive qui vous est donnée, ils sont désactivés par l'annotation @Ignore. Après l'écriture d'une méthode, pour la tester il faut :

• mettre en commentaire la ligne contenant l'annotation @Ignore du test ;
• lancer la commande « mvn clean install » ; la totalité des tests réactivés sont exécutés.

Les tests sont écrits avec deux niveaux de log :

• l'annonce du début et de la fin du test est au niveau INFO ;
• l'annonce de chaque point testé est au niveau TRACE.

Les logs des tests sont très verbeux, si vous voulez alléger leur sortie, il suffit de régler le niveau du Logger au début de chaque méthode de test.

Les tests ne fonctionnent que si vous faites les questions dans l'ordre.

3.2 Écriture de la classe ConnexionAsynchrone (3pt)

3.2.1 Introduction

La classe ConnexionAsynchrone gère la réception des messages en mode asynchrone. Pour cela, elle associe un buffer (l'attribut buffer de la classe) au canal de la connexion, et fournit des méthodes pour gérer ce buffer.

La lecture d'un message asynchrone peut nécessiter plusieurs appels à la méthode avancerLecture() avant la réception complète du message. Lorsque le message est complètement reçu, la méthode avancerLecture() passe le statut messageComplet à true, et ensuite, la méthode getMessage() peut fournir ce message. La méthode getMessage() doit pouvoir être appelée plusieurs fois pour le même message.

La méthode clear() de la classe doit être appelée avant de commencer la lecture d'un nouveau message.

3.2.2 Création de la connexion asynchrone (1pt)

Écrivez le constructeur de la classe ConnexionAsynchrone. Le paramètre rwChan est le canal déjà connecté. Le constructeur doit rendre la connexion asynchrone et initialiser deux attributs de la classe :

• rwChan : il doit être initialisé avec le canal déjà connecté passé en paramètre du constructeur ;
• buffer : il doit être exactement dimensionné pour les échanges des messages du protocole.

Pour tester votre code, activez le test de la méthode testConnexionAsynchrone() de la classe de test tp4509.tcp.TestConnexionAsynchrone.

3.2.3 Lecture en mode asynchrone (1pt)

Écrivez la méthode avancerLecture() qui doit faire progresser la lecture d'un message du protocole, et ainsi le recevoir complètement appel après appel. Elle signale que le message est complètement reçu en passant le statut de messageComplet à true.

Pour tester votre code, activez le test de la méthode testAvancerLecture() de la classe de test tp4509.tcp.TestConnexionAsynchrone.

3.2.4 Réception du message (1pt)

Écrivez la méthode getMessage() qui fournit un message du protocole s'il est complètement arrivé, et null sinon. La méthode doit pouvoir fournir plusieurs fois le même message.

Pour tester votre code, activez le test de la méthode testGetMessage() de la classe de test tp4509.tcp.TestConnexionAsynchrone.

Attention: le test ci dessus contient une boucle. Si votre méthode est mal écrite cette boucle peut devenir une boucle infinie et le test ne se terminera jamais.

3.2.5 Lecture de la classe

Les autres méthodes de la classe sont déjà écrites ; vous n'avez donc pas à les programmer. Mais, vous devez en utiliser certaines pour la suite du sujet. Donc, prenez le temps de lire et de comprendre les méthodes suivantes :

• clear() : elle prépare la classe pour la réception d'un nouveau message. Le message précédemment reçu est perdu et la méthode getMessage() ne peut délivrer un nouveau message qu'après sa réception complète ;
• messageComplet() : cette méthode indique si le message en cours réception est complet ou non. Il faut tester cette méthode avant tout appel à getMessage() ;
• close() : elle ferme le canal de connexion. Elle doit être appelée toutes les fois que vous voulez fermer la connexion ou que vous détectez que le distant a fermé la connexion ;
• envoyer() : elle envoie un message du protocole. Même si le canal est asynchrone, on considère qu'un seul appel à cette méthode suffit pour envoyer le message complètement.

3.3 Écriture de la classe ThreadClient (7pt)

3.3.1 Introduction

Pour éviter de gérer une connexion asynchrone, l'application cliente (AppliSwing) lance deux threads :

• le premier est le thread de SWING : il gère les évènements venant du joueur (les clics de souris), et envoie les messages au serveur (les messages VALEUR_GRILLE_CLIENT). Il est lancé à la fin de la méthode main() par une méthode de classe de SwingUtilities: SwingUtilities.invokeLater(tacheSwing) ;
• le second, que vous devez écrire, est dédié à la réception et au traitement des messages émis par le serveur. Ces messages sont donc reçus en mode synchrone : le mode de lecture est « bloquant » et contient une boucle jusqu'à réception complète. Vous devez écrire son lancement à la question 3.3.3.

La classe ThreadClient contient la méthode run() de ce thread. Elle possède deux attributs initialisés par le constructeur qui vous est donné :

• rwChan : un canal sur une connexion TCP déjà ouverte avec le serveur ;
• picrossApi : la référence vers l'API du picross. Pour ce client, vous avez besoin de cette API pour trois usages :
  1. cette référence sera le premier paramètre de la méthode realiser() qu'il faut appeler à la réception de chaque message du protocole ;
  2. pour savoir si la partie est gagnée, il faut faire appel à la méthode PicrossApi::estGagne() ;
  3. pour signaler au joueur une perte de connexion, il faut faire appel à la méthode PicrossApi::setConnexionPerdue(boolean) avec la valeur true.

3.3.2 Écriture de la méthode recevoirMessage() (2pt)

Le rôle principal du thread du client est de recevoir des messages et de réaliser l'action associée. La méthode recevoirMessage() réalise la réception d'un message en mode synchrone.

Écrivez la méthode recevoirMessage() qui retourne le message une fois qu'il est totalement reçu, ou la valeur null si une exception se produit ou si la connexion est fermée.

Pour tester votre code, activez le test de la méthode testRecevoirMessage() de la classe de test tp4509.tcp.TestThreadClient.

3.3.3 Lancement du thread et écriture de la méthode run() (5pt)

Commencez par écrire les instructions pour lancer le thread:

La classe runnable ThreadClient est déjà partiellement écrite, mais les instructions qui lancent le thread avec cette classe restent à écrire. Ajoutez à la fin de la méthode main() de la classe tp4509.graphique.AppliSwing les intructions pour lancer un nouveau thread qui exécute la méthode run() de la classe ThreadClient.

Ensuite écrivez la méthode run():

La signature de la méthode run() nous est imposée par l'interface Runnable et ne permet donc pas la transmission des exceptions. Il faut traiter dans la méthode toutes les exceptions qui peuvent se produire. Le traitement d'une exception se fera par l'affichage du message de l'exception. Donc, pour les exceptions que votre code lève, veuillez fournir un message clair qui explicite la raison de l'exception.

En mode réseau, l'application graphique ne peut pas s'initialiser tant que les informations sur la taille de la grille et des indices ne sont pas reçues. Le thread de l'application graphique est bloqué par un wait() en attente d'une notification signalant la disponibilité de ces informations. Lorsqu'elles sont reçues et traitées, il faut appeler la méthode notifierFinInitialisation() pour redémarrer le thread de l'application graphique.

La méthode run() déroule le protocole d'une partie de Picross. Elle doit donc ressembler à cela :

• réception et traitement du message de protocole TAILLE_GRILLE ;
• réception et traitement du message de protocole TAILLE_INDICES ;
• notification de l'interface graphique avec la méthode notifierFinInitialisation() ;
• tant que la partie n'est pas gagnée :
  • réception et traitement des tous les messages de protocole sauf TAILLE_GRILLE et TAILLE_INDICES.

Si l'ordre des messages du protocole n'est pas cohérent, il faut lever l'exception ProtocoleException avec un message explicite. L'erreur est considérée comme fatale (fin du thread) s'il s'agit d'un deux premiers messages, mais sinon il faut afficher le message, et continuer le programme.

Écrivez la méthode run(). Si la façon de traiter un message du protocole ne vous semble pas claire, relisez la section 2.2 du sujet.

Pour tester votre code pour les situations normales, activez le test de la méthode testRun() de la classe de test tp4509.tcp.TestThreadClient.

Pour tester votre code pour les situations anormales, activez le test de la méthode testRun2() de la classe de test tp4509.tcp.TestThreadClient.

Même si votre code ne passe pas la seconde série de tests, vous pouvez continuer la suite du sujet : votre programme fonctionnera dans les situations normales ; cependant il n'aura pas le comportement attendu en cas d'anomalies dans le protocole.

3.4 Écriture de la classe ServeurPicross (8pt)

3.4.1 Introduction

La classe ServeurPicross contient un serveur TCP multiclient en mode asynchrone. Vous devez écrire deux méthodes :

• la méthode createServerSocket() qui crée un serveur TCP asynchrone ;
• la méthode serverLoop() qui contient la boucle d'attente des nouveaux clients et des messages des clients déjà connectés.

La méthode envoyerPicross() vous est donnée. Elle contient le code qui envoie toutes les informations utiles à un client qui se connecte.

3.4.2 Écriture de la méthode createServerSocket() (2pt)

Écrivez le code qui crée un serveur TCP asynchrone en attente sur le port passé en paramètre.

3.4.3 Écriture de la méthode serverLoop() (6pt)

Écrivez la boucle d'un serveur asynchrone en utilisant la classe Selector de JAVA NIO.

Chaque client connecté est représenté par une instance de la classe ConnexionAsynchrone écrites à la question 3.2 de ce sujet.

Cette boucle doit gérer trois types d’événements :

1. la connexion d'un nouveau client, il faut :
   • l'ajouter à la liste des clients traités ;
   • appeler la méthode ServeurPicross::envoyerPicross() pour envoyer l'état de la grille au nouveau joueur ;
2. la déconnexion d'un client : il faut le retirer de la liste des clients traités ;
3. la réception du message VALEUR_GRILLE_CLIENT de la part d'un client, il faut :
   • enclencher le traitement du message pour modifier la grille mémorisée par le serveur ;
   • informer tous les clients du changement de la grille, sauf l'émetteur qui, a fortiori, est déjà au courant. Pour cela il faut leur envoyer le message VALEUR_GRILLE_SERVEUR avec les trois mêmes paramètres que le message reçu.

Cette boucle s'arrête quand la partie est gagnée (picrossApi.estGagne() retourne true). Il faut alors envoyer le message GAGNE à tous les clients.

Écrivez la méthode serverLoop().

Une fois cette méthode écrite, le programme est terminé et il est possible de le lancer. Pour le tester, voici la procédure :

• ouvrez quatre terminaux en vous plaçant dans le répertoire racine du projet (là où il y a le fichier pom.xml) ;
• dans le premier terminal, lancez la commande « mvn exec:java@server ». Cette commande lance le serveur sur le port 4545 et sur le fichier de jeu ./data/sablier.txt ;
• dans le deuxième terminal, lancez la commande « mvn exec:java@client ». Cette commande lance l'application graphique qui lancera le thread client (connexion sur l'adresse localhost:4545). Cliquez sur deux ou trois cases de la grille pour les noircir ;
• dans les deux derniers terminaux, lancez la commande « mvn exec:java@client ». Cela lance la même application graphique, mais la fenêtre de jeu doit déjà avoir en noir les cases que vous avez noircies dans la première fenêtre. Cliquez sur des cases dans les trois fenêtres, et l'action doit à chaque fois être visible partout ;
• résolvez la partie en prenant modèle sur la solution ci-dessous. Le serveur doit s'arrêter de lui même, et les fenêtres doivent annoncer que la partie est gagnée et devenir insensible aux clics de souris. Vous pouvez terminer les applications en fermant les fenêtres de jeu.

Faites la question 3.5 avant de tenter les tests ci dessous.

Pour tester la robustesse de votre application, vérifiez que l'utilisateur ne subit pas une pile d'exception, mais peut soit continuer la partie normalement, soit être averti par un message clair de la raison de la fin du programme pour les cas suivants :

• faites entrer et sortir des clients en cours de partie : les joueurs restant doivent pouvoir continuer sans s'en rendre compte ;
• faites tomber le nombre de client à 0, et relancez un nouveau client. Le nouveau joueur doit récupérer la partie dans l'état où l'ont laissée les anciens ;
• tuez le serveur (avec un Contrôle C) en cours de partie. Les joueurs doivent avoir un message qui annonce une déconnexion.

3.5 Classe anonyme et expression lambda pour l'énumération Protocole (2pt)

Dans l'énumération Protocole, l'association entre la méthode à appeler et la valeur de l'énumérateur est faite avec le constructeur qui reçoit en paramètre une instance d'un objet qui implémente l'interface fonctionnelle ProtocoleAction. Dans le code actuel, toutes les constructions se font grâce à des classes d'implémentation définies de façon explicite dans le paquetage tp4509.tcp.protocole_action.

Modifiez la construction de l'énumérateur TAILLE_GRILLE en utilisant une classe anonyme à la place de la classe TailleGrilleAction.

Modifiez la construction de l'énumérateur TAILLE_INDICES en utilisant une expression lambda à la place de la classe TailleIndicesAction.

Supprimez les classes TailleGrilleAction et TailleIndicesAction (et leur ligne d'import) dans le paquetage tp4509.tcp.protocole_action et vérifiez que le programme fonctionne encore. Si vous avez besoin de rétablir ces classes, il y a une version de sauvegarde dans le dossier save du projet.