Stefan Mogeritsch
683ef956fc
- Documented decision for Peer-to-Peer (P2P) model with mDNS discovery, WebSocket transport, and shared security keys. - Addressed data isolation with namespacing by turnierId. - Updated roadmap to reflect progress in Phase 6: Vernetzung & Inter-App Kommunikation. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
72 lines
3.4 KiB
Markdown
72 lines
3.4 KiB
Markdown
---
|
|
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)
|