netdiag-app/src/lib/tools/rating.ts
Eduard Wisch 34589f12d1 Phase 2: Dauertest komplett neu — Live-Ansicht, fester Takt, Foreground-Service
Kompletter Umbau (ROADMAP_UMSETZUNG.md Phase 2). Die alte Fassung hatte vier
Probleme, die den Test praktisch wertlos machten: kein festes Intervall (ein
"Messpunkt" dauerte so lange wie das Ziel zufaellig antwortete — Prod #126:
38 Punkte in 300 s statt der ueblichen ~250-300), keine Zeitreihe (nur
Summen), kein Foreground-Service trotz gegenteiliger Doku-Behauptung, kein
Abbruchpfad. Vor allem aber: waehrend der 1-60 Minuten sah man nichts ausser
"Messung laeuft ...".

Nativ (NetDiagScannerPlugin.kt, MonitorService.kt)
  StressRun komplett neu: feste Taktung per naechstem Fixpunkt (nextTick +=
  intervalSec*1000, kein Zeitverzug ueber eine Stunde), Rohzaehler
  (sentTotal/receivedTotal/rttSum/Min/Max) + echte Zeitreihe (Liste aus
  {ts,rtt}), Ausfallsegmente werden waehrend des Laufs erkannt und
  geschlossen. Laeuft im MonitorService (Foreground, wie der Geraete-Monitor)
  — dafuer wurde der Dienst auf eine Job-Registry umgestellt (jobId -> Text),
  damit ein gleichzeitig laufender Geraete-Monitor und Dauertest sich beim
  Beenden nicht gegenseitig die Benachrichtigung wegnehmen.
  Events stressSample (live, pro Probe) und stressFinished (einmalig, Grund
  completed/stopped) + getStressStatus zur Wiederaufnahme nach Seitenwechsel.
  WICHTIG geloest: laeuft der Test natuerlich aus, waehrend niemand zuhoert
  (App im Hintergrund, andere Seite offen), bleibt der Lauf-Eintrag in
  stressRuns bestehen (wie monitorRuns) statt sofort geloescht zu werden —
  sonst waere das Ergebnis unwiederbringlich weg. Neuer Aufraeum-Call
  dismissStressRun.
  Nebenbei: der geteilte io-Scope aller Plugin-Methoden lief bisher auf einem
  gewoehnlichen Job — eine unbehandelte Exception in EINER Coroutine (z.B.
  IP-Scan mit kaputtem Host) haette strukturell alle Geschwister-Coroutinen
  mitgerissen, auch einen parallel laufenden Monitor/Dauertest. Jetzt
  SupervisorJob + CoroutineExceptionHandler.

Kritischer Bug gefunden UND gefixt (im Emulator, echter Netzausfall-Test):
  `.put("rtt", rtt as Any?)` mit Kotlin null wird von org.json.JSONObject
  behandelt wie `remove(key)` — der Schluessel verschwindet komplett statt
  als JSON null anzukommen. Die App bekam damit `undefined` statt `null` fuer
  verlorene Proben; `!== null`-Filter hielten das faelschlich fuer "erhalten".
  Ergebnis: ein per Flugmodus ausgeloester echter Ausfall zeigte live "0 %
  Verlust" und "NaN ms" bei Min/Max/Oe. Betraf NUR die Live-Anzeige — die
  gespeicherte Messung war unabhaengig davon korrekt, weil buildStressResult()
  ausschliesslich aus dem nativen Kotlin-Zustand rechnet, nie ueber die
  Pro-Probe-JSON-Bruecke. Fix: ueberall explizit JSONObject.NULL statt bloss
  `null` (betraf auch die Traceroute-Korrektur aus Phase 1). Zusaetzlich
  TS-seitig als zweite Verteidigungslinie `!= null` statt `!== null` (deckt
  sowohl null als auch undefined ab).

Neu: gemeinsame Bewertung (tools/rating.ts)
  ping.ts und der alte Dauertest bewerteten denselben Netzzustand
  unterschiedlich (ping.ts: avgMs>100 -> Rot; Dauertest: nur lossPct/maxMs).
  rateLatency() ist jetzt die einzige Stelle: Verlust, Jitter, Latenz nach
  Zielklasse (LAN/WLAN/WAN) UND eine eigene Regel "jeder Ausfall > 5 s = Rot"
  unabhaengig vom Gesamt-Verlustprozentsatz. ping.ts umgestellt, unveraendertes
  Verhalten fuer die bisherigen Schwellen (inkl. Jitter>10ms, das beim
  Portieren fast uebersehen wurde).

Neue Route statt Dialog (routes/protokoll/[id]/stresstest/)
  Wie IP-Test/WLAN/Monitor eine eigene Seite statt des blockierenden
  Werkzeug-Dialogs. Einrichtung (Ziel leer=Gateway, Dauer, Takt) mit
  Vorlaufprobe wie zuvor in stresstest.ts. Laufend: grosse Live-Zahl mit
  Ampelfarbe (rateLatency), Fortschrittsbalken mit Restzeit, Streifendiagramm
  (StressChart.svelte, live rollierendes 120s-Fenster), Zaehler
  gesendet/verloren/Ø/Min/Max, offener-Ausfall-Banner, Ereignisliste mit
  Uhrzeit ("Ausfall — wieder da nach 16 s"), Abbrechen. Abgeschlossene Laeufe
  darunter aufklappbar mit demselben Diagramm (kompletter Verlauf statt
  Fenster). stresstest.ts (Tool-Registry-Eintrag) ist jetzt nur noch
  Namens-Lookup fuer die Messungen-Liste, run() wirft bewusst einen Fehler,
  falls doch noch etwas den alten Weg aufruft.

