urMQTT nach dem VPS: SQLite im Benutzermodus, Vergleich mit Mosquitto, Konfiguration als Daten und ein Builder im Browser

Der zweite Text, urMQTT auf einem echten VPS, endete mit einer Liste unter "Was als Nächstes kommt": H6 (SQLite außerhalb des Kernels), H7 (Zeitsicherheit), X11 (Vergleich mit Mosquitto auf demselben VPS) und die erste Veröffentlichung. Dieser Text folgt dieser Liste in derselben Reihenfolge und fügt dann zwei Dinge hinzu, die nicht auf der Liste standen, weil sie unterwegs entstanden sind: Konfiguration als Daten, mit einem Web-Builder für ISOs, und optionales einfaches MQTT ohne TLS. Wie zuvor: was wir geplant haben, was wir gebaut haben, was uns überrascht hat und was offen ist. In diesem Text stehen auch einige Ergebnisse, die nicht zugunsten von urMQTT ausfallen; wir haben sie drin gelassen, weil sie Teil der Wahrheit sind.

Der Hinweis vorab bleibt derselbe: Das Projekt ist Pre-Alpha, die erste Veröffentlichung gilt nur für VPS mit KVM, und die Zahlen messen Code, Tests und bestimmte Versuche, nicht die Reife in der Produktion.

Wie das in der Zeit aussah

Seit dem vorigen Text (31.10. um 23:00 Uhr) bis heute (1.11. um 20:41 Uhr) sind im Repository 59 neue Commits dazugekommen, insgesamt 178. Alle sind an einem einzigen Kalendertag entstanden, deshalb gilt dieselbe Warnung wie zuvor: Das Projekt wird mit Claude Code gebaut (die Commits tragen Co-Authored-By: Claude), Plan, Code, Tests und ADRs entstehen in kurzen, geschlossenen Schleifen, und die Zahlen unten sagen etwas über die Menge an Code und Prüfungen aus, nicht darüber, wie viel menschliche Arbeit darin steckt.

Die Zahlen sind mit derselben Methode berechnet wie im letzten Text: alle .rs-Dateien außerhalb von vendor/ und fuzz/, #[test]-Funktionen, Überschriften ## ADR- in docs/DECISIONS.md.

Zeitpunkt	Commit	Zeit	Rust-Zeilen	Tests	ADRs
letzter Text	794f607	31.10. 23:00	89 790	739	104
H6 fertig	a0423cc	1.11. 03:59	95 078	754	107
X11	a29f49b	1.11. 07:56	95 579	754	108
Web-Builder und Release-Mirror	582783f	1.11. 16:49	105 645	848	122
einfaches MQTT, Dokumentation	8f959f1	1.11. 19:05	112 408	926	125
heute	d21e3ec	1.11. 20:41	112 408	926	126

Es wurde parallel auf mehreren Branches gearbeitet, daher ist die Reihenfolge der Commits nicht strikt die Reihenfolge der Arbeit. Die ADRs sind bis 232 nummeriert, aber die Nummerierung hat Lücken (ein Teil wurde beim Zusammenführen von Branches umbenannt); wir zählen die Überschriften, nicht die größte Nummer. Veröffentlichungen: v0.2.0 (1.11., 18:45 UTC) und v0.2.1 (1.11., 20:22 UTC), beide als Pre-Release gekennzeichnet.

H6: SQLite im Benutzermodus

Was wir geplant haben. SQLite sind 254 268 Zeilen C, die die Datenbank, das WAL und das Journal von der Festplatte parsen, und die Festplatte kann manipuliert oder verändert sein. Bis dahin lief es im Kernel, mit den Rechten des Kernels. Was wir gebaut haben (ADR-210 bis ADR-212): SQLite, seine libc-Teile und der Heap wurden in ein eigenes Programm verschoben, dbworker, das auf EL0 (aarch64) bzw. Ring 3 (x86_64) in einem eigenen Adressraum läuft. Der Kernel linkt SQLite nicht mehr. Der Worker spricht mit dem Kernel über ein gemeinsames Speicherfenster und zwölf Systemaufrufe, und jede zurückgegebene Länge und jeder Offset wird vor der Verwendung geprüft. Ein Fehler im Worker (unzulässiger Zugriff, undefinierte Instruktion, überschrittenes Zeitbudget von 30 s) beendet den Aufruf, der Worker wird neu gestartet und die Datenbank wird aus dem WAL geöffnet wie beim Hochfahren; nach 5 Neustarts pro Minute wird der Speicher für defekt erklärt, statt endlos neu zu starten.

