WebSocket-hjarteslag i nettlesaren krev ein applikasjonsprotokoll
Lag eit avtalt applikasjonshjarteslag når JavaScript i nettlesaren ikkje kan senda WebSocket Ping-rammer direkte.
WebSocket-API-et i nettlesaren har send(). Det tilbyr ikkje ein generell ping()-metode som JavaScript kan bruka til å senda Ping-rammer i protokollen.
Viss applikasjonen din sender ei tekstmelding som {"type":"heartbeat"}, er det applikasjonsdata. Tenaren må forstå meldinga og definera eit svar. Ein tenar som ikkje implementerer denne kontrakten, er ikkje pliktig til å svara med ein protokoll-Pong berre fordi teksten inneheld ordet ping.
Definer kva ei stadfesting tyder, korleis ho identifiserer hjarteslaget som ventar, og når ei gammal stadfesting er for sein. Hald dette skilt frå stadfesting av ein forretningsoperasjon.
Ein JavaScript-timer har òg planleggingsgrenser. Bakgrunnsfaner og travle hovudtrådar kan forseinka tilbakekall. Ikkje tolk ei mista nøyaktig timergrense som avgjerande prov på at proxyen slutta å vidaresenda.
Nettlesaren kan handsama kontrollrammer i protokollen internt, men det gir ikkje applikasjonskoden eit flyttbart bilete av kvar Ping eller Pong. Viss sida treng si eiga levedyktigheitsavgjerd, bruk ein uttrykkeleg applikasjonskontrakt og ein gjenopprettingspolicy.
Ein sokkel der readyState er OPEN blir lokalt rekna som open; det er ikkje ei uavhengig måling av at fjernapplikasjonen har handsama den siste meldinga di. Bruk prova som passar til spørsmålet du faktisk må svara på.