Joueur distant
Javass – étape 7

L'idée de la technique que nous utiliserons dans cette étape pour offrir aux joueurs la possibilité de jouer à distance est simple et peut s'illustrer au moyen d'un exemple d'émission télévisée de Jass.

Admettons donc qu'une chaîne de télévision désire offrir une émission durant laquelle trois joueurs présents sur le plateau jouent au Jass avec une téléspectatrice jouant depuis chez elle. Cette dernière ne peut bien entendu pas participer physiquement à la partie : elle ne peut ni tenir ses cartes en main, ni en extraire une afin de la poser sur la table lorsque c'est à elle de jouer. Pour qu'elle puisse néanmoins jouer normalement, il faut donc qu'une autre personne, présente sur le plateau, lui serve d'intermédiaire. La téléspectatrice et son intermédiaire communiquent via la télévision et le téléphone : lorsque les cartes sont distribuées, l'intermédiaire prend celles destinées à la téléspectatrice et les montre à la caméra ; lorsque c'est à la téléspectatrice de jouer, elle communique par téléphone la carte qu'elle désire jouer à l'intermédiaire, qui la joue pour elle ; et ainsi de suite.

On pourrait même imaginer une solution plus sophistiquée permettant à la téléspectatrice d'avoir l'illusion de jouer une véritable partie chez elle. Plutôt que de la faire communiquer directement avec son intermédiaire sur le plateau de télévision, un assistant présent chez elle se chargerait de cette communication. La téléspectatrice pourrait alors s'asseoir à une table comme si elle jouait avec d'autres personnes présentes, et l'assistant se chargerait de maintenir cette illusion : une fois informé par l'intermédiaire des cartes présentes dans la main de la téléspectatrice, il lui donnerait des cartes identiques ; de même, une fois informé par l'intermédiaire d'une carte jouée par l'un des trois autres joueurs, l'assistant poserait une carte identique sur la table de la téléspectatrice. Et ainsi de suite.

La technique que nous utiliserons dans le projet est très similaire à cette seconde solution. L'intermédiaire et l'assistant mentionnés ci-dessus seront des objets Java, communiquant entre eux au moyen de messages textuels transmis via Internet, mais l'idée de base est la même.

Le premier de ces objets, que nous nommerons le client, joue le rôle de l'intermédiaire présent sur le plateau de télévision dans notre exemple. Cet objet se trouve sur l'ordinateur sur lequel se déroule la partie, et du point de vue de cette dernière, il n'est rien d'autre qu'un joueur comme un autre. En termes Java, cela signifie que le client est une instance d'une classe implémentant l'interface Player.

Le second de ces objets, que nous nommerons le serveur, joue le rôle de l'assistant présent chez la téléspectatrice dans notre exemple. Cet objet se trouve (généralement) sur un autre ordinateur que celui sur lequel la partie se déroule. Son but est de donner l'illusion à un joueur local qu'il participe à une partie normale. En termes Java, cela signifie que le serveur appelle les méthodes du joueur local — un objet de type Player — exactement comme le fait habituellement l'objet JassGame lors d'une partie locale.

Pour illustrer le fonctionnement de cette solution, imaginons une partie de Jass entre quatre joueurs simulés. La partie elle-même, c-à-d l'instance de JassGame, et trois des joueurs simulés, se trouvent sur un premier ordinateur que nous appellerons l'ordinateur A. Le dernier joueur simulé se trouve sur l'ordinateur B.

Pour que le quatrième joueur simulé puisse participer à la partie, il faut qu'un client le représente — en quelque sorte — sur l'ordinateur A, et communique avec un serveur sur l'ordinateur B. Le serveur, quant à lui, appelle les méthodes du joueur simulé qui s'exécute sur l'ordinateur B en fonction des messages que lui envoie le client via le réseau.

