Живият TCP сокет, отговарящият WebSocket партньор и полезният напредък на приложението са различни наблюдения:

ДоказателствоКакво установява
Жизненост на TCP нивоПровереният транспортен път отговаря на това ниво
Съответстващ WebSocket PongПартньорът отговори на този контролен кадър
Потвърждение от приложениетоПриложението потвърди операция по собствения си протокол

Предно прокси обикновено поддържа отделни връзки към клиента и към дестинацията. TCP партньор на клиента е проксито, докато Ping вътре в установен тунел пътува до крайната точка на WebSocket.

Съответстващ Pong

Протоколът изисква отговарящият Pong да носи данните на приложението от Ping. Използвайте това съответствие, за да разпознаете висяща проверка. Непоискан Pong е позволен, но не изисква потвърждение; изпращането му след всяко съобщение с данни дава различни доказателства.

Предпочитайте поддържания от библиотеката механизъм за сърдечен ритъм. JavaScript в браузъра се нуждае вместо това от договор за сърдечен ритъм на ниво приложение. Избирайте интервали и прагове за отказ според натоварването и мрежовата политика. Паузи в планирането или претоварен цикъл на събития могат да пропуснат агресивен праг, без да установят мрежов отказ.

Поддържайте приемника работещ

Клиентът се нуждае от непрекъснат вход-изход, за да получава и обработва контролни кадри. Блокирането на този механизъм може да представи локален глад като прекъсване.

Ping създава тунелен трафик, но всеки посредник решава какво удовлетворява неговата политика за бездействие. Никой сърдечен ритъм не гарантира защита от абсолютен лимит за времетраене на връзката.

Партньорът може да отговаря на Ping, докато приложението му спре да произвежда обновления, а тих абонамент може да е здрав. Проследявайте последния валиден Pong и значимото събитие на приложението поотделно, когато и двете са важни. При отказ запазете маршрута, изминалите времена и висящата проверка, след което затворете или възстановете чрез поддържания жизнен цикъл.

Подобни статии