Re: Besoin de quelques éclaircissements

On crée un objet XMLHttpRequest, on lui indique l’URL de la page à télécharger

Qui ? Le client ?

Yep. XMLHttpRequest est une classe qu'on ne trouve que dans les navigateurs web (habituellement en tout cas !).

Par contre, il faut se payer la gestion de la séparation des messages. Rien ne garantit qu’on va recevoir chaque message en un coup. Il « suffit » donc d’utiliser un séparateur (par exemple un ou deux retours à la ligne).
Un gars plutôt réseau comme moi ne comprend pas pourquoi il faut séparer les messages. On reçoit les messages au fur et à mesure, donc des paquets de données (plus précisément des PDU de niveau 7). C'est le paquet qui sépare les messages non ?

Ici on est à un plus haut niveau : un « message » pour moi est un objet JSON complet (par exemple). Ou un texte dont la taille est connue en avance. Ou un texte qui se finit par une nouvelle ligne. Il peut être composé de un ou plusieurs paquets TCP, et plusieurs messages peuvent être envoyés en même temps par le serveur, et il peut même y avoir un paquet TCP qui contient la fin d'un message et le début du suivant.

La fonction onreadystatechange de l'objet XMLHttpRequest peut être appelée n'importe quand, quand le navigateur le décide. Mettons que le serveur envoie deux « messages » en même temps. Il peut y avoir du buffering, on peut recevoir une partie du premier, puis sa fin et tout le deuxième message en entier, ou recevoir le tout en trois fois... Bref, il faut analyser le flux au fil de l'eau et trouver les messages dedans. Je ne sais pas si c'est plus clair dit comme ça.

Ce qu'il faudrait expliciter vraiment (si j'ai bien compris), c'est que une fois le socket "ouvert", le serveur peut être à l'initiative d'un message vers le client, ce qui est normalement réservé au client

Le serveur peut de lui même initier des requêtes vers le client. Je suppose que cela sous-entend une prise en charge particulière dans les proxies et NAT.

Alors, non. Le serveur peut envoyer des messages sur une connexion WebSockets établie, demandée par le client. C'est une connexion TCP classique établie, le NAT n'est pas un problème. Le proxy, si c'est un proxy TCP, non, si c'est un proxy HTTP oui, il faut qu'il comprenne les WebSockets.

Là encore, je ne vois pas la différence avec du HTTP.

La différence, c'est la connexion établie. HTTP c'est : une requête, une réponse et on coupe la connexion. Les WebSockets laissent une connexion TCP ouverte, par laquelle le client et le serveur peuvent envoyer des données à tout moment.

Et du coup :

Sans les WebSockets :
Une requête HTTP est envoyée pour avertir le serveur.
Le serveur répond OK à la requête, puis,
transmet le déplacement à tous les joueurs, y compris celui qui a joué, par simplicité. Ce déplacement est reçu par le joueur via la requête de longue durée.

Avec les WebSockets :
Le joueur envoie le coup par la WebSocket
Le serveur répond ok dans la WebSocket
Le serveur envoie le déplacement à tous les joueurs, dont à ce joueur à travers cette même WebSocket.

C'est un peu exactement la même chose, je ne vois pas la différence.

Elle réside peut-être là :

Sauf que dans la vraie vie, le déplacement peut être reçu avant la réponse OK par le joueur.

Mais je ne comprends pas du tout pourquoi.

Sans WebSocket, vu que la requête et la connexion long polling son dans deux connexions différentes (sur différents ports - ou dans une seule connexion HTTP2 mais multiplexée, donc je pense que c'est le même problème), il n'y a pas de garantie d'ordre d'arrivée des messages.

le client envoie la requête, le serveur la traite, envoie la réponse au client, et envoie un message sur l'autre connexion correspondant à cette requête, on peut recevoir la réponse et le message dans les deux sens.

Avec un WebSocket, les messages seront bien ordonnés puisque tout passe dans le même tuyau et que TCP garantie l'ordre : la réponse à la requête arrive toujours avant le message, par exemple.

J'espère que ça répond aux interrogations :-)