Etape 11 – Communication réseau

Comme cela a été expliqué dans l'introduction au projet, la mise en œuvre du jeu XBlast est séparée en deux programmes distincts :

• le serveur, qui fait évoluer l'état du jeu en fonction des règles et des événements reçus des clients, et le transmet périodiquement aux clients,
• le client, qui affiche à l'écran l'état reçu du serveur et détecte la pression des touches correspondant aux différentes actions, qu'il transmet au serveur.

Dans une partie comportant n joueurs, un total de 1 + n programmes s'exécutent : un serveur, et n clients. Chaque joueur humain dispose d'un ordinateur sur lequel il exécute une copie du client, tandis que le serveur s'exécute soit sur un des ordinateurs des joueurs, soit sur un ordinateur séparé.

La communication entre le serveur et les clients est découpée en deux phases distinctes :

1. dans un premier temps, les clients envoient périodiquement au serveur un message l'informant de leur intention de se joindre à la partie ; le serveur accepte chaque nouveau client jusqu'à ce qu'il y en ait le nombre requis — généralement 4,
2. dans un deuxième temps, la partie commence, et à partir de cet instant, le serveur envoie périodiquement le nouvel état à chaque client, et chaque client lui transmet les actions de son joueur.

Ces deux phases de communication et les différents messages échangés par un serveur s et deux clients c₁ et c₂ au début d'une partie sont illustrés dans la figure 1. Le temps s'y écoule de gauche à droite, et les messages échangés sont représentés par des flèches allant de l'expéditeur du message à son destinataire. Les types de messages sont identifiés par les couleurs des flèches et les étiquettes attachées, qui ont la signification suivante :

• J désigne un message envoyé par un client au serveur pour lui communiquer son intention de se joindre à la partie,
• p,s_i désigne un message envoyé par le serveur à un client pour lui communiquer son identité p et l'état de la partie au coup d'horloge i,
• N (resp. S) désigne un message envoyé par un client au serveur l'informant que le joueur désire se diriger vers le nord (resp. sud),
• B désigne un message envoyé par un client au serveur l'informant que le joueur désire déposer une bombe.

Tous les messages transmis par les clients au serveur ne contiennent qu'un octet, qui spécifie l'action que le client désire effectuer. Cet octet n'est rien d'autre que l'index de l'action en question dans l'énumération PlayerAction définie lors de l'étape précédente (0 pour JOIN_GAME, noté J ci-dessus, 1 pour MOVE_N, etc.).

Les messages transmis par le serveur sont constitués de :

• un octet donnant l'identité du joueur auquel le message est destiné (0 pour le premier joueur, 1 pour le second, etc.),
• une séquence d'octets de taille variable représentant l'état du jeu sérialisé de la manière décrite à l'étape 8.

La communication entre le serveur et les clients se fait via Internet. 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 ce cours. 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, et/ou lire le livre Java Network Programming, très complet et disponible en ligne.

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 2.

Comme nous le verrons plus loin, le protocole du jeu, désigné par XBlast dans cette figure, est basé sur le protocole UDP de la couche inférieure. Beaucoup de protocoles connus — p.ex. HTTP qui est le protocole du Web, ou SMTP et IMAP qui sont liés au courrier électronique — sont quant à eux basés sur un autre protocole de la couche inférieure, TCP.

La classe ByteBuffer du paquetage java.nio représente une mémoire tampon (ou simplement tampon) d'octets, c-à-d un tableau d'octets de taille fixe. Par rapport à un tableau Java, un tel tampon est doté d'attributs supplémentaires permettant un accès séquentiel à son contenu. Des instances de cette classe sont utilisées par la classe Channel et ses sous-classes — décrites plus bas — pour représenter les paquets transmis à travers le réseau.

Les principaux attributs que ByteBuffer possède en plus d'un tableau Java normal sont :

• une position (position), qui donne la position du prochain élément à lire ou à écrire dans le tampon,
• une limite (limit), qui donne la position du premier élément qui ne doit pas être lu ou écrit.