Die Kosten, gemessen auf aarch64 unter HVF, dieselbe VM, Kernel mit eingebautem SQLite gegenüber Kernel mit Worker, je sechs abwechselnde Läufe:

Messung	Vorher (im Kernel)	Nachher (Worker)	Unterschied
Ein- und Austritt aus dem Benutzermodus	-	1,1 us pro Runde
db-bench, 5 000 Einfügungen in 50 Transaktionen, bester / Median	61,9k / 58,4k op/s	54,7k / 53,3k op/s	-11,6 % / -8,7 %
eine Einfügung pro Transaktion, bester / Median	2 319 / 2 148 op/s	2 307 / 2 126 op/s	-0,5 % / -1 %
komplette Sicherung in einem Aufruf (23 MiB)	514 ms	635 ms	+23 %

Die Schreibvorgänge auf die Festplatte (1 572) und die Flushes (319) sind identisch, wie es sein muss. Nicht isoliert ist Folgendes: Der Kernel vertraut weiterhin dem, was der Worker zurückgibt, nach Prüfung der Form. Ein kompromittierter Worker kann lügen (zum Beispiel eine leere Liste widerrufener Zertifikate zurückgeben und sie damit "entwiderrufen"), aber er kann weder den Speicher des Kernels noch TLS-Schlüssel noch Ticket-Schlüssel lesen. Es gibt kein KPTI, daher sind Lecks vom Typ Spectre/Meltdown nicht verhindert, und wir behaupten dazu nichts; der PAC-Schlüssel wird von EL0 und EL1 geteilt. Auf x86_64 haben wir die Umschaltkosten auf KVM nicht gemessen (unter TCG wäre die Zahl sinnlos), und das Fuzzing von Worker und Protokoll selbst ist nicht abgeschlossen. Die Testsuite für den Speicher (79 Szenarien, jedes lässt SQLite im Worker laufen) läuft auf aarch64 HVF und x86_64 TCG durch, auf aarch64 TCG 76 (eines wird übersprungen, weil TCG kein MSI-X hat).

H7 ist abgeschlossen, aber nicht so, wie wir es angekündigt hatten. Die Untergrenze der Zeit (ADR-050) und SNTP mit Konsens (T1) decken den Umfang von H7 ab; NTS (RFC 8915) bleibt außerhalb des Umfangs und ist als verbleibendes Risiko vermerkt, nicht als etwas, das funktioniert. Wir halten die Zeitsicherheit nicht für "gelöst", sondern ihren beweisbaren Teil für fertig.

Neue Netzwerkoption. Contabo vergibt kein DHCP an ein benutzerdefiniertes ISO, daher brauchte der VPS bisher ein anderes Image als die Labor-VM. Jetzt fragt network.mode = "auto" (ADR-214) zuerst DHCP, und wenn innerhalb der Frist (dhcp_timeout_s, Standard 15 s) kein Lease kommt oder er verloren geht, wird die vorgegebene statische Adresse verwendet. Manuell auf QEMU ausprobiert (mit DHCP nutzt es den Lease, ohne Netzwerk fällt es nach 5 s auf die statische Adresse zurück); ein Smoke-Szenario dafür gibt es noch nicht.

X11: Vergleich mit Mosquitto auf demselben VPS

Dieselbe Art von Maschine wie im letzten Text (Contabo, 4 vCPU AMD EPYC, 8 GiB), Last von einem Linux-Host 15 ms entfernt, gegenseitiges TLS 1.3 mit denselben Zertifikaten auf beiden Seiten, Mosquitto 2.0.21 auf Debian 13 ohne Persistenz. Methode und Entscheidungen stehen in ADR-213, Rohdaten in docs/perf-results/. Median aus drei Läufen.

	urMQTT	Mosquitto 2.0.21
