След повторно свързване през прокси на WebSocket възстановете и сесията
Възстановете абонаментите на приложението и несигурното състояние на съобщенията съзнателно, след като установите нова WebSocket връзка през прокси.
Обратното извикване за повторно свързване се изпълнява и новият сокет се отваря. Това е възстановяване на транспорта. То не означава непременно, че абонаментите ви, потвържденията на съобщенията или сесията на приложението са продължили оттам, където предишната връзка е спряла.
Дори същата крайна точка на прокси може да създаде нова изходяща връзка. Промененият изходен IP също може да задейства собствената политика за сесии на дестинацията. Третирайте новия сокет като нова връзка и следвайте документирания обмен за възстановяване на приложението. Решете дали работният поток трябва да запази маршрута си през прокси при повторно свързване.
Запазете малко повече от последния URL
Полезното състояние за възстановяване може да включва оторизирана идентичност на сесията, желаните абонаменти, идентификатора на последното потвърдено събитие и операции, които все още чакат потвърждение. Тези полета принадлежат на протокола на приложението; WebSocket не дефинира универсален токен за продължаване.
Решете дали да продължите от курсор, да получите нова моментна снимка или да приемете празнина. Ако източникът на събития не предлага интерфейс за повторно възпроизвеждане, по-бързото повторно свързване не може да докаже, че не са пропуснати съобщения.
Изпращането два пъти може да означава извършване два пъти
Съобщение, поставено на опашка локално преди прекъсване, може никога да не е напуснало клиента. Друго може да е стигнало до сървъра, докато потвърждението му е било загубено. Сляпото повторно изпращане на всяка непотвърдена команда третира тези два случая като еднакви.
Използвайте идентификаторите на заявките на услугата, поддръжката за идемпотентност или механизъм за съгласуване, където са налични. Повторното свързване на транспорта не може да направи действие на приложението обратимо или автоматично да премахне дублирането му.
Поддържайте опитите за повторно свързване ограничени и с темпо според политиката на приложението. RFC 6455 препоръчва отстъпване след ненормално затваряне; множество клиенти, които опитват веднага, могат да увеличат натоварването по време на прекъсването.
Записвайте кой маршрут през прокси е избрал всеки опит, но дръжте възстановяването на маршрута отделно от възстановяването на приложението. „Свързахме се отново“ е полезно доказателство. „Наваксахме и сме готови да подадем още работа“ изисква допълнителния обмен на приложението, който го установява.