Wie wir Netzwerkunterbrechungen elegant handhaben

Wenn Sie jemals ein Remote-Tool benutzt haben, das nach einem kurzen Netzwerkausfall einen Spinner anzeigt und sich nie wieder erholt, verstehen Sie, warum wir von Reconnection-Zuverlässigkeit besessen sind. In der Welt mobiler Entwicklungstools sind Netzwerkunterbrechungen keine Grenzfälle — sie sind der Normalfall. Smartphones wechseln zwischen Wi-Fi und Mobilfunk. Aufzüge blockieren Signale. Café-Netzwerke sind von Natur aus unzuverlässig.

TacticRemotes Reconnection-Engine ist um ein Prinzip herum entworfen: Netzwerkunterbrechungen sollten für den Benutzer wann immer möglich unsichtbar sein, und elegant kommuniziert werden, wenn sie es nicht sein können.

Die Zustandsmaschine

Im Kern unserer Reconnection-Logik steht eine endliche Zustandsmaschine mit sechs Zuständen:

┌──────────┐     connect     ┌───────────┐
│ INITIAL  │───────────────►│ CONNECTED │◄─────────────┐
└──────────┘                 └─────┬─────┘              │
                                   │                    │
                              disconnect           reconnect
                                   │              success │
                              ┌────▼─────┐              │
                              │ UNSTABLE │──── retry ───►│
                              └────┬─────┘    (1-3s)    │
                                   │                    │
                              3 failures           ┌────┴─────┐
                                   │               │RECOVERING│
                              ┌────▼─────┐        └────┬─────┘
                              │RECONNECT │── retry ────►│
                              │  ING     │  (5-30s)     │
                              └────┬─────┘              │
                                   │                    │
                              timeout (5min)            │
                                   │                    │
                              ┌────▼─────┐              │
                              │DISCONNEC │─── manual ───┘
                              │  TED     │   reconnect
                              └──────────┘

CONNECTED: Normaler Betrieb. Daten fließen frei.

UNSTABLE: Ein Verbindungsversuch schlug fehl, aber wir vermuten, es ist vorübergehend. Wiederholungen erfolgen in 1-3-Sekunden-Intervallen. Die UI zeigt einen dezenten Warnindikator, unterbricht aber den Benutzer nicht.

RECONNECTING: Mehrere Fehler deuten auf ein echtes Problem hin. Wiederholungsintervalle steigen exponentiell (5s, 10s, 20s, Obergrenze 30s). Die UI zeigt ein deutliches „Verbindung wird wiederhergestellt"-Banner.

RECOVERING: Verbindung wiederhergestellt, aber Zustandssynchronisation notwendig. Der Client fordert ein State-Delta vom Server an, wendet es an und wechselt nach abgeschlossener Abgleichung zu CONNECTED.

DISCONNECTED: Das Wiederholungs-Timeout (Standard: 5 Minuten) wurde überschritten. Der Benutzer muss die Wiederverbindung manuell auslösen. Dies verhindert endlosen Batterieverbrauch bei tatsächlich offline befindlichen Geräten.

Das Abgleichsprotokoll

Wiederverbindung ist einfach. Der Abgleich — Client und Server wieder in Einklang zu bringen — ist der schwierige Teil.

Wenn das iPhone nach einer Unterbrechung die Verbindung wiederherstellt, sendet es dem Server seinen letzten bekannten Zustandsvektor: die Sequenznummer des letzten verarbeiteten Terminal-Updates, die Session-ID und einen Zeitstempel. Der Server berechnet daraus exakt, was dem Client fehlt.

Szenario 1: Kurze Unterbrechung (< 30 Sekunden). Der Ausgabepuffer des Servers enthält noch alle verpassten Updates. Er spielt sie der Reihe nach ab, und der Client wendet sie sequenziell an. Aus Benutzerperspektive „holt das Terminal auf" in unter einer Sekunde — ein kurzer Scroll-Burst, während die verpasste Ausgabe erscheint.

Szenario 2: Mittlere Unterbrechung (30 Sekunden - 5 Minuten). Der Ausgabepuffer könnte teilweise rotiert sein. Der Server sendet eine teilweise Wiedergabe gefolgt von einem vollständigen Terminal-Snapshot. Der Client wendet die Wiedergabe an und validiert dann gegen den Snapshot, um Konsistenz sicherzustellen.

Szenario 3: Lange Unterbrechung (> 5 Minuten). Der Server sendet nur einen vollständigen Snapshot. Der Client ersetzt seinen gesamten Zustand. Dies ist der am wenigsten effiziente Pfad, garantiert aber Korrektheit unabhängig davon, wie viel verpasst wurde.

type ReconciliationResponse = {
  method: 'replay' | 'replay_and_snapshot' | 'snapshot'
  replay?: TerminalUpdate[]
  snapshot?: TerminalSnapshot
  sessions: SessionState[]
  pendingApprovals: ApprovalRequest[]
}

Beachten Sie, dass die Abgleichsantwort auch pendingApprovals enthält. Wenn Claude Code während der Offline-Phase des Smartphones eine Genehmigung angefordert hat, wird diese Anfrage als Teil der Wiederverbindung zugestellt. Dies ist entscheidend — ohne dies würde Claude Code auf eine Genehmigung warten, die der Benutzer nie gesehen hat.

