J'ai apprécié la lecture de l'article. Le ton léger sans trop en faire permet d'absorber plus facilement des concepts un peu rébarbatifs.
Cependant, je pense qu'il gagnerait en qualité s'il était un peu plus clair sur certains points. Voici quelques remarques et questions, qui ne sont que constructives, car je sais à quel point il est difficile d'écrire un texte de cette taille. Il s'agit du point de vue de quelqu'un qui n'y connaît pas grand chose en dév Web, mais c'est le public concerné je crois.
On crée un objet XMLHttpRequest, on lui indique l’URL de la page à télécharger
Qui ? Le client ?
Pour en recevoir, on lance une requête de longue durée, et on reçoit les messages du serveur au fur et à mesure (...) 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 ?
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.
Ce serait quand même bien d’avoir un mécanisme de communication dans les deux sens sur le web, sans se payer le coup des requêtes HTTP,
- Navigateur : Salut, une petite WebSocket, ça te dit ?
- Serveur : Ouais ouais, carrément !
- ... et c’est parti pour un échange bidirectionnel endiablé
Là encore, je ne vois pas la différence avec du HTTP. Avec le HTTP, on a aussi un échange bidirectionnel : le client envoie des données au serveur, et le serveur envoie des données au client.
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. En fait, on peut faire un vrai "push" ici : pour recevoir des données du serveurs, on ne contente pas d'attendre le retour de requêtes envoyées au serveur. 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.
C'est plutôt bien expliqué sur la page Wikipedia :
This is made possible by providing a standardized way for the server to send content to the client without being first requested by the client
La page https://websocket.org/quantum.html donnée en référence explique aussi les méthodes historiques (polling, long-polling, streaming).
# Besoin de quelques éclaircissements
Posté par tbartolone . En réponse à la dépêche Communiquer avec le serveur depuis un navigateur Web : XHR, SSE et WebSockets. Évalué à 2.
Hello
J'ai apprécié la lecture de l'article. Le ton léger sans trop en faire permet d'absorber plus facilement des concepts un peu rébarbatifs.
Cependant, je pense qu'il gagnerait en qualité s'il était un peu plus clair sur certains points. Voici quelques remarques et questions, qui ne sont que constructives, car je sais à quel point il est difficile d'écrire un texte de cette taille. Il s'agit du point de vue de quelqu'un qui n'y connaît pas grand chose en dév Web, mais c'est le public concerné je crois.
Qui ? Le client ?
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 ?
C'est un peu exactement la même chose, je ne vois pas la différence.
Elle réside peut-être là :
Mais je ne comprends pas du tout pourquoi.
Là encore, je ne vois pas la différence avec du HTTP. Avec le HTTP, on a aussi un échange bidirectionnel : le client envoie des données au serveur, et le serveur envoie des données au client.
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. En fait, on peut faire un vrai "push" ici : pour recevoir des données du serveurs, on ne contente pas d'attendre le retour de requêtes envoyées au serveur. 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.
C'est plutôt bien expliqué sur la page Wikipedia :
La page https://websocket.org/quantum.html donnée en référence explique aussi les méthodes historiques (polling, long-polling, streaming).
Merci