Os latexos de WebSocket no navegador necesitan un protocolo de aplicación
Deseñe un latexo de aplicación acordado cando o JavaScript do navegador non pode enviar directamente marcos WebSocket Ping.
A API WebSocket do navegador ten send(). Non expón un método ping() xeral para que JavaScript envíe marcos Ping do protocolo.
Se a súa aplicación envía unha mensaxe de texto como {"type":"heartbeat"}, iso son datos de aplicación. O servidor debe entender a mensaxe e definir unha resposta. Un servidor que non implementa ese contrato non está obrigado a responder cun Pong do protocolo só porque o texto conteña a palabra ping.
Defina que significa un acuse de recepción, como identifica o latexo pendente e cando un acuse antigo chega demasiado tarde. Mantéñao separado do acuse dunha operación de negocio.
Un temporizador de JavaScript tamén ten restricións de planificación. As pestanas en segundo plano e os fíos principais ocupados poden atrasar as devolucións de chamada. Non interprete un límite exacto de temporizador perdido como proba concluínte de que o proxy deixou de reenviar.
O navegador pode xestionar internamente os marcos de control do protocolo, pero iso non lle dá ao código da aplicación unha visión portátil de cada Ping ou Pong. Se a páxina necesita a súa propia decisión de vitalidade, use un contrato de aplicación explícito e unha política de recuperación.
Un socket cuxo readyState é OPEN considérase aberto localmente; non é unha medición independente de que a aplicación remota procesase a súa última mensaxe. Use a evidencia que corresponda á pregunta que realmente necesita responder.