Handshakes/s, 32 / 64 / 128 Clients (Bench-Profil)	169 / 278 / 413	82 / 140 / 184
dasselbe, mit den ausgelieferten Limits	185 / 262 / 333 (bei 128: 202 bis 286 Fehler, Handshake-Resets)	-
Speicher pro inaktiver Verbindung (20 000 Verbindungen)	0,50 KB Kernel-Heap (0,66 KB bei 5 000)	26,8 KB Prozesswachstum
Latenz p50, QoS 0 / QoS 1, 800 Nachrichten/s, 64 B	14,0 / 14,8 ms	21,4 / 39,5 ms
QoS 1, 4 800 Nachrichten/s, zugestellt/s (p50)	4 209 (77 ms)	4 235 (197 ms)
100 Subscriber, 50 Nachrichten/s: p50	16,6 ms	99 ms
ein Fluss, QoS 0, 64 B, veröffentlicht/s	2 962 (0 bis 7 733)	22 749

Was das bedeutet und was nicht. Die Handshakes sind Untergrenzen für beide Server: Der Lastgenerator ist eine geteilte VM mit 60 bis 70 % gestohlener CPU-Zeit und war bei 128 Threads nahe an seiner eigenen Grenze, während die Arbeitskerne von urMQTT nur zu 12 bis 13 % ausgelastet waren. Das Verhältnis bei 128 Clients (etwa das 2,2-Fache) ist am aussagekräftigsten; bei 32 und 64 misst es überwiegend das Warten der Clients. Die Speicherzahlen zählen nicht dasselbe (Kernel-Heap gegenüber RSS des Prozesses), daher ist "etwa 50-mal weniger" eine Größenordnung, kein genaues Verhältnis. Die Latenz von 14 ms ist eine Netzwerkrunde (etwa 15 ms), also "keine messbare Zeit des Brokers"; die Ausreißer (p99 etwa 100 bis 200 ms) werden bei beiden Brokern von den geteilten Hosts dominiert. Unterschiede unter etwa 20 % behaupten wir nicht.

Was nicht zu unseren Gunsten ausfiel und in den Tabellen blieb: Ein TCP-Fluss durch urMQTT trug 2- bis 8-mal weniger als durch Mosquitto, mit Schwankungen von null bis 7,7 Tausend Nachrichten pro Sekunde zwischen den Läufen, und der 20-ms-Watchdog des Handlers hat lebende Verbindungen getrennt, wenn der Hypervisor die vCPU angehalten hat (in der Produktionseinstellung action = "drop", 6 bis 8 Verbindungen pro Lauf bei QoS-0-Flut). Beides ist im nächsten Abschnitt beschrieben, denn beides hatte Ursachen in unserem Code.

Warum der Einzelfluss langsam war: Ursachen, keine Ausreden

Am einfachsten wäre gewesen, "geteilter VPS" zu sagen. Das haben wir nicht getan, sondern auf demselben VPS und mit derselben Methode nach Ursachen gesucht. Es wurden fünf Ursachen gefunden, vier im Datenpfad und eine im Watchdog (ADR-221 bis ADR-224):

Symptom in X11	Ursache in urMQTT	Änderung
ein Fluss 1,9k Nachrichten/s, oft 0 zugestellt	Verlorenes Aufwecken: Die Ausgabeschleife gab die Liste der bereiten Verbindungen über die soeben geschriebene zurück; ein Subscriber, dessen Ausgabepuffer sich einmal gefüllt hatte, wurde nie wieder bedient, bis ihn ein PINGRESP weckte	behoben (ADR-223)
einige Prozent Verlust machen aus 48k 14k Nachrichten/s	jedes Segment nach einem verlorenen wurde verworfen (Empfang nur in Reihenfolge), also kostete die Wiederherstellung eine Netzwerkrunde pro Segment	Warteschlange für Segmente außerhalb der Reihenfolge, SACK (ADR-222)
Obergrenze 4,4 MB/s bei 15 ms	16-Bit-Fenster, Sendewarteschlange von 64 KiB und ein Slow Start, der ACKs zählte statt Bytes	Fensterskalierung, Zeitstempel, Zählen in Bytes (ADR-222)
jede Runde eines Flusses, der passt, wartet 0 bis 10 ms	der Dispatcher schlief bis zum nächsten 10-ms-Tick (virtio-net hat keinen Interrupt für den Empfang)	NIC-Abfrage alle 200 us, solange Verbindungen bestehen (ADR-224)
1 bis 8 getrennte Verbindungen pro Lauf	der Watchdog rechnete dem Handler die verstrichene Zeit an, und der VPS hält vCPUs oft und lange an	das Budget ist die Zeit, die der Kern tatsächlich gearbeitet hat (ADR-221)

