Mais tout d'abords, une petite description de l'environnement. On part du principe que chaque interface de jeu, programmée par exemple en Flash, se connecte à un serveur de jeu et que ce dernier se contente de véhiculer les actions des joueurs sur toutes les interfaces connéctées. Je clique, mon interface interprète le clique comme une demande de type "je veux avancer", et fait donc avancer mon joueur. Ensuite, pour que les autres participants voient aussi mon joueur avancer, mon interface envoie au serveur le message "le joueur untel (c'est moi) avance". Le serveur communique cette information aux autres joueurs et tout le monde me voit avancer. Jusque là, tout va bien.

Revenons maintenant sur la fin de cette course. Elle était sérrée. Tellement sérrée, à vrai dire, que mon collègue et moi nous sommes retrouvés tous les deux, à un moment, à un clique de la victoire. Autrement dit: à ce moment-là, c'était celui qui cliquait le premier qui devait gagner. Et... on a cliqué "en même temps". Enfin... disons, suffisament "en même temps". Que s'est t'il passé ensuite ? Mon interface a detecté mon clique et a fait avancer mon joueur vers la victoire. Nos cliques étaient pratiquement simultanés, mais l'autre joueur étant sur le réseau, son clique à lui a mis plus de temps pour arriver, via le serveur de jeu, à mon interface, et cette dernière m'a donc déclaré vainqueur. De son coté, mon collègue a assisté au même comportement, mais en sa faveur. Son clique a été perçu par son interface avant le mien, qui arrivé par le réseau, et son interface l'a donc déclaré, lui, vainqueur.

Une solution consiste à centraliser les decisions sur le serveur, ce dernier contenant alors une représentation du jeu. Je clique, l'information est communiquée au serveur. Le serveur fait évoluer sa représentation du jeu en fonction du clique, et communique le nouvel état du jeu à tous les joueurs (y compris moi) et alors seulement, mon interface est mise à jour pour ce clique. Maintenant, c'est plus celui qui clique le premier qui gagne, mais celui dont l'information "j'ai cliqué" arrive la première au serveur. Et comme le serveur est le seul à décider de l'état du jeu, tout le monde voit le jeu dans le même état. L'inconvénient majeur c'est qu'il faut donc faire en sorte que le serveur soit un minimum au courant du jeu et de ses règles: il faut maintenant développer le jeu coté Flash, mais aussi coté serveur. Ce dernier ne peut plus se contenter de relayer les informations. On peut cependant s'en sortir en restant sur un jeu complètement développé en Flash... À condition de bien faire attention à l'odre des opérations. On va pour ça utiliser une propriété des connexions TCP.

Il existe de nombreux protocols de communications sur les réseaux. Celui utilisé actuellement pour l'Internet est le protocol IP. Sans rentrer dans les détails, on remarquera cependant que le protocole TCP, construit sur le protocol IP, fonctionne en mode dit "connecté". C'est à dire, entre autres, que deux informations envoyées l'une à la suite de l'autre sur une connexion TCP arrivent dans l'ordre dans lequel elles ont été émises . Ce qui n'est pas forcément le cas avec d'autres protocoles. Losrque des informations sont véhiculées sur Internet, elles sont découpées en paquets, et chaque paquet est envoyé au destinataire. Ces paquets, selon l'état du réseau, peuvent emprunter des chemins différents... ou se perdre. Carrément. Le protocole UDP se contente de faire suivre ces paquets... tant qu'ils existent. Et ne se soucie pas de leur ordre d'arrivé. Le protocole TPC intègre quant à lui un mécanisme qui permet de conserver l'intégrité d'un message qui a été découpé en plusieurs paquets. Et ça, pour la cohérence, ça aide.

Revenons maintenant à notre jeu. En Flash, on peut établir une connexion via un objet qui s'appelle XMLSocket. Une connexion établie avec cet objet véhicule ses données en utilisant le protocole TCP. C'est à dire, donc, que deux informations envoyées à la suite via cette connexion arriveront dans l'ordre dans lequel elles ont été émises. Comme pour la version avec le jeu développé en partie sur le serveur, on va utiliser ce dernier comme un repère, qui s'appliquera à toutes les interfaces. Mais plus besoin ici de développer une représentation du jeu sur le serveur, qui servira juste à relayer les informations. Il s'agit juste, donc, de faire attention à l'ordre des opérations.

Lorsqu'un clique est détécté sur mon interface, mon interface n'en tient pas compte. Pas tout de suite. Elle commence par l'envoyer au serveur. Le serveur reçoit l'information et la communique à toutes les interfaces, y compris la mienne. Et c'est seulement lorsque mon interface reçoit l'information du serveur qu'elle interprète mon clique comme une demande de type "j'avance". Et mon joueur avance. Si on reprend la fin de la course avec ce mode de fonctionnement, qu'est ce que ça donne ? On est donc tous les deux à un clique du but, et on clique "en même temps". Les deux informations "j'avance" sont reçues, quoi qu'il en soit, l'une après l'autre sur le serveur. La première reçue est diffusée avant l'autre. Sur toutes les connexions. Et comme on est sur des connexions TCP, elles ne peuvent pas se doubler en route. Donc on reçoit tous les deux ces informations dans le même ordre.

... Donc si je gagne, je pourrais faire le kakou pour du vrai