---
type: ADR
status: ACCEPTED
owner: Lead Architect
---

# ADR-0020: Lokale Netzwerk-Kommunikation und Daten-Isolierung

## Status

Akzeptiert (März 2026)

## Kontext

Die Desktop-Anwendung ("Meldestelle-Biest") muss in einer lokalen Netzwerkumgebung (LAN) auf Reitturnieren
funktionieren, oft ohne zuverlässige Internetverbindung. Dabei müssen verschiedene Instanzen der App (z.B. "
Meldestelle-Desk-App" und "Richter-Desk-App") in Echtzeit miteinander kommunizieren.

Herausforderungen:

1. Wie finden sich die Geräte automatisch im LAN?
2. Wie wird die Sicherheit der Datenübertragung ohne zentrale Cloud-Infrastruktur gewährleistet?
3. Wie können Daten zwischen verschiedenen Turnieren innerhalb einer Veranstaltung sauber isoliert werden, während ein
   veranstaltungsweiter Austausch (z.B. Chat) möglich bleibt?

## Entscheidung

Wir implementieren ein Peer-to-Peer (P2P) Kommunikationsmodell basierend auf folgenden Säulen:

1. **Discovery (Geräte finden):** Einsatz von `mDNS` (Multicast DNS / ZeroConf), damit sich Instanzen im lokalen
   Netzwerk ohne manuelle IP-Konfiguration finden können.
2. **Transport & Echtzeit:** Nutzung von verschlüsselten **WebSockets** für die bidirektionale Datenübertragung in
   Echtzeit.
3. **Sicherheit:** Verwendung eines **Shared Security Keys** (Sicherheitsschlüssel), der pro Veranstaltung vergeben
   wird. Dieser dient als Basis für die Verschlüsselung und Authentifizierung der Peers.
4. **Daten-Isolierung (Namespacing):**
  - Alle fachlichen Datenpakete (Nennungen, Ergebnisse) müssen zwingend eine `turnierId` im Header führen.
  - Clients abonnieren spezifische Turnier-Streams. Daten anderer Turniere werden auf Protokollebene verworfen.
5. **Veranstaltungsweiter Chat:**
  - Einführung eines globalen Kanals basierend auf der `veranstaltungId`.
  - Nachrichten in diesem Kanal haben keine Turnier-Bindung und sind für alle Geräte der Veranstaltung sichtbar.
  - Implementierung eines lokalen Nachrichtenspeichers (Buffering), um Offline-Phasen zu überbrücken.

## Konsequenzen

### Positiv

- **Offline-First:** Volle Funktionalität im LAN ohne Internetzwang.
- **Benutzerfreundlichkeit:** Automatische Geräteerkennung spart Zeit beim Setup vor Ort.
- **Datenintegrität:** Strikte Trennung der Turniere verhindert Fehlbuchungen.
- **Flexibilität:** Richter und Meldestelle können nahtlos zusammenarbeiten.

### Negativ/Herausforderungen

- **Netzwerk-Komplexität:** Handhabung von Firewall-Regeln und MDNS-Einschränkungen in manchen Router-Konfigurationen.
- **Synchronisation:** Konfliktauflösung bei gleichzeitigen Änderungen (Eventual Consistency) muss implementiert werden.
- **Ressourcen:** Laufende WebSocket-Verbindungen und MDNS-Services benötigen (geringe) zusätzliche Systemressourcen.

## Betrachtete Alternativen

- **Zentraler lokaler Server:** Erfordert ein dediziertes "Server-Gerät" und erhöht die Komplexität des Deployments. (
  Verworfen zugunsten von P2P/Master-Client Hybrid).
- **HTTP Polling:** Zu langsam für Echtzeit-Richter-Eingaben und verursacht unnötigen Overhead. (Verworfen zugunsten von
  WebSockets).
- **Manuelle IP-Eingabe:** Zu fehleranfällig für Endanwender unter Zeitdruck. (Verworfen zugunsten von mDNS).

## Referenzen

- Vision_03: Desktop-App Architektur
- [ADR-0004: Event-driven Communication](0004-event-driven-communication-de.md)
- [ADR-0008: Multiplatform Client Applications](0008-multiplatform-client-applications-de.md)