Die Anhaltephasen sind real: Auf diesem VPS hatten die Kerne 0 bis 2 einen Median von 36 bis 80 verspäteten Ticks pro 5 Sekunden, und die schlimmste Anhaltephase im Fenster lag im Median bei etwa 70 ms und bis zu 0,9 s (Kern 3, Datenbank und Journal: bis zu 1,55 s), während der Host keine gestohlene Zeit meldet (host steal 0 us). Deshalb brauchte der Watchdog eine zweite Uhr, kein größeres Budget.

	X11-Code (7f9517e)	jetzt (86a71ff)	Mosquitto
ein Fluss, QoS 0, 64 B, veröffentlicht / zugestellt pro s	1,9k / 0	23,7k / 12,6k	29,3k / 29,2k
ein Fluss, QoS 0, 1 KiB	0 / 0	3,9k / 2,3k	5,4k / 5,4k
16 Paare, Flut, QoS 0, 64 B	24,7k / 20,0k	43,2k / 37,4k	31,4k / 30,7k
16 Paare, Flut, QoS 0, 1 KiB	3,7k / 2,9k	5,0k / 4,5k	5,9k / 5,7k
verlorene Verbindungen pro Lauf (16 Paare, 64 B)	13 (7 bis 16)	0 (0 bis 0)	0

Watchdog: 148 getrennte Verbindungen in 30 belasteten Läufen vorher, 0 in 24 Läufen nachher; auf einem lokalen Gerät, das Frames verzögert und verliert, hat ein Fluss von 64 B bei 0,1 % Verlust mit 14,3k Nachrichten/s (Kernel von X11) jetzt 41,0k, und bei 0,5 % von 5,0k auf 17,7k.

Was das nicht sagt. urMQTT ist bei einem Einzelfluss weiterhin nicht schneller als Mosquitto: Bei 64 B veröffentlicht es etwa 80 % von dessen Geschwindigkeit und liefert etwa 40 % zu, weil es QoS 0 verwirft, wenn der Fluss des Subscribers langsamer ist als der des Publishers (Mosquitto reiht ohne Grenze ein). Bei 1 KiB in der 16-Paar-Flut liegt Mosquitto um etwa 15 % vorn, was im Rauschen liegt. Der Generator war wieder eine geteilte VM mit 58 bis 77 % gestohlener Zeit. Die zweite Runde (Heap-Sperren außerhalb des Datenpfads, SACK auf der Sendeseite und anderes) liegt auf dem nicht integrierten Branch perf-single-flow-wip; ihre Zahlen sind noch keine Behauptungen, und wir nennen sie hier nicht.

Ein Versprechen, das wir nicht gegeben, aber eingelöst haben: Konfiguration ist Daten

Bisher war jede Konfiguration ein neuer Build: Schlüssel und Limits waren im Image eingebaut. C1 dreht das um (ADR-215 bis ADR-219): Der Kernel wird einmal gebaut, und die Konfiguration ist Daten.