Sicherheitsnetz gegen verpasste Events (lib/stresstest.ts)
  Ein natuerlich beendeter Test, waehrend niemand auf der Stresstest-Seite
  ist, verpasst dort das stressFinished-Event. Die Hauptprotokollseite prueft
  deshalb beim Oeffnen zusaetzlich per resumeFinishedStressSessions() nach
  (praktisch immer besucht, bevor ein Protokoll abgeschlossen wird) und
  traegt das Ergebnis nach. Bekannter Rest-Fall (dokumentiert): verlaesst der
  Techniker das Protokoll komplett ohne eine der beiden Seiten noch einmal zu
  oeffnen, bleibt der fertige Lauf bis zum naechsten Besuch liegen.

Ergebnis-Speicherung: Zeitreihe in 1-Minuten-Buckets + Ausfallsegmente +
laengster Ausfall als Measurement (tool=stresstest, sync-faehig) — Ausfaelle
werden beim Abschliessen mit dem nativen (autoritativen) Ergebnis abgeglichen,
nicht nur mit der lokal live mitgefuehrten Kopie.

Getestet im Emulator (Pixel 6 / Android 14):
- 1-Minuten-Lauf komplett bei ausgeschaltetem Display durchgelaufen
  (Foreground-Service haelt den Prozess), automatischer Abschluss + Toast
- Echter Netzausfall per Flugmodus (15s) waehrend laufendem 5-Minuten-Test:
  korrekt 23,2%/16,7% Verlust, Min/Max ohne NaN, Ereignisliste mit exakter
  Uhrzeit und Dauer — nach dem NULL-Fix verifiziert
- Abbrechen-Pfad: sofortiger Stopp, korrektes Teil-Ergebnis
- Wiederaufnahme: laufender Test nach APK-Neuinstallation (Prozess-Kill)
  korrekt als beendet erkannt
- gradle compileDebugKotlin ok, svelte-check 0 Fehler

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-15 00:39:36 +02:00

54 lines
2.2 KiB
TypeScript

/**
* Gemeinsame Ampel-Bewertung für Latenz-/Verlustmessungen.
*
* Vorher bewerteten `ping.ts` und der alte Dauertest denselben Netzzustand
* unterschiedlich: `ping.ts` schlug schon bei `avgMs > 100` auf Rot, der
* Dauertest schaute nur auf `lossPct`/`maxMs`. Derselbe Zustand konnte damit
* einmal Rot, einmal Gelb sein — verwirrend für den Techniker und schlecht
* fürs Kundenprotokoll. Diese Funktion ist jetzt die einzige Stelle, die
* entscheidet, und wird von beiden Werkzeugen aufgerufen.
*/
import type { MeasureStatus } from '../types';
/** Grobe Einordnung des Ziels — WAN-Latenzen sind strukturell höher als LAN. */
export type TargetClass = 'lan' | 'wlan' | 'wan';
export interface LatencyRating {
/** Verlust in Prozent (Kommazahl) */
lossPct: number;
/** Leitwert der Latenz — bevorzugt Median, sonst Mittelwert; null = nicht ermittelt */
latencyMs: number | null;
/** längster einzelner Ausfall in Sekunden, falls bekannt (nur Dauertest) */
longestOutageSec?: number | null;
/** Schwankung zwischen aufeinanderfolgenden Proben; > 10 ms zählt als Warnung */
jitterMs?: number | null;
}
const THRESHOLDS: Record<TargetClass, { warnMs: number; failMs: number }> = {
lan: { warnMs: 20, failMs: 100 },
wlan: { warnMs: 50, failMs: 150 },
wan: { warnMs: 150, failMs: 400 },
};
/**
* Bewertet eine Latenz-/Verlustmessung. `targetClass` default 'lan', weil die
* meisten Ziele (Gateway, Switch, Gerät im Kundennetz) LAN sind — ein Anrufer
* ins Internet (Traceroute-Ziel, WAN-Speedtest) sollte 'wan' übergeben.
*/
export function rateLatency(r: LatencyRating, targetClass: TargetClass = 'lan'): MeasureStatus {
const t = THRESHOLDS[targetClass];
// Ein einzelner Ausfall über 5 s ist für den Kunden spürbar (Videocall bricht,
// Kasse hängt) — unabhängig davon, wie klein der Verlust über die Gesamtdauer
// gerechnet aussieht. Deshalb eigene, vorrangige Regel.
if ((r.longestOutageSec ?? 0) > 5) return 2;
if (r.lossPct >= 10) return 2;
if (r.latencyMs !== null && r.latencyMs > t.failMs) return 2;
let status: MeasureStatus = 0;
if (r.lossPct > 0) status = 1;
if ((r.jitterMs ?? 0) > 10) status = 1;
if (r.latencyMs !== null && r.latencyMs > t.warnMs) status = 1;
return status;
}