HMS MediaEngine Agent
362e089be0
Der Nutzer hat recht: Der Ordner war voller Entwicklungs-Muell. Jetzt ist sauber getrennt: ROOT (was der Nutzer sieht und braucht): - run.py = das Programm - hms_app/ = der Anwendungscode - HMS MediaEngine.app = macOS Doppelklick-Starter - HMS-Start.vbs = Windows Doppelklick-Starter - HMS-Install.vbs = Windows Erst-Installation - HMS-Mac-Install.command = macOS Homebrew-Installation - HMS-Portable-Install.command = macOS Portable-Installation (16GB-Fix) - installer_gui.py = grafischer Installer - launcher.pyw + launcher_core.py = interne Start-Logik - LIESMICH.txt = 10-Zeilen-Kurzanleitung - .gitignore _entwicklung/ (alles andere, NICHT benoetigt): - packages/ apps/ native/ plugins/ tools/ schemas/ tests/ docs/ build/ fixture_profiles/ - PLAN.md STATUS.md ERRORS.md TEST_REPORT.md CHANGELOG.md README.md - pyproject.toml uv.lock setup_*.sh/ps1 make_mac_app.py Diese Trennung gilt ab sofort fuer alle Commits. Der Nutzer kann _entwicklung/ loeschen wenn er Platz braucht - die App laeuft ohne. Verifiziert: App startet nach Aufraeumen unveraendert (Health 200).
51 lines
2.2 KiB
Markdown
51 lines
2.2 KiB
Markdown
# ADR-0009: Node-Discovery – mDNS/DNS-SD mit manueller Fallback-Liste
|
||
|
||
- **Status:** Angenommen
|
||
- **Datum:** 2026-09-11
|
||
- **Phase:** 1
|
||
- **Bauplan:** §6.3, §27.1, §32 (ADR-Pflicht: Node-Discovery und manueller Subnetz-Fallback)
|
||
|
||
## Entscheidung
|
||
|
||
1. Discovery-Protokoll: mDNS/DNS-SD, Service-Typ `_hmsmedia._tcp.local.`
|
||
(§6.3).
|
||
2. TXT-Record enthält ausschließlich kleine, nicht vertrauliche Daten:
|
||
`proto` (Protokollversion), `node` (Node-ID), `roles` (Rollen, kommasepariert),
|
||
`port` (API-Port), `caps` (Capability-Digest, kurzer Hash).
|
||
Keine Tokens, keine Secrets (§27.1).
|
||
3. mDNS ist **keine Vertrauensentscheidung**: gefundene Nodes sind zunächst
|
||
`discovered`, steuerbar erst nach Paarung (ADR-0010).
|
||
4. Für Umgebungen ohne Multicast (VLAN, geroutete Netze, blockiertes mDNS)
|
||
existiert eine **persistente manuelle Node-Liste** (Host/IP + Port) als
|
||
gleichwertiger Fallback (§6.3).
|
||
5. Bibliothek: `zeroconf` (Standard-Python-mDNS) für den Betrieb auf
|
||
Zielsystemen. Kein Eigenbau des Multicast-Stacks; Alternativen (python-avahi,
|
||
Eigenbau) verworfen: plattformneutral unzureichend bzw. unnötiges Risiko
|
||
(§33). Im Entwicklungscontainer werden nur Modell und Registry getestet
|
||
(kein Multicast nötig); der Echtnetz-Test gehört zu Gate 1 (§29.2).
|
||
|
||
## Alternativen
|
||
|
||
- Avahi via D-Bus: Linux-only, ungeeignet für Windows-first.
|
||
- Eigener Multicast-Code: hoher Aufwand, kein messbarer Nutzen.
|
||
- Nur manuelle Liste: widerspricht §6.3 (Discovery ist Fundament).
|
||
|
||
## Folgen
|
||
|
||
- `hms_cluster.discovery` definiert ServiceInfo (Instanzname, TXT-Kodierung)
|
||
und Registry-Kategorien: `discovered`, `paired`, `unknown`, `incompatible`,
|
||
`offline` (§6.3: UI führt Gruppen getrennt auf).
|
||
- Doppelte Node-IDs werden als Fehler blockiert, nicht still gemischt (§6.3).
|
||
- Inkompatible Protokollversionen erscheinen als `incompatible`.
|
||
|
||
## Messwerte / Nachweise
|
||
|
||
- Unit-Tests: TXT-Roundtrip, Registry-Kategorien, Doppel-Node-ID-Blockade,
|
||
manuelle Liste, Protokoll-Inkompatibilität.
|
||
- Multicast-Echtnetz-Test mit zwei Nodes: Teil von Gate 1 (§29.2), auf
|
||
echter Hardware bzw. im LAN-Test nachzuholen.
|
||
|
||
## Freigabe
|
||
|
||
- Standardumsetzung gemäß §6.3; zeroconf-Addition als ADR dokumentiert (§33).
|