Admettons que ce soit justement au joueur simulé distant de jouer en premier au premier tour de la partie. L'instance de JassGame représentant cette dernière appelle la méthode cardToPlay du client afin de savoir quelle carte il désire jouer. Le client n'étant qu'un représentant d'un joueur, et pas un joueur réel, il se contente d'envoyer un message au serveur le priant de bien vouloir demander au joueur simulé quelle carte il désire jouer. A la réception de ce message, le serveur appelle la méthode cardToPlay du joueur simulé, et lorsque celui-ci répond, il transmet la réponse au client via le réseau, qui retourne le résultat de sa méthode cardToPlay à lui.

Comme cet exemple l'illustre, l'objet JassGame n'a absolument pas « conscience » du fait que le quatrième joueur simulé est distant : de son point de vue, le client est le quatrième joueur.

Les différents appareils connectés à Internet — généralement appelée hôtes (host) — communiquent entre eux au moyen d'un grand nombre de protocoles distincts, dont la description complète sort du cadre de cette étape. Néanmoins, une rapide introduction est nécessaire et les personnes intéressées par plus de détails peuvent suivre les liens vers Wikipedia inclus ci-dessous.

Les protocoles d'Internet sont organisés en différentes couches, correspondant à différents niveaux d'abstraction. Les protocoles d'une couche donnée sont toujours basés sur ceux de la couche juste en-dessous. Trois de ces couches et plusieurs protocoles importants de chacune d'entre elles sont illustrées sur la figure 1.

Comme nous le verrons plus loin, le protocole du jeu, désigné par Javass dans cette figure, est basé sur le protocole TCP de la couche inférieure, lui-même basé sur IP. Beaucoup de protocoles connus — p.ex. HTTP qui est le protocole du Web, ou SMTP et IMAP qui sont liés au courrier électronique — se basent également sur TCP.

Afin de rendre concret les différents concepts présentés ci-dessus, et voir comment il est possible de les mettre en œuvre en Java, un petit exemple complet est présenté plus bas. Il est constitué de deux programmes :

1. un serveur « successeur » qui écoute sur le port TCP 5108 et, dès qu'une connexion y est faite, lit un message textuel d'une ligne constitué de la représentation textuelle, en base 10, d'un entier, puis répond au moyen d'une ligne constituée du successeur de cet entier,
2. un client qui se connecte au serveur, lui envoie le message 2019 afin de connaître le successeur de ce nombre, et affiche le résultat (2020) à l'écran.

Le code du serveur est présenté en premier ci-après. La plupart de ce code est du code d'entrée/sortie standard, et le fait que ces entrées/sorties se fassent à travers le réseau n'est pas visible. Quelques points méritent toutefois d'être décrits plus en détails.

Pour commencer, le serveur crée une instance de ServerSocket qui est une « prise » (socket) permettant au serveur d'attendre des connexions TCP sur un port donné, ici 5108. Une fois cette prise créée, le serveur appelle sa méthode accept qui bloque l'exécution du programme jusqu'à ce qu'une connexion soit effectuée sur ce port. Une fois que cela se produit, accept retourne une nouvelle prise, de type Socket cette fois, qui peut être utilisée pour échanger des données avec l'entité connectée à l'autre bout, ici le client décrit plus bas. Cet échange de données se fait au moyen des flots d'entrée et de sortie de la prise, qui s'obtiennent au moyen des méthodes getInputStream et getOutputStream. Une fois obtenus, ces flots s'utilisent de manière tout à fait standard.

Une fois que le serveur a lu le nombre envoyé par le client, calculé son successeur et écrit la représentation textuelle de ce dernier sur le flot de sortie, il fait encore deux choses :

• il écrit une fin de ligne (au moyen de w.write('\n')), la séquence \n représentant en Java le caractère de contrôle LF,
• il appelle la méthode flush afin de vidanger le flot, ce qui permet de garantir que les données qui y ont été écrites jusqu'alors sont bien envoyées sur le réseau à ce moment-là.