• Der Blob urmqtt-cfg (C1a): eine versionierte, kanonische Darstellung (Felder in aufsteigender Reihenfolge der Tags, SHA-256-Fingerabdruck, optionale getrennte Ed25519-Signatur), 70 Felder mit Standardwerten und Grenzen, ein Decoder, der alles Ungültige ablehnt.
• Der Kernel liest ihn als Limine-Modul (C1b), vor allem anderen, auf aarch64 und x86_64. Es gibt einen veröffentlichten Kernel für jedes ENV außer dev (die aarch64-ELFs für release, prod und bench haben denselben SHA-256; nur auf aarch64 geprüft). Der veröffentlichte Kernel lehnt eine Entwicklungskonfiguration ab, und ohne Konfiguration schreibt er "refusing to serve" und bedient nichts.
• Die installierte Festplatte trägt die Konfiguration, und das Update behält sie (C1c).
• urmqtt-config und die ISO-Vorlage (C1d): pack, show, verify, und pack --iso ersetzt beide Exemplare des Konfigurationsplatzes und 24 Modul-Digests in einem fertigen ISO. Das Ergebnis ist Byte für Byte dasselbe wie das ISO, das mkiso.sh --config baut. Die Vorlage der Version v0.2.0 hat 63 111 168 Bytes.
• Vertrauenserklärung (ADR-219): Ein konfiguriertes Image gibt beim Hochfahren den Fingerabdruck der Konfiguration aus (config: fingerprint ...), und die Signatur ist optional und standardmäßig ausgeschaltet. Ein verändertes ISO hat keinen offiziellen Digest; der Fingerabdruck ist die Möglichkeit zu sehen, was darin steckt.

Der Builder auf aldo.tech

Dasselbe, was urmqtt-config pack --iso tut, tut auch die Webseite, mit demselben Code: die Werkzeugbibliothek, kompiliert zu WebAssembly (1,06 MB, ohne Importe und ohne unsafe-Block). Die Seite ist unter aldo.tech/de/produkte/urmqtt-builder/ und in allen 15 Sprachen der Website verfügbar (zum Beispiel hr).

• Nichts verlässt den Browser. Zertifikate, private Schlüssel und das fertige ISO bleiben auf dem Computer; die Seite lädt nur die Release-Dateien von dieser Website, es gibt kein Tracking und keine Skripte von Dritten. Im Live-Test trug keine Anfrage Schlüsselmaterial.
• Release-Mirror (ADR-227): Stündlich (systemd-Timer, niedrige Priorität) kopiert er die Releases von GitHub, prüft jedes vor der Veröffentlichung, und die Seite im Browser prüft die Signatur von SHA256SUMS mit einem in die Seite eingebauten Schlüssel, erst dann schreibt sie die Konfiguration in die Vorlage. Eine fehlgeschlagene Prüfung blockiert den Download.
• Einfach als Standard, erweitert bei Bedarf (ADR-232): Der erste Bildschirm besteht aus drei Schritten (wo es läuft, Ihre Zertifikate, Name des Images). Ein einziges Feld zum Hineinziehen von Dateien sortiert Zertifikat, Schlüssel und CA nach Inhalt. Die erweiterte Ansicht öffnet jedes der 70 Felder, die Suche, Import und Export von TOML; beide Ansichten bearbeiten denselben Zustand. Die Vorlage (63 MB) wird heruntergeladen, während der Benutzer das Formular ausfüllt. Im Live-Test, mit Test-Mirror und Testschlüssel, dauerte der Bau des ISO im Browser 5 bis 18 s.

Emulator, optional. Neben "ISO herunterladen" steht "Im Emulator ausprobieren": QEMU, kompiliert zu WebAssembly, startet das soeben gebaute Image in einem Browser-Tab. Vor dem Klick wird nichts davon heruntergeladen (beim ersten Mal etwa 3 MB). Der Emulator ist nur BIOS, ohne Netzwerk (damit der Verkehr des Benutzers nicht über einen Vermittler läuft und das "nichts verlässt den Browser" verletzt), braucht etwa 1,5 GB Speicher und einen Desktop-Browser (getestet mit Chrome; Firefox und Safari nicht). Darin erreicht urMQTT URMQTT READY nach etwa 8 s (mit übersprungenem Countdown) und gibt denselben Konfigurationsfingerabdruck aus wie die Seite, was der Beweis ist, dass genau diese Konfiguration hochgefahren wurde. Das Hochfahren ist etwa 2-mal langsamer als im nativen QEMU auf demselben Mac (0,82 s gegenüber 1,9 s), und die Kryptografie etwa 58-mal langsamer, weil die Hardware-Instruktionen emuliert werden. Deshalb ziehen wir aus dem Emulator keinerlei Aussagen zur Geschwindigkeit, und die Seite sagt das vor dem Start. Beim Build mussten vier Bytes in der .wasm gepatcht werden wegen eines Fehlers bei der Übersetzung der Instruktion POPCNT im ursprünglichen Emulator (wir haben ihn noch nicht gemeldet); der Emulator selbst steht unter der GPL, mit Angebot des Quellcodes.

