WebSocket-hartklopings in die blaaier het 'n toepassingsprotokol nodig
Ontwerp 'n ooreengekome toepassingshartklop wanneer blaaier-JavaScript nie WebSocket-pingraamwerk direk kan stuur nie.
Die blaaier se WebSocket-API het send(). Dit stel nie 'n algemene ping()-metode beskikbaar waarmee JavaScript protokolpingraamwerk kan stuur nie.
As jou toepassing 'n teksboodskap soos {"type":"heartbeat"} stuur, is dit toepassingsdata. Die bediener moet die boodskap verstaan en 'n antwoord definieer. 'n Bediener wat nie daardie kontrak implementeer nie, is nie verplig om met 'n protokol-Pong te antwoord net omdat die teks die woord ping bevat nie.
Definieer wat 'n bevestiging beteken, hoe dit die uitstaande hartklop identifiseer, en wanneer 'n ou bevestiging te laat is. Hou dit apart van die bevestiging van 'n besigheidsoperasie.
'n JavaScript-tydhouer het ook skeduleringsbeperkings. Agtergrond-oortjies en besige hoofdraaiings kan terugroepe vertraag. Moenie 'n gemiste presiese tydhouergrens as afdoende bewys beskou dat die proksi opgehou het om deur te stuur nie.
Die blaaier kan protokolbeheerraamwerk intern hanteer, maar dit gee nie toepassingskode 'n draagbare siening van elke Ping of Pong nie. As die bladsy sy eie lewensvatbaarheidsbesluit nodig het, gebruik 'n eksplisiete toepassingskontrak en 'n herstelbeleid.
'n Sok wat se readyState OPEN is, word plaaslik as oop beskou; dit is nie 'n onafhanklike meting dat die verre toepassing jou laaste boodskap verwerk het nie. Gebruik die bewyse wat pas by die vraag wat jy werklik moet beantwoord.