Finalement, l'énoncé catch à la fin de la méthode main a pour but de transformer (en quelque sorte) les éventuelles exceptions d'entrées/sorties de type IOException en exceptions équivalentes mais de type UncheckedIOException. La différence entre les deux types d'exception est que le premier est un type d'exception checked, le second pas. Lorsqu'on ne désire pas traiter les exception de manière particulière, comme ici, il est plus simple d'avoir affaire au second type qu'au premier, car il n'est pas nécessaire d'ajouter les throws dans les déclarations des méthodes.

import static java.nio.charset.StandardCharsets.US_ASCII;

public final class SuccServer {
  public static void main(String[] args) {
    try (ServerSocket s0 = new ServerSocket(5108);
	 Socket s = s0.accept();
	 BufferedReader r =
	   new BufferedReader(
	     new InputStreamReader(s.getInputStream(),
				   US_ASCII));
	 BufferedWriter w =
	   new BufferedWriter(
	     new OutputStreamWriter(s.getOutputStream(),
				    US_ASCII))) {
      int i = Integer.parseInt(r.readLine());
      int i1 = i + 1;
      w.write(String.valueOf(i1));
      w.write('\n');
      w.flush();
    } catch (IOException e) {
      throw new UncheckedIOException(e);
    }
  }
}

Le code du client est quant à lui présenté ci-dessous. Le seul commentaire qui mérite d'être fait à son sujet est que pour se connecter au serveur le client crée directement une prise de type Socket en passant en arguments au constructeur un nom d'hôte (ici localhost qui désigne l'ordinateur sur lequel s'exécute le client) et un port. Le fait de passer ces arguments au constructeur a pour effet d'établir directement la connexion au serveur. Il est donc immédiatement possible d'échanger des données avec le serveur en utilisant les mêmes techniques que ci-dessus.

import static java.nio.charset.StandardCharsets.US_ASCII;

public final class SuccClient {
  public static void main(String[] args) {
    try (Socket s = new Socket("localhost", 5108);
	 BufferedReader r =
	   new BufferedReader(
	     new InputStreamReader(s.getInputStream(),
				   US_ASCII));
	 BufferedWriter w =
	   new BufferedWriter(
	     new OutputStreamWriter(s.getOutputStream(),
				    US_ASCII))) {
      int i = 2019;
      w.write(String.valueOf(i));
      w.write('\n');
      w.flush();
      int succ = Integer.parseInt(r.readLine());
      System.out.printf("succ(%d) = %d%n", i, succ);
    } catch (IOException e) {
      throw new UncheckedIOException(e);
    }
  }
}

En programmation, l'action consistant à représenter des objets existants en mémoire en une suite d'octets ou de caractères afin p.ex. de les transmettre via le réseau se nomme sérialisation (en anglais : serialization ou encore marshalling ou pickling). Il vaut la peine d'avoir une classe facilitant la (dé)sérialisation des valeurs échangées entre le client et le serveur, et c'est le but de la classe StringSerializer du paquetage ch.epfl.javass.net.

Il s'agit d'une classe publique, finale et non instanciable, qui contient des méthodes statiques permettant de sérialiser et désérialiser, sous forme de chaînes de caractères, des valeurs des types suivants :

• entiers de type int et long, sérialisés sous la forme de leur représentation textuelle en base 16 (méthodes nommées p.ex. serializeInt, deserializeInt, serializeLong et deserializeLong),
• chaînes de caractères de type String, sérialisées par encodage en base64 des octets constituant leur encodage en UTF-8 (serializeString et deserializeString).

D'autre part, la classe StringSerializer contient deux méthodes simplifiant la (dé)sérialisation de valeurs composites comme TurnState ou la table associative des noms des joueurs :

• la première prend un nombre variable de chaînes en argument, un caractère de séparation (ici la virgule) et retourne la chaîne composée des chaînes séparées par le séparateur (combine),
• la seconde fait l'inverse et prend une chaîne unique et un caractère de séparation (ici la virgule) et retourne un tableau contenant les chaînes individuelles (split).

