Els batecs de WebSocket al navegador necessiten un protocol d'aplicació
Dissenyu un batec d'aplicació acordat quan el JavaScript del navegador no pot enviar directament marcs Ping de WebSocket.
L'API WebSocket del navegador té send(). No exposa un mètode ping() general perquè el JavaScript enviï marcs Ping del protocol.
Si la vostra aplicació envia un missatge de text com {"type":"heartbeat"}, això són dades d'aplicació. El servidor ha d'entendre el missatge i definir una resposta. Un servidor que no implementa aquest contracte no té l'obligació de respondre amb un Pong del protocol només perquè el text contingui la paraula ping.
Definiu què significa un reconeixement, com identifica el batec pendent i quan un reconeixement antic arriba massa tard. Manteniu-ho separat del reconeixement d'una operació de negoci.
Un temporitzador de JavaScript també té restriccions de planificació. Les pestanyes en segon pla i els fils principals ocupats poden endarrerir les crides. No interpreteu un límit exacte de temporitzador incomplert com a prova concloent que el proxy ha deixat de reenviar.
El navegador pot gestionar internament els marcs de control del protocol, però això no dona al codi de l'aplicació una visió portable de cada Ping o Pong. Si la pàgina necessita la seva pròpia decisió de vitalitat, feu servir un contracte d'aplicació explícit i una política de recuperació.
Un sòcol el readyState del qual és OPEN es considera obert localment; no és una mesura independent que l'aplicació remota hagi processat el vostre darrer missatge. Feu servir l'evidència que correspon a la pregunta que realment heu de respondre.