Ces deux attributs, bien décrits dans la documentation de la classe Buffer, permettent à une instance de ByteBuffer de se comporter un peu comme un flot, aux éléments duquel on accède de manière séquentielle. Etant donné que certaines méthodes de ByteBuffer permettent également d'accéder à ces éléments de manière aléatoire — c-à-d au moyen d'un index — un tel tampon peut être vu comme une combinaison entre un tableau et un flot.

Les méthodes de la classe ByteBuffer qui sont utiles à cette étape et dont le fonctionnement doit donc être bien compris sont :

• allocate, qui permet la création d'un tampon d'une capacité (taille) donnée,
• put (variante relative), qui permet l'écriture d'un octet à la position courante du tampon, qui est mise à jour en fonction,
• put (variante absolue), qui permet l'écriture d'un octet à une position donnée,
• flip, qui met la limite du tampon à la position actuelle, et réinitialise cette dernière à 0 ; cela permet de préparer pour la lecture un tampon dans lequel des données ont été écrites,
• rewind, qui « rembobine » le tampon, en mettant à 0 sa position,
• remaining, qui retourne le nombre d'octets restants dans le tampon, c-à-d la différence entre la limite et la position,
• hasRemaining, qui retourne vrai si et seulement si il reste au moins un octet dans le tampon,
• clear, qui met à 0 la position du tampon, et sa limite à sa capacité.

L'extrait de code ci-dessous montre comment créer un tampon d'une capacité de 100 éléments, y insérer les octets de 0 à 9 aux dix premières positions au moyen d'écritures relatives, remplacer le premier élément par 50 au moyen d'une écriture absolue, puis finalement afficher ces éléments.

ByteBuffer b = ByteBuffer.allocate(100);
for (int i = 0; i < 10; ++i)
  b.put((byte)i);               // écriture relative
b.put(0, (byte)50);             // écriture absolue
b.flip();
while (b.hasRemaining())
  System.out.println(b.get());  // 50, 1, 2, …, 9

La classe InetSocketAddress du paquetage java.net, immuable, représente une paire (adresse IP, numéro de port). Pour cette étape, seuls deux constructeurs de la classe InetSocketAddress sont nécessaires :

• le premier construisant une adresse en fonction d'un nom d'hôte et d'un numéro de port,
• le second construisant une adresse en fonction d'un numéro de port uniquement.

Les adresses obtenues au moyen du second constructeur ne possédant qu'un numéro de port, elles ne sont utilisables que comme argument à la méthode bind d'un canal, décrite ci-dessous. En d'autres termes, elles ne sont utilisables que dans le code du serveur, qui désire recevoir des données, et pas dans le code du client, qui désire envoyer des données et doit donc forcément spécifier l'hôte auquel les envoyer.

L'utilisation de ces deux constructeurs est illustrée dans les extraits de code de la section ci-après.

La classe DatagramChannel du paquetage java.nio.channels représente un canal de communication UDP. Le concept de canal est propre à la nouvelle version de la bibliothèque d'entrées/sorties Java (paquetage java.nio), et sert d'équivalent aux flots d'entrée/sortie de l'ancienne version. Toutefois, l'interface des canaux est très différente de celle des flots.

Les canaux de type DatagramChannel sont toujours bidirectionnels, et permettent donc à la fois la réception et l'envoi de données. Un canal peut être configuré pour être soit bloquant (son état par défaut), soit non bloquant. Lorsqu'il est bloquant, ses méthodes d'envoi (send) et de réception (receive) bloquent en attendant que les données soient effectivement envoyées ou reçues.

Les méthodes de la classe DatagramChannel qui sont utiles à cette étape et dont le fonctionnement doit donc être bien compris sont :

• open, qui permet de créer un canal UDP,
• close, qui permet de fermer le canal et libérer les resources système qui lui sont associées,
• bind, qui permet de lier le canal à un port UDP,
• configureBlocking, qui permet de rendre le canal bloquant ou non,
• send, qui permet d'envoyer un paquet UDP sur le canal,
• receive, qui permet de recevoir un paquet UDP du canal.

L'extrait de programme suivant montre comment utiliser un tel canal pour envoyer un paquet UDP constitué d'un seul octet valant 4 sur le port UDP 2016 de l'hôte local, c-à-d l'ordinateur sur lequel s'exécute le programme.

DatagramChannel channel =
  DatagramChannel.open(StandardProtocolFamily.INET);
