WebSocket отчукувањата во прелистувачот бараат апликациски протокол
Дизајнирајте договорено апликациско отчукување кога JavaScript во прелистувачот не може директно да испраќа WebSocket Ping рамки.
WebSocket API на прелистувачот има send(). Тој не изложува општ метод ping() со кој JavaScript би можел да испраќа Ping рамки на протоколот.
Ако вашата апликација испрати текстуална порака како {"type":"heartbeat"}, тоа се апликациски податоци. Серверот мора да ја разбере пораката и да дефинира одговор. Сервер што не го спроведува тој договор не е должен да одговори со протоколен Pong само затоа што текстот ја содржи зборот ping.
Дефинирајте што значи потврдата, како го идентификува отчукувањето што чека и кога старата потврда е премногу доцна. Држете го тоа одвоено од потврдата на деловна операција.
И тајмерот на JavaScript има ограничувања за закажување. Позадинските јазичиња и зафатените главни нишки можат да ги одложат повратните повици. Не толкувајте пропуштена точна граница на тајмерот како решавачки доказ дека проксито престанало да проследува.
Прелистувачот може внатрешно да ги обработува контролните рамки на протоколот, но тоа не му дава на апликацискиот код пренослив преглед на секој Ping или Pong. Ако на страницата ѝ треба сопствена одлука за живост, користете изречен апликациски договор и политика за обновување.
Приклучок чиј readyState е OPEN локално се смета за отворен; тоа не е независно мерење дека оддалечената апликација ја обработила вашата последна порака. Користете докази што одговараат на прашањето на кое навистина треба да одговорите.