Після повторного підключення проксійованого WebSocket відновіть і сеанс
Свідомо відновіть підписки застосунку та невизначений стан повідомлень після встановлення нового з'єднання WebSocket через проксі.
Зворотний виклик повторного підключення виконується, і новий сокет відкривається. Це відновлення транспорту. Це не обов'язково означає, що ваші підписки, підтвердження повідомлень або сеанс застосунку продовжилися з того місця, де зупинилося попереднє з'єднання.
Навіть та сама кінцева точка проксі може створити нове вихідне з'єднання. Змінений вихідний IP також може запустити власну політику сеансів призначення. Ставтеся до нового сокета як до нового з'єднання й дотримуйтеся документованого обміну відновлення застосунку. Вирішіть, чи робочий процес має зберігати свій проксі-маршрут під час повторного підключення.
Зберігайте трохи більше, ніж останній URL
Корисний стан відновлення може включати авторизовану ідентичність сеансу, бажані підписки, ідентифікатор останньої підтвердженої події та операції, що все ще очікують підтвердження. Ці поля належать протоколу застосунку; WebSocket не визначає універсального токена продовження.
Вирішіть, чи продовжувати з курсора, отримати новий знімок стану або прийняти розрив. Якщо джерело подій не пропонує інтерфейсу відтворення, швидше повторне підключення не може довести, що жодне повідомлення не втрачено.
Надсилання двічі може означати виконання двічі
Повідомлення, поставлене в локальну чергу перед роз'єднанням, могло так і не залишити клієнт. Інше могло дійти до сервера, поки його підтвердження губилося. Сліпе повторне надсилання кожної непідтвердженої команди розглядає ці два випадки як однакові.
Використовуйте ідентифікатори запитів сервісу, підтримку ідемпотентності або механізм узгодження, де вони доступні. Повторне підключення транспорту не може зробити дію застосунку оборотною або автоматично прибрати її дублювання.
Тримайте спроби повторного підключення обмеженими й узгоджуйте темп із політикою застосунку. RFC 6455 радить відступати після аномального закриття; натовп клієнтів, що одразу повторюють спробу, може збільшити навантаження під час збою.
Записуйте, який проксі-маршрут обрала кожна спроба, але тримайте відновлення маршруту окремо від відновлення застосунку. «Знову підключено» — корисний доказ. «Наздогнали й готові надіслати більше роботи» потребує додаткового обміну застосунку, який це встановлює.