Einfaches MQTT, nur für Netzwerke, denen Sie vertrauen

Einfaches MQTT (TCP 1883, ohne TLS) ist im IoT sehr verbreitet: Es ist der Standard in Mosquitto, in den meisten Firmwares für Arduino und ESP, in Tasmota, Zigbee2MQTT und Home Assistant, und es wird auch in segmentierten Industrienetzen, hinter VPNs und in privaten LANs verwendet, auch auf Geräten ohne Uhr (Zertifikate brauchen ein Datum), ohne genug Flash oder Prozessor für TLS. Über ein nicht vertrauenswürdiges Netzwerk ist es nicht akzeptabel: Wer auf dem Weg sitzt, liest und verändert den Verkehr. Deshalb ist P1 (ADR-229 bis ADR-231) eine ausdrückliche, begrenzte Wahl, standardmäßig ausgeschaltet, und der TLS-Port bleibt; TLS wird dadurch nicht abgeschaltet, der einfache Port kommt zusätzlich.

• Eine Liste erlaubter Netzwerke ist Pflicht (allow_from, CIDRs) und wird beim SYN geprüft: Außerhalb der Liste gibt es kein SYN-ACK und keinen Zustand. Das gesamte Internet (0.0.0.0/0) verlangt eine eigene ausdrückliche Option.
• Drei Anmeldearten: Passwort (Standard, wenn eingeschaltet; PBKDF2-HMAC-SHA-256, Salt, 10 000 Iterationen, Vergleich in konstanter Zeit, Sperrung pro Adresse), anonym (eine konfigurierte Identität mit eigener ACL) und nach Adresse (ip). Der Builder hasht das Passwort im Browser und hält nur den Digest im Speicher.
• Weniger Rechte als mTLS: Ein einfacher Client hat nie Service-, Operator- oder Verwaltungsrechte, hat kein $SYS und keine Konsole, hat eigene Sitzungen ($plain/<identität>/<client-id>, nur saubere), und eigene Limits und das Register erlaubter Clients binden ihn weiterhin.
• Was verloren geht, steht in SECURITY.md: Vertraulichkeit, Integrität, Authentizität des Brokers und die Wiedereinspielung einer aufgezeichneten Anmeldung. Das lässt sich durch Konfiguration nicht beheben; so ist es ohne TLS.

Gemessen auf einem Laptop (Apple Silicon, HVF, QEMU-Benutzernetzwerk), 16 Paare, 64 B, drei Läufe zu je 10 s: Bei 8 000 Nachrichten pro Sekunde liefern der TLS- und der einfache Pfad alle Nachrichten mit gleicher Latenz (p50 0,17 ms gegenüber 0,13 bis 0,18 ms), neue Verbindungen pro Sekunde: TLS etwa 2 600 bis 2 750, anonym einfach etwa 4 900 bis 7 800, und die Passwort-Anmeldung ist der teure Teil: Ein PBKDF2 kostet etwa 2,5 ms, daher ist die Zahl neuer Anmeldungen auf etwa 200 pro Datenkern und Sekunde begrenzt (gemessen 308 bis 342 auf zwei Kernen). Die Flut auf dieser Maschine ist kein stabiles Instrument (20k bis 440k zugestellt pro Sekunde zwischen den Läufen), und wir ziehen daraus keinen Schluss. Der Vergleich des einfachen Pfads mit Mosquitto auf dem VPS ist noch nicht gemacht. Tests: Smoke-Gruppe plaintext 7 von 7 auf aarch64 HVF und auf x86_64 TCG, neues Fuzz-Ziel plain_input (2,3 Millionen Läufe ohne Befund).

Fehler, die der Live-Betrieb gefunden hat

Zwei Dinge haben nicht die Tests entdeckt, sondern die erste Inbetriebnahme auf der echten Website:

• Die Seite suchte die Release-Dateien ein Verzeichnis zu hoch, daher antwortete jede Signaturprüfung mit 404 (Korrektur 13af301). Der Test benutzte einen Test-Mirror unter einem anderen Pfad.
• Die Tastatur des Emulators erreichte den Gast nie: Die Ursache war nicht eine falsche Übersetzung der Tasten, sondern dass der Dialog gar nicht auf Tasten hörte (Korrektur in ADR-232, mit einem Boot-Eintrag ohne Tasten).

Lektionen

• Suchen Sie die Ursache, geben Sie nicht der Umgebung die Schuld. Die meisten Schwächen des Einzelflusses und alle getrennten Verbindungen lagen bei uns; der Hypervisor ist real, aber er musste gemessen und nicht vermutet werden.
• Ein Vergleich mit einem anderen Produkt muss auch die Verluste enthalten. Eine Tabelle, in der nur unsere Siege stehen, wäre kein Vergleich.
• Das Messinstrument hat Grenzen. Ein geteilter Generator mit 60 bis 70 % gestohlener Zeit verändert, was die Zahlen bedeuten; deshalb schreiben wir "Untergrenze" und behaupten keine Unterschiede unter 20 %.
• Isolation ist kein Beweis. SQLite in EL0 verkleinert, was ein Fehler darin anrichten kann, nicht das, wobei es lügen kann.
• Eine echte Installation findet, wonach Tests nicht suchen: einen falsch zusammengesetzten Pfad und Tasten, auf die niemand hört.

Was noch nicht bewiesen ist

• Der Signaturschlüssel der Releases ist vorerst ein Testschlüssel; v0.2.0 und v0.2.1 sind Pre-Releases, und die Images dazu sind Entwicklungs-Images mit Testzertifikaten (außer der Vorlage, die ohne Konfiguration ist).
• 13 Übersetzungen der Builder-Seite (und dieses Textes) hat eine KI geschrieben, und sie wurden durch Tests und Stichproben geprüft, nicht von Muttersprachlern.
• Der Vergleich mit Mosquitto ist eine Sitzung, ein Pfad und ein geteilter Generator, auf einem geteilten VPS; Unterschiede unter 20 % sind keine Behauptungen.
• Der einfache Pfad wurde weder auf dem VPS noch gegen Mosquitto gemessen.
• Lighthouse auf der neuen einfachen Ansicht ist nicht bestätigt (alte Ansicht: Barrierefreiheit 95 oder mehr).
• Bare Metal, x86_64-Kosten des Workers auf KVM, Firefox und Safari für den Emulator: nicht gemessen.

Was als Nächstes kommt

• D1: öffentlicher Demo-Broker. Den Emulator aus dem Browser können wir nicht öffentlich machen: Er lebt im Tab eines einzelnen Besuchers, ist 20- bis 100-mal langsamer als KVM, hat kein eingehendes Netzwerk und verschwindet mit dem Schließen des Tabs; das Internet in den Browser eines Fremden umzuleiten, wäre außerdem Missbrauch. Möglich ist ein echter Demo-Broker: urMQTT auf einem VPS hinter einem Namen auf aldo.tech, mit veröffentlichter Test-CA, strikter ACL und kleinen Limits. Das ist vorerst nur eine Idee, kein Bau, und braucht eine ausdrückliche Zustimmung zur öffentlichen Bereitstellung.
• Zweite Runde für den Einzelfluss (Branch perf-single-flow-wip): erst, wenn sie auf dem VPS gemessen und zusammengeführt ist.
• Den einfachen Pfad gegen Mosquitto auf dem VPS, Anmeldung und Widerruf von Konten für einfaches MQTT über den signierten Verwaltungskanal.
• Nach der Veröffentlichung: Bare Metal (X12 bis X16), IOMMU und Secure Boot, Festplattenverschlüsselung.

Der Code liegt auf github.com/zeljan-alduk/urMQTT, und docs/PROGRESS.md bleibt die einzige Quelle der Wahrheit darüber, was tatsächlich funktioniert, docs/PERFORMANCE.md darüber, was gemessen wurde. Pre-Alpha, wie zuvor; Fehlermeldungen und Sicherheitsmeldungen nach den Hinweisen in SECURITY.md sind willkommen.