Bicia serca WebSocket w przeglądarce wymagają protokołu aplikacji
Zaprojektuj uzgodnione bicie serca aplikacji, gdy JavaScript w przeglądarce nie może bezpośrednio wysyłać ramek WebSocket Ping.
API WebSocket w przeglądarce udostępnia send(). Nie oferuje ogólnej metody ping(), którą JavaScript mógłby wysyłać ramki Ping protokołu.
Jeśli Twoja aplikacja wysyła wiadomość tekstową na przykład {"type":"heartbeat"}, są to dane aplikacji. Serwer musi zrozumieć wiadomość i zdefiniować odpowiedź. Serwer, który nie realizuje tego kontraktu, nie ma obowiązku odpowiadać ramką Pong protokołu tylko dlatego, że tekst zawiera słowo ping.
Zdefiniuj, co oznacza potwierdzenie, jak identyfikuje oczekujące bicie serca i kiedy stare potwierdzenie jest zbyt późne. Trzymaj to oddzielnie od potwierdzenia operacji biznesowej.
Timer JavaScriptu ma również ograniczenia planowania. Karty w tle i zajęte wątki główne mogą opóźniać wywołania zwrotne. Nie interpretuj przekroczonej dokładnej granicy timera jako rozstrzygającego dowodu, że proxy przestało przekazywać dane.
Przeglądarka może wewnętrznie obsługiwać ramki sterujące protokołu, ale nie daje to kodowi aplikacji przenośnego widoku każdego Ping lub Pong. Jeśli strona potrzebuje własnej decyzji o żywotności, użyj jawnego kontraktu aplikacji i polityki odzyskiwania.
Gniazdo, którego readyState ma wartość OPEN, jest lokalnie uznawane za otwarte; nie jest to niezależny pomiar tego, że zdalna aplikacja przetworzyła Twoją ostatnią wiadomość. Używaj dowodów odpowiadających pytaniu, na które naprawdę musisz odpowiedzieć.