Le type énuméré JassCommand du paquetage ch.epfl.javass.net énumère les 7 types de messages échangés par le client et le serveur (PLRS, TRMP, etc.).

Notez qu'au moyen de la méthode name de ce type énuméré, vous pouvez très facilement convertir une valeur de ce type en la chaîne correspondante. Pour faire l'inverse, tous les types énumérés offrent une méthode statique nommée valueOf, prenant une chaîne en argument et retournant l'élément de l'énumération portant le nom donné.

La classe RemotePlayerServer du paquetage ch.epfl.javass.net, publique et finale, représente le serveur d'un joueur, qui attend une connexion sur le port 5108 et pilote un joueur local en fonction des messages reçus.

Elle offre un unique constructeur public auquel on passe le joueur local, de type Player, dont les différentes méthodes doivent être appelées en fonction des messages reçus via le réseau.

En plus du constructeur, elle offre une méthode ne prenant aucun argument et ne retournant rien, nommée p.ex. run, qui, dans une boucle infinie :

1. attend un message du client,
2. appelle la méthode correspondante du joueur local, et
3. dans le cas de cardToPlay, renvoie la valeur de retour au client.

La classe RemotePlayerClient du paquetage ch.epfl.javass.net, publique et finale, représente le client d'un joueur. Elle implémente bien entendu l'interface Player. Elle devrait de plus implémenter l'interface AutoCloseable afin de pouvoir être utilisée dans un énoncé try-with-resources.

Son constructeur prend en argument le nom de l'hôte sur lequel s'exécute le serveur du joueur distant, et s'y connecte.

Les différentes méthodes provenant de l'interface Player ne font rien d'autre qu'envoyer les messages correspondants au serveur et, dans le cas de cardToPlay, attendre sa réponse.

La méthode close quant à elle appelle les méthodes close des flots d'entrée et de sortie de la prise utilisée pour se connecter au serveur, ainsi que celle de la prise elle-même.

A partir de cette étape, aucun fichier de vérification de signatures ne vous est fourni, étant donné que la signature des différentes méthodes n'est plus spécifiée en détail. Pour la même raison, aucun test unitaire ne sera plus fourni à l'avenir, à vous d'écrire les vôtres. Notez que cela est fortement recommandé en général.

Pour tester cette étape, il est conseillé d'écrire un petit programme simulant une partie entre différents joueurs simulés ou aléatoires, dont au moins un est un joueur distant. Initialement, ce joueur distant peut s'exécuter sur le même ordinateur que la partie elle-même.

Une fois qu'il vous est possible de jouer une partie avec un joueur distant local, il est conseillé d'essayer de jouer avec le joueur distant d'un autre groupe, fonctionnant sur un autre ordinateur. Pour cela, il faut tout d'abord déterminer l'adresse IP de l'ordinateur sur lequel le serveur sera exécuté. Il existe de très nombreux moyens de l'obtenir, le plus simple étant probablement d'utiliser un site comme WhatIsMyIP. En cliquant sur ce lien depuis l'ordinateur exécutant le serveur, vous verrez s'afficher l'adresse IP de son ordinateur, que vous pourrez utiliser comme nom d'hôte passé au client.

Pour faire ces tests, assurez-vous d'être connecté au réseau de l'EPFL, soit par Wifi, soit par le réseau câblé. Pour différentes raisons — en particulier l'utilisation systématique de NAT — il est très peu probable que vous soyez en mesure d'échanger des données entre un serveur et un client situés sur des machines accédant à Internet via un fournisseur d'accès Internet commercial (Swisscom, Cablecom, etc.). Si vous désirez néanmoins effectuer des tests depuis l'extérieur de l'EPFL, connectez-vous dans un premier temps au VPN de l'EPFL.