Grenzfälle, die uns fast gebrochen hätten

Die Unterbrechung während der Genehmigung

Ein Benutzer erhält eine Genehmigungsbenachrichtigung, tippt auf „Genehmigen" und verliert die Verbindung, bevor die Genehmigung den Server erreicht. Wird die Aktion ausgeführt?

Unsere Lösung: Genehmigungen verwenden ein Bestätigungsprotokoll. Der Server führt die genehmigte Aktion erst aus, wenn er die Genehmigungsnachricht des Clients empfängt UND den Empfang dem Client bestätigt. Wenn die Verbindung während der Genehmigung abbricht, wird die Genehmigung bei Wiederverbindung erneut übertragen. Doppelte Genehmigungen sind idempotent — „Anfrage #47 genehmigen" zweimal zu senden hat den gleichen Effekt wie einmal.

Der Fall: Sitzung während Offline beendet

Ihre Claude Code-Aufgabe wird abgeschlossen, während Ihr Telefon offline ist. Bei der Wiederverbindung befindet sich die Sitzung im beendeten Zustand. Soll der Client die finale Ausgabe zeigen? Die Abschlussbenachrichtigung? Beides?

Wir handhaben dies, indem wir einen sessionEndState in die Abgleichsantwort aufnehmen. Der Client rendert den finalen Terminalzustand und zeigt ein „Aufgabe während Offline abgeschlossen"-Banner mit einer Zusammenfassung des Geschehenen. Der Benutzer sieht das Ergebnis sofort, statt auf veraltete In-Progress-Ausgabe zu starren.

Der Fall: Mac wurde neu gestartet

Das herausforderndste Szenario: Ihr Mac startet neu, während das Telefon offline ist (wegen eines Systemupdates, Stromausfalls oder Absturzes). Wenn das Telefon sich wiederverbindet, hat der Server keine Erinnerung an vorherige Sitzungen.

Unsere Lösung: Die Mac-Companion-App persistiert Sitzungsmetadaten (Sitzungs-IDs, Projektpfade, letzte bekannte Zustände) auf der Festplatte. Nach dem Neustart liest sie diese Metadaten und verbindet sich, wo möglich, mit überlebenden tmux-Sitzungen. Das Abgleichsprotokoll erkennt den Server-Neustart über einen Server-Epoch-Counter und initiiert eine vollständige Zustandsrekonstruktion statt eines inkrementellen Abgleichs.

Leistungsmerkmale

Wir messen die Reconnection-Leistung anhand dreier Metriken:

Zeit bis zur visuellen Wiederherstellung — wie lange von der Netzwerkwiederherstellung bis der Benutzer den aktuellen Terminalzustand sieht. Unser P95 liegt bei 1,8 Sekunden für lokales Netzwerk und 3,2 Sekunden für Cloudflare Tunnel.

Dateneffizienz — wie viele Daten während des Abgleichs im Vergleich zu einer vollständigen Aktualisierung übertragen werden. Bei Unterbrechungen unter 60 Sekunden überträgt unser Abgleichsprotokoll 85% weniger Daten als eine vollständige Aktualisierung.

Korrektheit — Null-Toleranz für Zustandsinkonsistenzen. Wir führen kontinuierliche Integrationstests durch, die tausende Trennungs-/Wiederverbindungszyklen mit zufälligem Timing simulieren und verifizieren, dass der finale Client-Zustand byte-genau mit dem Server-Zustand übereinstimmt.

Lehren für Entwickler

Wenn Sie irgendeine Art von Echtzeit-Mobilanwendung entwickeln, legen unsere Erfahrungen drei Prinzipien nahe:

1. Entwerfen Sie von Tag eins für Verbindungsabbrüche. Reconnection zu einem System hinzuzufügen, das für ständige Konnektivität entworfen wurde, ist um Größenordnungen schwieriger als intermittierende Konnektivität als erstklassiges Anliegen zu behandeln.

2. Idempotenz ist Ihr bester Freund. Jede Client-zu-Server-Nachricht sollte sicher wiederholbar sein. Diese einzige Eigenschaft eliminiert ganze Kategorien von Reconnection-Bugs.

3. Testen Sie mit echten Netzwerken, nicht mit Simulatoren. Netzwerkzustandssimulatoren können nicht die gesamte Vielfalt realer Ausfälle reproduzieren — teilweise Paketlieferung, DNS-Auflösungsverzögerungen, TLS-Handshake-Timeouts. Wir testen in echten Mobilfunknetzen, in Aufzügen und in überlasteten Konferenz-WLANs.

Zuverlässige Wiederverbindung ist keine glamouröse Arbeit. Benutzer loben sie nicht, wenn sie funktioniert — sie bemerken Unterbrechungen einfach nicht. Aber wenn sie versagt, verdunstet Vertrauen sofort. Wir halten die Investition für lohnenswert, und die Bereitschaft unserer Benutzer, Tactic Remote für Produktionsworkflows zu nutzen, deutet darauf hin, dass sie zustimmen.