Robustheit: WebSocket-Reconnect-Strategie pruefen #73

New issue

Closed

opened 2026-05-16 23:42:21 +00:00 by jreinemann-euris · 0 comments

jreinemann-euris commented

2026-05-16 23:42:21 +00:00

(Migrated from github.com)

Bestandsaufnahme

Der WebSocket-Client (WebSocketClientImpl) verbindet sich zum Server für Real-Time-Sync-Events. Es ist unklar, wie robust die Reconnect-Strategie bei Verbindungsabbrüchen ist.

Szenarien mit potenziellem Problem

Netzwerkwechsel (WLAN → Mobilfunk): Verbindung bricht ab, Client muss reconnecten
Server-Neustart (Deployment, Crash): Alle WebSocket-Verbindungen gehen verloren
Intermittierende Konnektivität (Tunnel, Aufzug): Häufige kurze Unterbrechungen
Server nicht erreichbar (DNS-Fehler, Firewall): Reconnect-Versuche laufen ins Leere

Risiken ohne robuste Strategie

Aggressive Reconnects könnten den Server mit Verbindungsversuchen fluten
Kein Reconnect → Client bekommt keine Sync-Events mehr, Daten veralten still
Batterieverbrauch bei ständigen Reconnect-Versuchen auf Mobilgeräten

Zu klären

Gibt es aktuell einen Reconnect-Mechanismus? Wenn ja, mit welcher Strategie?
Exponentieller Backoff vorhanden?
Maximale Retry-Anzahl / Give-up-Logik?
Wird der User informiert, wenn die Verbindung dauerhaft fehlschlägt?

## Bestandsaufnahme Der WebSocket-Client (`WebSocketClientImpl`) verbindet sich zum Server für Real-Time-Sync-Events. Es ist unklar, wie robust die Reconnect-Strategie bei Verbindungsabbrüchen ist. ### Szenarien mit potenziellem Problem - **Netzwerkwechsel** (WLAN → Mobilfunk): Verbindung bricht ab, Client muss reconnecten - **Server-Neustart** (Deployment, Crash): Alle WebSocket-Verbindungen gehen verloren - **Intermittierende Konnektivität** (Tunnel, Aufzug): Häufige kurze Unterbrechungen - **Server nicht erreichbar** (DNS-Fehler, Firewall): Reconnect-Versuche laufen ins Leere ### Risiken ohne robuste Strategie - Aggressive Reconnects könnten den Server mit Verbindungsversuchen fluten - Kein Reconnect → Client bekommt keine Sync-Events mehr, Daten veralten still - Batterieverbrauch bei ständigen Reconnect-Versuchen auf Mobilgeräten ### Zu klären - Gibt es aktuell einen Reconnect-Mechanismus? Wenn ja, mit welcher Strategie? - Exponentieller Backoff vorhanden? - Maximale Retry-Anzahl / Give-up-Logik? - Wird der User informiert, wenn die Verbindung dauerhaft fehlschlägt?

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: bollwerkadmin/bollwerk#73

No description provided.