Depois de reconectar um WebSocket através de proxy, restaure também a sessão
Restaure deliberadamente as subscrições da aplicação e o estado incerto das mensagens depois de estabelecer uma nova ligação WebSocket através de proxy.
O callback de reconexão é executado e o novo socket abre. Isso é recuperação do transporte. Não significa necessariamente que as suas subscrições, confirmações de mensagens ou sessão da aplicação tenham continuado onde a ligação anterior parou.
Mesmo o mesmo ponto final de proxy pode produzir uma nova ligação de saída. Um IP de saída alterado também pode acionar a política de sessão própria do destino. Trate o novo socket como uma nova ligação e siga a troca de recuperação documentada da aplicação. Decida se o fluxo de trabalho deve manter a sua rota de proxy ao reconectar.
Guarde um pouco mais do que o último URL
Um estado de recuperação útil pode incluir uma identidade de sessão autorizada, as subscrições desejadas, o identificador do último evento confirmado e operações ainda à espera de confirmação. Esses campos pertencem ao protocolo da aplicação; o WebSocket não define um token de retoma universal.
Decida se retoma a partir de um cursor, obtém um novo instantâneo ou aceita uma lacuna. Se uma fonte de eventos não oferecer interface de reprodução, reconectar mais depressa não pode provar que nenhuma mensagem se perdeu.
Enviar duas vezes pode significar fazer duas vezes
Uma mensagem colocada localmente em fila antes de uma desconexão pode nunca ter saído do cliente. Outra pode ter chegado ao servidor enquanto a sua confirmação se perdia. Reenviar às cegas cada comando não confirmado trata esses dois casos como idênticos.
Use os identificadores de pedido do serviço, o suporte a idempotência ou o mecanismo de reconciliação onde estiverem disponíveis. Uma reconexão do transporte não pode tornar uma ação da aplicação reversível nem remover automaticamente a sua duplicação.
Mantenha as tentativas de reconexão limitadas e com um ritmo conforme a política da aplicação. A RFC 6455 recomenda recuar após um fecho anormal; uma frota de clientes a tentar imediatamente pode aumentar a carga da falha.
Registe que rota de proxy cada tentativa escolheu, mas mantenha a recuperação da rota separada da recuperação da aplicação. «Reconectados» é uma evidência útil. «Recuperados e prontos para enviar mais trabalho» exige a troca adicional da aplicação que o estabelece.