Gli heartbeat WebSocket nel browser richiedono un protocollo applicativo
Progettate un heartbeat applicativo concordato quando il JavaScript del browser non può inviare direttamente frame WebSocket Ping.
L'API WebSocket del browser dispone di send(). Non espone un metodo ping() generico per consentire a JavaScript di inviare frame Ping del protocollo.
Se la vostra applicazione invia un messaggio di testo come {"type":"heartbeat"}, si tratta di dati applicativi. Il server deve comprendere il messaggio e definire una risposta. Un server che non implementa quel contratto non è tenuto a rispondere con un Pong del protocollo solo perché il testo contiene la parola ping.
Definite che cosa significa un riscontro, come identifica l'heartbeat in sospeso e quando un riscontro vecchio è troppo in ritardo. Tenetelo separato dal riscontro di un'operazione commerciale.
Anche un timer JavaScript ha vincoli di pianificazione. Le schede in background e i thread principali occupati possono ritardare le callback. Non interpretate un limite esatto del timer mancato come prova definitiva che il proxy ha smesso di inoltrare.
Il browser può gestire internamente i frame di controllo del protocollo, ma ciò non offre al codice applicativo una visione portabile di ogni Ping o Pong. Se la pagina necessita di una propria decisione di vitalità, usate un contratto applicativo esplicito e una politica di ripristino.
Un socket il cui readyState è OPEN è considerato aperto localmente; non è una misura indipendente del fatto che l'applicazione remota abbia elaborato il vostro ultimo messaggio. Usate le prove che corrispondono alla domanda a cui dovete davvero rispondere.