Discussion :

[mormic]

Bonjour à tous et une bien bonne nouvelle année.

Ma question relève plus du dévelopement Web mais si quelqu'un sur ce forum a une idée?
Dans mon application domotique dont le serveur est un ESP32:

Un client(PC ou portable) envoi une demande au serveur pour basculer un relais sur une carte distante.
Le serveur accuse réception de la requète et envoi la commande à la carte distante.
La carte distante exécute la commande et en accuse réception en confirmant le nouvel état du relais(On ou Off).


Ma question: comment faire remonter au client l'information sur l'état du relais:
Puis-je retarder l'envoi du 'ack' en lui envoyant Ok21O venant de la carte distante sans risquer un 'timeout'?

[Jay M]

Le timeout moyen des navigateurs web varie, mais il est généralement compris entre 30 et 60 secondes. Ce délai peut dépendre du navigateur et de la configuration du serveur, bien que la plupart des navigateurs suivent une plage similaire. Certains navigateurs, comme Chrome ou Firefox, peuvent ajuster ce délai en fonction des conditions réseau ou de la configuration utilisateur.

Donc si le cycle requête / réponse de la carte distante dure moins de 30 secondes, vous pouvez différer la réponse à la requête web initiale et attendre simplement l'ACK. bien sûr ce n'est plus asynchrone.

Sinon en mode web traditionnel, une fois que vous avez envoyé la réponse et fermé le canal de la requête, le serveur web ne peut pas de lui même re contacter le client. Donc il faudrait que le serveur renvoie d'abord un ACK disant "requête bien reçue, reviens voir bientôt si elle a été traitée correctement" et ensuite le client va demander "où en est ma requête" tous les ∆t pour mettre à jour sa page (avec AJAX par exemple).

une autre option est d'utiliser une websockets. Il existe aussi le Server-Sent Event qui permet au serveur d'envoyer des mises à jour de manière unidirectionnelle vers le client via une connexion HTTP persistante. Ce mécanisme est particulièrement adapté pour des flux de données en temps réel comme des notifications ou des mises à jour régulières. Cependant, contrairement aux WebSockets, il ne permet pas de communication bidirectionnelle.

Autre option : l’utilisation de long polling, où le client envoie une requête au serveur, et le serveur la maintient ouverte (c'est plus lourd que SSE ou WebSockets mais le long polling peut être utile dans des environnements où ces technologies ne sont pas disponibles).

Vous pouvez utiliser 'en-tête HTTP "Keep-Alive" qui permet de signaler au navigateur que le serveur souhaite maintenir la connexion ouverte après une réponse, au lieu de la fermer immédiatement après l'échange. Lorsqu'un serveur envoie cet en-tête avec une valeur, par exemple `Connection: Keep-Alive`, il indique au navigateur que la connexion peut être réutilisée pour plusieurs requêtes, ce qui évite la nécessité d'établir une nouvelle connexion pour chaque requête successive. Dans le cas de long polling, cela permet au serveur de maintenir la connexion ouverte pendant une période prolongée sans qu'elle soit fermée par le navigateur ou le serveur, à condition que le serveur continue de répondre périodiquement, même avec des données minimales ou de simples "pings", pour éviter un timeout.


le plus simple c'est Requête, réponse et la page web qui ensuite revient demander un update tous les ∆t jusqu'à ce qu'il y ait ACK ou NACK.

[mormic]

si le cycle requête / réponse de la carte distante dure moins de 30 secondes, vous pouvez différer la réponse à la requête web initiale et attendre simplement l'ACK

La réponse arrive au serveur en moins de deux secondes, ce qui lui permet d'avoir grandement le temps d'envoyer son 'ack' avec la réponse de la carte distante. Je vais modifier les dialogues en ce sens.

Je pensais que c'était plus court.

Merci Jay M pour ce tour d'horizon des possibilités répondant à mon problème.