Discussion :

[mormic]

Bonjour à tous
J'ai créé un serveur Web sur un ESP32 et j'établi bien la communication avec le client (ma page HTML sur mon PC).
Mais la requête client est une demande d'état d'un périphérique de l'ESP32.
Donc l'ESP32 doit questionner ce périphérique et envoyer l'état au client.
Ma question: comment faire pour transmettre simplement une information du serveur vers le client (sans une requête préalable)?
Est-ce possible sans passer par webSocket?

[Jay M]

Ma question: comment faire pour transmettre simplement une information du serveur vers le client (sans une requête préalable)?
Est-ce possible sans passer par webSocket?

le principe général de HTTP c'est que c'est le client (navigateur web) qui effectue la requête, une réponse est alors générée et la connexion est close. Le Serveur HTTP n'a aucune connaissance a priori des clients possibles (pour un serveur sur internet, ce serait l'ensemble des ordinateurs ayant accès à Internet dans le monde...)

Quand vous dites "sans une requête préalable" comment envisagez vous cela? il faut quand même que le serveur ait l'adresse IP du client d'une façon ou d'une autre et éventuellement du port auquel il doit s'adresser pour atteindre le service d'affichage (le navigateur). Si c'est le serveur qui contacte le client, en fait vous avez inversé les rôles...

Si une première connexion est envisageable ensuite le HTML généré peut inclure un timer qui fait que tant que la page web est affichée sur le navigateur, tous les ∆t (toutes les secondes par exemple) une requête de mise à jour des données est envoyée au serveur. Avec des techniques comme AJAX par exemple ça peut ne pas se voir (pas de rafraîchissement complet de la page, juste des éléments modifiés)

Les webSocket c'est une autre approche. Un serveur WebSocket est un protocole de communication bidirectionnelle mais l'initiation est toujours à la charge du client

- Le client établit une connexion WebSocket en envoyant une demande d'ouverture de connexion au serveur via un handshake HTTP initial.
- Une fois la connexion WebSocket établie, les données peuvent être envoyées dans les deux sens sans nécessiter de nouvelles requêtes HTTP.
- Le serveur et le client peuvent s'envoyer des messages sous forme de trames WebSocket, ce qui permet une communication en temps réel.

Comme les connexions WebSocket restent ouvertes ça permet une latence réduite et une communication efficace entre le client et le serveur.


Dans les 2 cas donc c'est le client qui initie la transaction

[mormic]

Merci Jay M. pour ces explications.
Dans un premier temps je vais tacher d'opter pour la première solution: le client demande l'état d'un périphérique de l'ESP32, puis après accusé réception par le serveur, envoi des requêtes pour connaître la réponse (n fois).
Par contre, y a-t'il un moyen pour le serveur de savoir quand le client se déconnecte?

[Jay M]

Par contre, y a-t'il un moyen pour le serveur de savoir quand le client se déconnecte?

Si vous faites du web de base, le client se déconnecte après chaque requête.

Un moyen de détecter la fermeture du navigateur est d'utiliser des événements JavaScript côté client, tels que l'événement "beforeunload" ou "unload" pour envoyer une notification au serveur avant que la page ne se ferme. Cependant, cela ne garantit pas que la notification sera envoyée en cas de fermeture inattendue du navigateur, par exemple, en cas de panne de l'ordinateur.

Une autre solution est le heartbeat : vous pouvez envisager d'implémenter un mécanisme de ping-pong. Le client envoie périodiquement des pings au serveur, et le serveur répond par des pongs. Si le serveur ne reçoit pas de ping dans un délai donné après une première connexion , il peut considérer le client comme déconnecté et si le client ne reçoit pas le pong il peut considérer qu’il y a un soucis réseau ou que le serveur a planté


Pourquoi avez vous besoin de savoir que le client est parti?

[mormic]

Merci pour ces riches explications que je vais utiliser prestement.
Cordialement