Nach einem Abbruch zurückkommen

Der Server übersteht jetzt einen langsamen Zuschauer und trennt einen toten. Diese Lektion schaut auf das andere Ende der Verbindung: das Programm des Zuschauers, nachdem seine Verbindung weg ist. Vielleicht wurde es von Keepalive getrennt, nachdem sein Netzwerk eine Weile weg war, wie in Lektion 4. Vielleicht wurde der Server neu gestartet und hat jede Verbindung mit 1001 geschlossen. Oder das Netzwerk zwischen ihnen ist auf eine der Arten ausgefallen, die Networks with Python aufgezählt hat: ein Reset, ein Timeout, eine Route, die verschwunden ist. In jedem Fall muss sich ein Zuschauer, der weiter Punktestände zeigen will, erneut verbinden.

Der naheliegende Weg ist, es sofort noch einmal zu versuchen, und wieder, wenn das scheitert, so schnell das Programm kann. Das richtet Schaden an. Wenn ein Server neu startet, verliert jeder seiner Zuschauer im selben Moment seine Verbindung, und wenn alle sofort neu versuchen, kommt der Server zurück zu einer Flut von Handshakes, die ihn wieder umwerfen kann. Ein Client, der den Server nicht erreicht, verbraucht beim Versuchen außerdem seinen eigenen Akku und sein Netzwerk.

Das Warten verdoppeln, bis zu einer Obergrenze, mit Jitter

Die übliche Antwort hat drei Teile. Warte vor jedem neuen Versuch und verdopple das Warten nach jedem Fehlschlag: eine halbe Sekunde, dann eine, dann zwei. Hör an einer Obergrenze auf zu verdoppeln, damit ein langer Ausfall einen Client nicht eine Stunde warten lässt, wenn der Server längst zurück ist. Und warte nicht genau so lange: Wähle eine zufällige Zeit zwischen null und der Decke, was man Jitter nennt. Zwei Clients, die den Server im selben Moment verloren haben, wählen dann verschiedene Zeiten und verteilen sich. RFC 6455 selbst empfiehlt das, in Abschnitt 7.2.3: Nach einem abnormalen Schließen SOLLTE ein Client seinen ersten Versuch um eine zufällige Zeitspanne verzögern und dann zurückweichen, wobei er die Verzögerung bis zu einer Grenze verdoppelt.

Das Programm unten berechnet den Zeitplan eines Clients. Ein echter Client nimmt seinen Jitter aus einer Zufallsquelle; hier vertritt ihn eine feste Liste von Zahlen zwischen 0 und 1, damit das Programm jedes Mal dieselben Zeilen ausgibt, so wie Python in der Praxis die Zeit hineingereicht hat, statt die Uhr zu lesen. Führe es aus:

Es gibt sechs Zeilen aus, von attempt 1: wait up to 0.5 s, this time 0.31 s bis attempt 6: wait up to 8.0 s, this time 2.64 s. Die Decke verdoppelt sich von 0,5 auf 8,0 und bleibt dann an der Obergrenze. Die Wartezeiten springen darunter hin und her: Versuch 4 wartet 1,6 s, obwohl seine Decke 4,0 beträgt. In einem echten Client wäre jede Wartezeit ein Schlafen, gefolgt von einem neuen connect; eine erfolgreiche Verbindung setzt die Versuchszählung auf 1 zurück.

print(0.5 * 2 ** 4, round(8.0 * 0.97, 2))

Neu synchronisieren braucht keine Vorgeschichte

Sobald der Zuschauer wieder verbunden ist, hat er jede Wertung verpasst, die passiert ist, während er weg war. Er muss nicht nach ihnen fragen. Die erste Nachricht des Servers an jeden Zuschauer ist der Beitritts-Snapshot, die ganze Tafel, also bringt eine einzige Nachricht einen zurückkehrenden Zuschauer auf den neuesten Stand.

Der Zuschauer braucht eine Regel dazu: Er behält die Version des letzten Snapshots, den er gezeigt hat, und ignoriert jeden Snapshot, dessen Version nicht neuer ist. Ein Snapshot mit derselben Version würde nur dieselbe Tafel noch einmal zeigen, und ein älterer würde die Punktestände zurücklaufen lassen. Das kann passieren, wenn ein Client kurz zwei Verbindungen hält oder eine verspätete Nachricht von der Verbindung liest, die er gerade verlässt. Das Programm unten wendet die Regel auf vier Snapshots an, die ankommen, nachdem der Zuschauer Version 4 gezeigt hat:

Es gibt version 3: ignored, version 5: shown, version 5: ignored und version 6: shown aus.

Wo das hingehört

Die Regel für veraltete Snapshots ist Teil des Vertrags der Anzeigetafel, und der Client des Abschlussprojekts wendet sie an. Eine vollständige Wiederverbindungsschleife, mit ihrem Schlafen, ihren connect-Aufrufen und ihrer Zufallsquelle, sollst du wiedererkennen, und dieser Kurs baut sie nicht: Sobald du die drei Teile kennst, kannst du eine solche Schleife in der Dokumentation jeder Client-Bibliothek lesen und prüfen, dass sie verdoppelt, begrenzt und Jitter verwendet.

Lektion 6 beweist Anzeigetafel v2 mit eigenen Tests und führt sie mit einem gebremsten und einem toten Zuschauer aus.