Dopo una riconnessione WebSocket tramite proxy, ripristina anche la sessione
Ripristina deliberatamente le sottoscrizioni dell'applicazione e lo stato incerto dei messaggi dopo aver stabilito una nuova connessione WebSocket tramite proxy.
Il callback di riconnessione viene eseguito e il nuovo socket si apre. Questa è una ripresa del trasporto. Non significa necessariamente che le tue sottoscrizioni, le conferme dei messaggi o la sessione dell'applicazione siano proseguite da dove si era fermata la connessione precedente.
Anche lo stesso endpoint proxy può produrre una nuova connessione in uscita. Un IP in uscita cambiato può anche attivare la policy di sessione propria della destinazione. Tratta il nuovo socket come una nuova connessione e segui lo scambio di ripristino documentato dall'applicazione. Decidi se il flusso di lavoro debba conservare la propria rotta proxy durante la riconnessione.
Conserva un po' più dell'ultimo URL
Lo stato di ripristino utile può includere un'identità di sessione autorizzata, le sottoscrizioni desiderate, l'identificativo dell'ultimo evento confermato e le operazioni ancora in attesa di conferma. Quei campi appartengono al protocollo dell'applicazione; WebSocket non definisce un token di ripresa universale.
Decidi se riprendere da un cursore, ottenere un nuovo snapshot o accettare un vuoto. Se una sorgente di eventi non offre un'interfaccia di riproduzione, una riconnessione più rapida non può dimostrare che nessun messaggio sia andato perso.
Inviare due volte può significare eseguire due volte
Un messaggio messo in coda localmente prima di una disconnessione potrebbe non aver mai lasciato il client. Un altro potrebbe aver raggiunto il server mentre la sua conferma andava persa. Reinviare alla cieca ogni comando non confermato tratta quei due casi come identici.
Usa gli identificatori di richiesta del servizio, il supporto all'idempotenza o un meccanismo di riconciliazione quando disponibili. Una riconnessione del trasporto non può rendere reversibile un'azione dell'applicazione né deduplicarla automaticamente.
Mantieni i tentativi di riconnessione limitati e cadenzati secondo la policy dell'applicazione. La RFC 6455 consiglia un arretramento dopo una chiusura anomala; una flotta di client che ritenta subito può aumentare il carico del disservizio.
Registra quale rotta proxy ha scelto ogni tentativo, ma tieni il ripristino della rotta separato dal ripristino dell'applicazione. «Riconnessi» è una prova utile. «Recuperato il ritardo e pronti a inviare altro lavoro» richiede lo scambio applicativo aggiuntivo che lo stabilisce.