Nach einem erneuten WebSocket-Verbindungsaufbau über einen Proxy auch die Sitzung wiederherstellen

Der Rückruf für den erneuten Verbindungsaufbau läuft, und der neue Socket öffnet sich. Das ist die Wiederherstellung des Transports. Es bedeutet nicht zwangsläufig, dass deine Abonnements, Nachrichtenbestätigungen oder die Applikationssitzung dort fortgesetzt wurden, wo die vorherige Verbindung endete.

Selbst derselbe Proxy-Endpunkt kann eine neue ausgehende Verbindung erzeugen. Eine geänderte Ausgangs-IP kann zudem die eigene Sitzungsrichtlinie des Ziels auslösen. Behandle den neuen Socket als neue Verbindung und folge dem dokumentierten Wiederherstellungsaustausch der Applikation. Entscheide, ob der Workflow seine Proxy-Route beibehalten soll, wenn er sich neu verbindet.

Behalte etwas mehr als die letzte URL

Nützlicher Wiederherstellungszustand kann eine autorisierte Sitzungsidentität, gewünschte Abonnements, die Kennung des zuletzt bestätigten Ereignisses und Vorgänge umfassen, die noch auf Bestätigung warten. Diese Felder gehören zum Applikationsprotokoll; WebSocket definiert kein allgemeines Fortsetzungs-Token.

Entscheide, ob du von einem Cursor aus fortsetzt, einen neuen Schnappschuss holst oder eine Lücke akzeptierst. Bietet eine Ereignisquelle keine Schnittstelle zum erneuten Abspielen, kann ein schnellerer Neuaufbau nicht beweisen, dass keine Nachrichten verloren gingen.

Zweimal senden kann zweimal ausführen bedeuten

Eine Nachricht, die vor einer Trennung lokal eingereiht wurde, hat den Client möglicherweise nie verlassen. Eine andere kann den Server erreicht haben, während ihre Bestätigung verloren ging. Jeden unbestätigten Befehl blind erneut zu senden, behandelt beide Fälle als gleich.

Nutze die Anfragekennungen des Dienstes, Idempotenz-Unterstützung oder einen Abgleichmechanismus, wo sie verfügbar sind. Ein Transport-Neuaufbau kann eine Applikationsaktion weder umkehrbar machen noch sie automatisch entdoppeln.

Halte Neuversuche begrenzt und passe das Tempo an die Richtlinie der Applikation an. RFC 6455 empfiehlt ein Zurückweichen nach ungewöhnlichem Schließen; eine Flotte von Clients, die sofort erneut versucht, kann die Last des Ausfalls erhöhen.

Protokolliere, welche Proxy-Route jeder Versuch gewählt hat, aber halte die Routen-Wiederherstellung getrennt von der Applikations-Wiederherstellung. „Wieder verbunden“ ist ein nützlicher Beleg. „Aufgeholt und bereit, weitere Arbeit einzureichen“ braucht den zusätzlichen Applikationsaustausch, der das feststellt.