WebSocket-Heartbeats im Browser brauchen ein Anwendungsprotokoll
Entwerfen Sie einen vereinbarten Anwendungs-Heartbeat, wenn Browser-JavaScript keine WebSocket-Ping-Frames direkt senden kann.
Die WebSocket-API des Browsers bietet send(). Sie stellt keine allgemeine Methode ping() bereit, mit der JavaScript Ping-Frames des Protokolls senden könnte.
Wenn Ihre Anwendung eine Textnachricht wie {"type":"heartbeat"} sendet, sind das Anwendungsdaten. Der Server muss die Nachricht verstehen und eine Antwort definieren. Ein Server, der diesen Vertrag nicht umsetzt, ist nicht verpflichtet, mit einem Protokoll-Pong zu antworten, nur weil der Text das Wort ping enthält.
Legen Sie fest, was eine Bestätigung bedeutet, wie sie den ausstehenden Heartbeat identifiziert und wann eine alte Bestätigung zu spät kommt. Halten Sie das getrennt von der Bestätigung eines Geschäftsvorgangs.
Auch ein JavaScript-Timer unterliegt Planungsbeschränkungen. Hintergrund-Tabs und ausgelastete Hauptthreads können Rückrufe verzögern. Deuten Sie eine verpasste exakte Timergrenze nicht als schlüssigen Beweis dafür, dass der Proxy aufgehört hat weiterzuleiten.
Der Browser kann Steuerframes des Protokolls intern verarbeiten, doch das gibt Anwendungscode keine portable Sicht auf jedes Ping oder Pong. Braucht die Seite eine eigene Lebendigkeitsentscheidung, nutzen Sie einen ausdrücklichen Anwendungsvertrag und eine Wiederherstellungsrichtlinie.
Ein Socket, dessen readyState OPEN ist, gilt lokal als offen; das ist keine unabhängige Messung dafür, dass die entfernte Anwendung Ihre letzte Nachricht verarbeitet hat. Nutzen Sie die Belege, die zur Frage passen, die Sie tatsächlich beantworten müssen.