Après une reconnexion WebSocket via proxy, restaurez aussi la session
Restaurez délibérément les abonnements de l'application et l'état incertain des messages après l'établissement d'une nouvelle connexion WebSocket via proxy.
Le rappel de reconnexion s'exécute et la nouvelle socket s'ouvre. C'est une récupération du transport. Cela ne signifie pas forcément que vos abonnements, vos accusés de réception de messages ou votre session applicative ont repris là où la connexion précédente s'était arrêtée.
Même le même point de terminaison proxy peut produire une nouvelle connexion sortante. Une IP de sortie changée peut aussi déclencher la propre politique de session de la destination. Traitez la nouvelle socket comme une nouvelle connexion et suivez l'échange de récupération documenté par l'application. Décidez si le flux de travail doit conserver sa route proxy lors de la reconnexion.
Gardez un peu plus que la dernière URL
Un état de récupération utile peut inclure une identité de session autorisée, les abonnements souhaités, l'identifiant du dernier événement confirmé et les opérations encore en attente d'accusé de réception. Ces champs relèvent du protocole applicatif ; WebSocket ne définit pas de jeton de reprise universel.
Décidez s'il faut reprendre depuis un curseur, obtenir un nouvel instantané ou accepter une lacune. Si une source d'événements n'offre pas d'interface de relecture, une reconnexion plus rapide ne peut pas prouver qu'aucun message n'a été manqué.
Envoyer deux fois peut signifier faire deux fois
Un message mis en file localement avant une déconnexion n'a peut-être jamais quitté le client. Un autre a peut-être atteint le serveur tandis que son accusé de réception était perdu. Renvoyer aveuglément chaque commande non confirmée traite ces deux cas comme identiques.
Utilisez les identifiants de requête du service, la prise en charge de l'idempotence ou un mécanisme de réconciliation lorsqu'ils sont disponibles. Une reconnexion du transport ne peut ni rendre réversible une action applicative ni la dédupliquer automatiquement.
Gardez les tentatives de reconnexion bornées et cadencées selon la politique de l'application. La RFC 6455 recommande un repli après une fermeture anormale ; une flotte de clients qui réessaient immédiatement peut accroître la charge de la panne.
Enregistrez la route proxy choisie par chaque tentative, mais gardez la récupération de route distincte de la récupération applicative. « Reconnecté » est une preuve utile. « Rattrapé et prêt à soumettre davantage de travail » exige l'échange applicatif supplémentaire qui l'établit.