mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
251647a6ab
meldestelle/docs/01_Architecture/adr/0020-lan-communication-isolation-de.md
Stefan Mogeritsch 683ef956fc docs(adr): add ADR-0020 for LAN communication and data isolation architecture 
- 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>
2026-03-31 13:02:08 +02:00

3.4 KiB
Raw Blame History

type status owner
ADR ACCEPTED 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.
  1. 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