SocketAddress address =
  new InetSocketAddress("localhost", 2016);

ByteBuffer buffer = ByteBuffer.allocate(1);
buffer.put((byte)4);
buffer.flip();

channel.send(buffer, address);

L'extrait de programme suivant montre quant à lui comment utiliser un tel canal pour attendre l'arrivée d'un paquet UDP sur le port 2016 et afficher son contenu à l'écran.

DatagramChannel channel =
  DatagramChannel.open(StandardProtocolFamily.INET);
channel.bind(new InetSocketAddress(2016));

ByteBuffer buffer = ByteBuffer.allocate(1);
SocketAddress senderAddress = channel.receive(buffer);

System.out.printf("Reçu l'octet %d de %s%n",
                  buffer.get(0),
                  senderAddress);

En plaçant ces deux extraits chacun dans un programme séparé et en lançant d'abord le second, puis le premier, le second devrait afficher à l'écran un message ressemblant à ceci, mais avec un numéro de port différent de 65347 :

Reçu l'octet 4 de /127.0.0.1:65347

Ces deux extraits de programme représentent respectivement un embryon de client et un embryon de serveur, et constituent donc un bon point de départ pour vous.

La classe Main du paquetage ch.epfl.xblast.server est la classe principale du serveur. Elle n'offre rien d'autre qu'une méthode main acceptant les arguments du serveur sous la forme d'un tableau de chaînes de caractères, comme d'habitude.

Le serveur prend un seul argument, optionnel, qui donne le nombre de clients qui doivent se connecter avant que la partie ne démarre. Si cet argument n'est pas spécifié, il vaut 4 par défaut.

A noter que cet argument ne détermine pas le nombre de joueurs présents sur le plateau, qui vaut toujours 4, mais uniquement le nombre de clients qui doivent se connecter avant que la partie ne démarre. Lorsque ce nombre de clients est inférieur à 4, les joueurs auquel aucun client ne correspond sont simplement inertes. Ce comportement est utile pour le test, puisqu'en spécifiant qu'un seul client est nécessaire au démarrage de la partie, il est possible de lancer à la fois le client et le serveur sur le même ordinateur puis de contrôler le premier joueur via le clavier.

Si vous ne savez pas ou plus comment passer des arguments à un programme exécuté depuis Eclipse, vous pouvez consulter notre petit guide à ce sujet.

Le serveur attend les messages de la part des clients sur le port UDP 2016, comme l'embryon ci-dessus.

La classe Main du paquetage ch.epfl.xblast.client est la classe principale du client. Elle n'offre rien d'autre qu'une méthode main acceptant les arguments du client sous la forme d'un tableau de chaînes de caractères, comme d'habitude.

Le client prend un seul argument, optionnel, qui donne le nom de l'hôte sur lequel se trouve le serveur. Si cet argument n'est pas spécifié, il vaut localhost par défaut.

A noter que cet argument peut simplement être passé au constructeur de la classe InetSocketAddress et que cette dernière accepte à la fois les chaînes représentant un nom d'hôte — p.ex. localhost — que celles représentant une adresse IPv4 — p.ex. 127.0.0.1.

Pour tester votre client et votre serveur sur une seule machine, vous pouvez lancer tout d'abord le serveur, en lui passant 1 en argument afin qu'il n'attende la connexion que d'un client, puis le client. Pour passer 1 en argument au serveur, suivez les indications de notre guide Eclipse sur les configurations d'exécution.

En plus de ces tests locaux, il est fortement conseillé d'essayer d'utiliser votre client avec le serveur d'un autre groupe, et inversément. Cela vous permettra de vous assurer que vous avez bien respecté le protocole et le format de sérialisation de l'état spécifiés dans les étapes précédentes.

Pour jouer une partie avec plusieurs joueurs utilisant des ordinateurs séparés, il faut tout d'abord déterminer l'adresse IP de l'ordinateur sur laquelle 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 ipinfo. En cliquant sur ce lien, vous verrez s'afficher l'adresse IP de votre ordinateur, que vous pouvez communiquer oralement aux autres joueurs, pour peu bien entendu que ce soit l'ordinateur exécutant le serveur.

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.