Les battements de cœur WebSocket dans le navigateur exigent un protocole applicatif
Concevez un battement de cœur applicatif convenu lorsque le JavaScript du navigateur ne peut pas envoyer directement des trames WebSocket Ping.
L'API WebSocket du navigateur dispose de send(). Elle n'expose pas de méthode ping() générale permettant au JavaScript d'envoyer des trames Ping du protocole.
Si votre application envoie un message texte comme {"type":"heartbeat"}, il s'agit de données applicatives. Le serveur doit comprendre le message et définir une réponse. Un serveur qui n'implémente pas ce contrat n'est pas tenu de répondre par un Pong du protocole simplement parce que le texte contient le mot ping.
Définissez ce que signifie un acquittement, comment il identifie le battement en attente et à partir de quand un acquittement ancien arrive trop tard. Gardez-le distinct de l'acquittement d'une opération métier.
Une minuterie JavaScript a aussi des contraintes d'ordonnancement. Les onglets en arrière-plan et les threads principaux occupés peuvent retarder les rappels. N'interprétez pas une limite de minuterie précise manquée comme la preuve décisive que le proxy a cessé de relayer.
Le navigateur peut traiter en interne les trames de contrôle du protocole, mais cela ne donne pas au code applicatif une vue portable de chaque Ping ou Pong. Si la page a besoin de sa propre décision de vivacité, utilisez un contrat applicatif explicite et une politique de reprise.
Un socket dont readyState vaut OPEN est considéré comme ouvert localement ; ce n'est pas une mesure indépendante du fait que l'application distante a traité votre dernier message. Utilisez les preuves correspondant à la question à laquelle vous devez réellement répondre.