После переподключения проксированного WebSocket восстановите и сессию
После установки нового WebSocket-соединения через прокси осознанно восстановите подписки приложения и неопределённое состояние сообщений.
Обратный вызов переподключения выполняется, и новый сокет открывается. Это восстановление транспорта. Оно не обязательно означает, что ваши подписки, подтверждения сообщений или сессия приложения продолжились с того места, где остановилось предыдущее соединение.
Даже та же конечная точка прокси может создать новое исходящее соединение. Изменённый исходящий IP также может запустить собственную политику сессии пункта назначения. Относитесь к новому сокету как к новому соединению и следуйте документированному обмену восстановления приложения. Решите, должна ли рабочая последовательность сохранять свой прокси-маршрут при переподключении.
Храните чуть больше, чем последний URL
Полезное состояние восстановления может включать авторизованную идентичность сессии, желаемые подписки, идентификатор последнего подтверждённого события и операции, всё ещё ожидающие подтверждения. Эти поля относятся к протоколу приложения; WebSocket не определяет универсальный токен продолжения.
Решите, продолжать ли с курсора, получить новый снимок состояния или принять разрыв. Если источник событий не предлагает интерфейс воспроизведения, более быстрое переподключение не может доказать, что ни одно сообщение не было потеряно.
Отправка дважды может означать выполнение дважды
Сообщение, поставленное в локальную очередь до отключения, могло так и не покинуть клиент. Другое могло дойти до сервера, пока его подтверждение терялось. Слепая повторная отправка каждой неподтверждённой команды рассматривает эти два случая как одинаковые.
Используйте идентификаторы запросов сервиса, поддержку идемпотентности или механизм сверки, где они доступны. Переподключение транспорта не может сделать действие приложения обратимым или автоматически устранить его дублирование.
Держите попытки переподключения ограниченными и согласуйте темп с политикой приложения. RFC 6455 рекомендует отступать после аномального закрытия; множество клиентов, повторяющих попытку сразу, может увеличить нагрузку во время сбоя.
Записывайте, какой прокси-маршрут выбрала каждая попытка, но держите восстановление маршрута отдельно от восстановления приложения. «Снова подключено» — полезное свидетельство. «Догнали и готовы отправить больше работы» требует дополнительного обмена приложения, который это устанавливает.