urMQTT na de VPS: SQLite in gebruikersmodus, vergelijking met Mosquitto, configuratie als data en een builder in de browser

Het tweede artikel, urMQTT op een echte VPS, eindigde met een lijst "Wat volgt": H6 (SQLite buiten de kernel), H7 (tijdveiligheid), X11 (vergelijking met Mosquitto op dezelfde VPS) en de eerste release. Dit artikel volgt die lijst in dezelfde volgorde en voegt dan twee dingen toe die niet op de lijst stonden, omdat ze onderweg opdoken: configuratie als data, met een web-builder voor ISO's, en optionele gewone MQTT zonder TLS. Net als eerder: wat we hadden gepland, wat we hebben gebouwd, wat ons verraste en wat openstaat. In dit artikel staan ook enkele resultaten die niet in het voordeel van urMQTT uitvallen; we hebben ze laten staan omdat ze deel van de waarheid zijn.

De opmerking vooraf blijft dezelfde: het project is pre-alfa, de eerste release is alleen voor VPS'en met KVM, en de cijfers meten code, tests en bepaalde experimenten, geen rijpheid in productie.

Hoe het er in de tijd uitzag

Sinds het vorige artikel (31.10. om 23:00) tot vandaag (1.11. om 20:41) zijn er 59 nieuwe commits in de repository bijgekomen, in totaal 178. Ze zijn allemaal in één kalenderdag ontstaan, dus dezelfde waarschuwing als eerder geldt: het project wordt gebouwd met Claude Code (de commits dragen Co-Authored-By: Claude), plan, code, tests en ADR's ontstaan in korte, gesloten lussen, en de cijfers hieronder zeggen iets over de hoeveelheid code en controles, niet over hoeveel menselijk werk erin zit.

De cijfers zijn berekend met dezelfde methode als in het vorige artikel: alle .rs-bestanden buiten vendor/ en fuzz/, #[test]-functies, koppen ## ADR- in docs/DECISIONS.md.

Moment	Commit	Tijdstip	Regels Rust	Tests	ADR's
vorig artikel	794f607	31.10. 23:00	89.790	739	104
H6 klaar	a0423cc	1.11. 03:59	95.078	754	107
X11	a29f49b	1.11. 07:56	95.579	754	108
web-builder en releasespiegel	582783f	1.11. 16:49	105.645	848	122
gewone MQTT, documentatie	8f959f1	1.11. 19:05	112.408	926	125
vandaag	d21e3ec	1.11. 20:41	112.408	926	126

Er is parallel op meerdere branches gewerkt, dus de volgorde van de commits is niet strikt de volgorde van het werk. De ADR's zijn genummerd tot 232, maar de nummering heeft gaten (een deel is hernoemd bij het samenvoegen van branches); we tellen de koppen, niet het hoogste nummer. Releases: v0.2.0 (1.11., 18:45 UTC) en v0.2.1 (1.11., 20:22 UTC), beide gemarkeerd als pre-release.

H6: SQLite in gebruikersmodus

Wat we hadden gepland. SQLite is 254.268 regels C die de database, de WAL en het journaal van schijf parsen, en de schijf kan worden gemaakt of gewijzigd. Tot dan toe draaide het in de kernel, met de rechten van de kernel. Wat we hebben gebouwd (ADR-210 tot ADR-212): SQLite, zijn libc-onderdelen en de heap zijn verplaatst naar een apart programma, dbworker, dat draait op EL0 (aarch64) respectievelijk ring 3 (x86_64), in een eigen adresruimte. De kernel linkt SQLite niet meer. De worker praat met de kernel via een gedeeld geheugenvenster en twaalf systeemaanroepen, en elke lengte en elke offset die terugkomt wordt gecontroleerd voordat ze worden gebruikt. Een fout in de worker (ongeoorloofde toegang, ongedefinieerde instructie, overschreden tijdbudget van 30 s) beëindigt de aanroep, de worker wordt opnieuw gestart en de database wordt uit de WAL geopend zoals bij het opstarten; na 5 herstarts per minuut wordt de opslag defect verklaard en wordt er niet eindeloos herstart.

De prijs, gemeten op aarch64 onder HVF, dezelfde VM, een kernel met ingebouwde SQLite tegenover een kernel met de worker, zes afwisselende runs van elk:

Meting	Ervoor (in de kernel)	Erna (worker)	Verschil
binnengaan en verlaten van de gebruikersmodus	-	1,1 us per rondgang
db-bench, 5.000 inserts in 50 transacties, beste / mediaan	61,9k / 58,4k op/s	54,7k / 53,3k op/s	-11,6 % / -8,7 %
één insert per transactie, beste / mediaan	2.319 / 2.148 op/s	2.307 / 2.126 op/s	-0,5 % / -1 %
volledige back-up in één aanroep (23 MiB)	514 ms	635 ms	+23 %

Schrijfacties naar schijf (1.572) en flushes (319) zijn identiek, zoals het hoort. Dit is niet geïsoleerd: de kernel vertrouwt nog steeds wat de worker teruggeeft, na controle van de vorm. Een gecompromitteerde worker kan liegen (bijvoorbeeld een lege lijst van ingetrokken certificaten teruggeven en ze daarmee weer "ongedaan intrekken"), maar kan het geheugen van de kernel, de TLS-sleutels en de ticketsleutels niet lezen. Er is geen KPTI, dus lekken van het type Spectre/Meltdown worden niet voorkomen en we beweren er niets over; de PAC-sleutel wordt gedeeld door EL0 en EL1. Op x86_64 hebben we de schakelkosten niet gemeten op KVM (onder TCG zou het getal zinloos zijn), en het fuzzen van de worker en het protocol zelf is niet af. De testreeks voor opslag (79 scenario's, elk draait SQLite in de worker) slaagt op aarch64 HVF en x86_64 TCG, op aarch64 TCG 76 (één wordt overgeslagen omdat TCG geen MSI-X heeft).

H7 is afgesloten, maar niet zoals we hadden aangekondigd. De ondergrens voor de tijd (ADR-050) en SNTP met consensus (T1) dekken de reikwijdte van H7; NTS (RFC 8915) blijft buiten de reikwijdte en is vastgelegd als resterend risico, niet als iets wat werkt. We vinden niet dat tijdveiligheid "opgelost" is, maar dat het aantoonbare deel ervan klaar is.

Nieuwe netwerkoptie. Contabo geeft geen DHCP aan een aangepaste ISO, dus de VPS vroeg tot dan toe om een andere image dan de lab-VM. Nu vraagt network.mode = "auto" (ADR-214) eerst DHCP, en als er binnen de ingestelde tijd (dhcp_timeout_s, standaard 15 s) geen lease is of die verloren gaat, past het het ingestelde vaste adres toe. Handmatig geprobeerd in QEMU (met DHCP gebruikt het de lease, zonder netwerk valt het na 5 s terug op het vaste adres); een smoke-scenario daarvoor is er nog niet.

X11: vergelijking met Mosquitto op dezelfde VPS

Hetzelfde type machine als in het vorige artikel (Contabo, 4 vCPU AMD EPYC, 8 GiB), belasting vanaf een Linux-host op 15 ms afstand, wederzijdse TLS 1.3 met dezelfde certificaten aan beide kanten, Mosquitto 2.0.21 op Debian 13 zonder persistentie. De methode en de beslissingen staan in ADR-213, de ruwe data in docs/perf-results/. Mediaan van drie runs.

	urMQTT	Mosquitto 2.0.21
handshakes/s, 32 / 64 / 128 clients (benchprofiel)	169 / 278 / 413	82 / 140 / 184
idem, met de limieten zoals ze worden geleverd	185 / 262 / 333 (bij 128: 202 tot 286 fouten, handshake-resets)	-
geheugen per inactieve verbinding (20.000 verbindingen)	0,50 KB kernel-heap (0,66 KB bij 5.000)	26,8 KB procesgroei
latentie p50, QoS 0 / QoS 1, 800 berichten/s, 64 B	14,0 / 14,8 ms	21,4 / 39,5 ms
QoS 1, 4.800 berichten/s, afgeleverd/s (p50)	4.209 (77 ms)	4.235 (197 ms)
100 abonnees, 50 berichten/s: p50	16,6 ms	99 ms
één stroom, QoS 0, 64 B, gepubliceerd/s	2.962 (0 tot 7.733)	22.749

Wat dit betekent en wat niet. De handshakes zijn ondergrenzen voor beide servers: de belastinggenerator is een gedeelde VM met 60 tot 70 % gestolen processortijd en zat bij 128 threads dicht bij zijn eigen limiet, terwijl de werkcores van urMQTT slechts 12 tot 13 % bezet waren. De verhouding bij 128 clients (ongeveer 2,2 keer) is het zinvolst; bij 32 en 64 meet ze voornamelijk het wachten van de clients. De geheugencijfers tellen niet hetzelfde (kernel-heap tegenover RSS van het proces), dus "ongeveer 50 keer minder" is een orde van grootte, geen precieze verhouding. De latentie van 14 ms is één netwerkrondgang (ongeveer 15 ms), dus "geen meetbare tijd van de broker"; de staarten (p99 ongeveer 100 tot 200 ms) worden bij beide brokers gedomineerd door de gedeelde hosts. Verschillen onder ongeveer 20 % beweren we niet.

Wat niet in ons voordeel uitviel en in de tabellen is gebleven: één TCP-stroom door urMQTT droeg 2 tot 8 keer minder dan door Mosquitto, met schommelingen van nul tot 7,7 duizend berichten per seconde tussen runs, en de watchdog van 20 ms voor de handler verbrak levende verbindingen wanneer de hypervisor een vCPU stopzette (in de productie-opstelling action = "drop", 6 tot 8 verbindingen per run bij QoS 0-overbelasting). Beide zijn beschreven in de volgende paragraaf, omdat ze hun oorzaken in onze eigen code hadden.

Waarom de enkele stroom traag was: oorzaken, geen excuses

Het makkelijkst zou zijn om "gedeelde VPS" te zeggen. Dat hebben we niet gedaan; we hebben op dezelfde VPS en met dezelfde methode naar oorzaken gezocht. Er zijn er vijf gevonden, vier in het datapad en één in de watchdog (ADR-221 tot ADR-224):

Symptoom in X11	Oorzaak in urMQTT	Wijziging
één stroom 1,9k berichten/s, vaak 0 afgeleverd	Verloren wake-up: de uitvoerlus gaf de lijst van gereedstaande verbindingen terug over de net geschreven lijst heen; een abonnee wiens uitgaande buffer eenmaal vol was geraakt werd nooit meer bediend totdat een PINGRESP hem wekte	gerepareerd (ADR-223)
een paar procent verlies verandert 48k in 14k berichten/s	elk segment na een verloren segment werd weggegooid (ontvangst alleen in volgorde), dus herstel kostte één netwerkrondgang per segment	wachtrij voor segmenten buiten volgorde, SACK (ADR-222)
plafond van 4,4 MB/s bij 15 ms	16-bits venster, verzendwachtrij van 64 KiB en een langzame start die ACK's telde in plaats van bytes	vensterschaling, tijdstempels, tellen in bytes (ADR-222)
elke rondgang van een stroom die past wacht 0 tot 10 ms	de dispatcher sliep tot de volgende tik van 10 ms (virtio-net heeft geen interrupt voor ontvangst)	de NIC elke 200 us pollen zolang er verbindingen zijn (ADR-224)
1 tot 8 verbroken verbindingen per run	de watchdog rekende de verstreken tijd aan de handler aan, en de VPS zet vCPU's vaak en lang stil	het budget is de tijd die de core daadwerkelijk heeft gewerkt (ADR-221)

De stilstanden zijn echt: op deze VPS hadden cores 0 tot 2 een mediaan van 36 tot 80 vertraagde tikken per 5 seconden, en de ergste stilstand in het venster was mediaan ongeveer 70 ms en tot 0,9 s (core 3, database en journaal: tot 1,55 s), terwijl de host geen gestolen tijd meldt (host steal 0 us). Daarom had de watchdog een tweede klok nodig, geen groter budget.

	X11-code (7f9517e)	nu (86a71ff)	Mosquitto
één stroom, QoS 0, 64 B, gepubliceerd / afgeleverd per s	1,9k / 0	23,7k / 12,6k	29,3k / 29,2k
één stroom, QoS 0, 1 KiB	0 / 0	3,9k / 2,3k	5,4k / 5,4k
16 paren, overbelasting, QoS 0, 64 B	24,7k / 20,0k	43,2k / 37,4k	31,4k / 30,7k
16 paren, overbelasting, QoS 0, 1 KiB	3,7k / 2,9k	5,0k / 4,5k	5,9k / 5,7k
verloren verbindingen per run (16 paren, 64 B)	13 (7 tot 16)	0 (0 tot 0)	0

Watchdog: 148 verbroken verbindingen in 30 belaste runs ervoor, 0 in 24 runs erna; op een lokaal apparaat dat frames vertraagt en laat vallen heeft bij 0,1 % verlies één stroom van 64 B met 14,3k berichten/s (kernel X11) nu 41,0k, en bij 0,5 % gaat het van 5,0k naar 17,7k.

Wat dit niet zegt. urMQTT is nog steeds niet sneller dan Mosquitto op één stroom: bij 64 B publiceert het ongeveer 80 % van zijn snelheid en levert het ongeveer 40 % af, omdat het QoS 0 weggooit wanneer de stroom van de abonnee trager is dan die van de uitgever (Mosquitto zet zonder limiet in de wachtrij). Bij 1 KiB in de overbelasting met 16 paren loopt Mosquitto ongeveer 15 % voor, wat binnen de ruis valt. De generator was opnieuw een gedeelde VM met 58 tot 77 % gestolen tijd. De tweede ronde (heap-locking buiten het datapad, SACK aan de verzendkant en meer) staat op de niet-geïntegreerde branch perf-single-flow-wip; de cijfers daarvan zijn nog geen beweringen en we noemen ze hier niet.

Een belofte die we niet hadden gedaan, maar toch zijn nagekomen: configuratie is data

Tot nu toe was elke configuratie een nieuwe build: sleutels en limieten waren in de image ingebakken. C1 draait dat om (ADR-215 tot ADR-219): de kernel wordt één keer gebouwd en de configuratie is data.

• Blob urmqtt-cfg (C1a): een geversioneerde, canonieke codering (velden op oplopende tags, SHA-256-vingerafdruk, optionele losse Ed25519-handtekening), 70 velden met standaardwaarden en grenzen, een decoder die alles wat ongeldig is afwijst.
• De kernel leest hem als Limine-module (C1b), vóór al het andere, op aarch64 en x86_64. Er is één uitgegeven kernel voor elke ENV behalve dev (de aarch64-ELF's voor release, prod en bench hebben dezelfde SHA-256; alleen op aarch64 gecontroleerd). De uitgegeven kernel wijst een ontwikkelconfiguratie af, en zonder configuratie schrijft hij "refusing to serve" en bedient niets.
• De geïnstalleerde schijf draagt de configuratie en een update behoudt haar (C1c).
• urmqtt-config en de ISO-sjabloon (C1d): pack, show, verify, en pack --iso vervangt beide exemplaren van de configuratieplek en 24 modulesamenvattingen in een kant-en-klare ISO. Het resultaat is byte voor byte gelijk aan de ISO die mkiso.sh --config bouwt. De sjabloon van release v0.2.0 is 63.111.168 bytes groot.
• Vertrouwensverklaring (ADR-219): een geconfigureerde image schrijft bij het opstarten de vingerafdruk van de configuratie uit (config: fingerprint ...), en de handtekening is optioneel en standaard uitgeschakeld. Een gewijzigde ISO heeft geen officiële samenvatting; de vingerafdruk is de manier om te zien wat erin zit.

De builder op aldo.tech

Wat urmqtt-config pack --iso doet, doet ook de webpagina, met dezelfde code: de bibliotheek van de tool gecompileerd naar WebAssembly (1,06 MB, zonder imports en zonder unsafe-blok). De pagina staat op aldo.tech/nl/producten/urmqtt-builder/ en bestaat in alle 15 talen van de site (bijvoorbeeld hr).

• Er verlaat niets de browser. Certificaten, privésleutels en de kant-en-klare ISO blijven op de computer; de pagina downloadt alleen releasebestanden van deze site, zonder tracking en zonder scripts van derden. In de test live droeg geen enkel verzoek sleutelmateriaal.
• Releasespiegel (ADR-227): elk uur (systemd-timer, lage prioriteit) kopieert hij de releases van GitHub, controleert elke vóór publicatie, en de pagina in de browser controleert de handtekening van SHA256SUMS met een in de pagina ingebouwde sleutel en schrijft pas daarna de configuratie in de sjabloon. Een mislukte controle blokkeert het downloaden.
• Eenvoudig als standaard, geavanceerd als dat nodig is (ADR-232): het eerste scherm bestaat uit drie stappen (waar het draait, uw certificaten, naam van de image). Eén veld om bestanden in te slepen sorteert certificaat, sleutel en CA op inhoud. De geavanceerde weergave opent elk van de 70 velden, zoeken, en import en export van TOML; beide weergaven bewerken dezelfde toestand. De sjabloon (63 MB) wordt gedownload terwijl de gebruiker het formulier invult. In een proef live, met een proefspiegel en een proefsleutel, duurde het bouwen van de ISO in de browser 5 tot 18 s.

Emulator, optioneel. Naast "ISO downloaden" staat "Uitproberen in de emulator": QEMU gecompileerd naar WebAssembly draait de net gebouwde image in een browsertabblad. Er wordt niets van gedownload vóór de klik (ongeveer 3 MB de eerste keer). De emulator is alleen BIOS, zonder netwerk (zodat het verkeer van de gebruiker niet via een tussenpersoon loopt en "er verlaat niets de browser" niet wordt geschaad), vraagt ongeveer 1,5 GB geheugen en een desktopbrowser (getest met Chrome; Firefox en Safari niet). Daarin bereikt urMQTT URMQTT READY in ongeveer 8 s (met overgeslagen aftelling) en schrijft het dezelfde vingerafdruk van de configuratie uit als de pagina, wat het bewijs is dat juist die configuratie is opgestart. Het opstarten is ongeveer 2 keer langzamer dan in het oorspronkelijke QEMU op dezelfde Mac (0,82 s tegenover 1,9 s), en de cryptografie ongeveer 58 keer langzamer omdat de hardware-instructies worden geëmuleerd. Daarom trekken we uit de emulator geen enkele bewering over snelheid, en de pagina zegt dat vóór het starten. Bij het bouwen moesten vier bytes in de .wasm worden gepatcht vanwege een fout in de vertaling van de POPCNT-instructie in het oorspronkelijke QEMU (die hebben we nog niet gemeld); de emulator zelf valt onder de GPL, met aanbod van de broncode.

Gewone MQTT, alleen voor netwerken die u vertrouwt

Gewone MQTT (TCP 1883, zonder TLS) is in IoT heel gangbaar: het is de standaard in Mosquitto, in de meeste firmware voor Arduino en ESP, in Tasmota, Zigbee2MQTT en Home Assistant, en wordt ook gebruikt binnen gesegmenteerde industriële netwerken, achter VPN's en op privé-LAN's, en zelfs op apparaten zonder klok (certificaten vragen een datum), zonder genoeg flash of processor voor TLS. Over een onbetrouwbaar netwerk is het niet aanvaardbaar: wie onderweg zit, leest en wijzigt het verkeer. Daarom is P1 (ADR-229 tot ADR-231) een uitdrukkelijke, beperkte keuze, standaard uitgeschakeld, en blijft de TLS-poort bestaan; TLS wordt hiermee niet uitgeschakeld, de gewone poort komt er naast.

• Een lijst van toegestane netwerken is verplicht (allow_from, CIDR's) en wordt bij de SYN gecontroleerd: buiten de lijst is er geen SYN-ACK en geen toestand. Het hele internet (0.0.0.0/0) vraagt een aparte, uitdrukkelijke optie.
• Drie aanmeldmethoden: wachtwoord (standaard wanneer ingeschakeld; PBKDF2-HMAC-SHA-256, salt, 10.000 iteraties, vergelijking in constante tijd, vergrendeling per adres), anoniem (één geconfigureerde identiteit met een eigen ACL) en per adres (ip). De builder hasht het wachtwoord in de browser en bewaart in het geheugen alleen de samenvatting.
• Minder rechten dan mTLS: een gewone client heeft nooit service-, operator- of beheerrechten, geen $SYS en geen console, heeft eigen sessies ($plain/<identiteit>/<client-id>, alleen schone), en eigen limieten en het register van toegestane apparaten blijven voor hem gelden.
• Wat verloren gaat, staat in SECURITY.md: vertrouwelijkheid, integriteit, authenticiteit van de broker en herhaling van een opgenomen aanmelding. Dat is met configuratie niet te herstellen; zo is het zonder TLS.

Gemeten op een laptop (Apple silicon, HVF, gebruikersnetwerk van QEMU), 16 paren, 64 B, drie runs van 10 s: bij 8.000 berichten per seconde leveren het TLS-pad en het gewone pad alle berichten af met dezelfde latentie (p50 0,17 ms tegenover 0,13 tot 0,18 ms), nieuwe verbindingen per seconde: TLS ongeveer 2.600 tot 2.750, anoniem gewoon ongeveer 4.900 tot 7.800, en aanmelden met wachtwoord is het dure deel: één PBKDF2 kost ongeveer 2,5 ms, dus het aantal nieuwe aanmeldingen wordt beperkt tot ongeveer 200 per datacore per seconde (gemeten 308 tot 342 op twee cores). Overbelasting op die machine is geen stabiel instrument (20k tot 440k afgeleverd per seconde tussen runs) en we trekken er geen conclusie uit. Een vergelijking van het gewone pad met Mosquitto op de VPS is nog niet gedaan. Tests: smoke-groep plaintext 7 van 7 op aarch64 HVF en op x86_64 TCG, nieuw fuzzdoel plain_input (2,3 miljoen runs zonder bevindingen).

Fouten die het gebruik live aan het licht bracht

Twee dingen werden niet door de tests gevonden, maar door de eerste inschakeling op de echte site:

• De pagina zocht de releasebestanden één map te hoog, waardoor elke controle van de handtekening met 404 antwoordde (reparatie 13af301). De test gebruikte een proefspiegel op een ander pad.
• Het toetsenbord van de emulator bereikte de gast nooit: de oorzaak was niet een slechte vertaling van toetsen, maar dat het dialoogvenster helemaal niet naar toetsen luisterde (reparatie in ADR-232, met een opstartinvoer zonder toetsen).

Lessen

• Zoek de oorzaak, geef de omgeving niet de schuld. De meeste zwakheden van de enkele stroom en alle verbroken verbindingen waren de onze; de hypervisor is echt, maar moest worden gemeten, niet verondersteld.
• Een vergelijking met een ander product moet ook de verliezen omvatten. Een tabel waarin alleen onze overwinningen staan, zou geen vergelijking zijn.
• Een meetinstrument heeft grenzen. Een gedeelde generator met 60 tot 70 % gestolen tijd verandert wat de cijfers betekenen; daarom schrijven we "ondergrens" en beweren we geen verschillen onder 20 %.
• Isolatie is geen bewijs. SQLite in EL0 verkleint wat een fout erin kan doen, niet wat het kan liegen.
• Een echte installatie vindt wat tests niet zoeken: een pad dat verkeerd in elkaar is gezet en toetsen waar niemand naar luistert.

Wat nog niet bewezen is

• De ondertekeningssleutel van de releases is voorlopig een proefsleutel; v0.2.0 en v0.2.1 zijn pre-releases, en de images erbij zijn ontwikkelimages met proefcertificaten (behalve de sjabloon, die zonder configuratie is).
• 13 vertalingen van de builderpagina (en van dit artikel) zijn door een AI geschreven en gecontroleerd met tests en steekproeven, niet door moedertaalsprekers.
• De vergelijking met Mosquitto is één sessie, één pad en één gedeelde generator, op een gedeelde VPS; verschillen onder 20 % zijn geen beweringen.
• Het gewone pad is niet gemeten op de VPS en niet tegen Mosquitto.
• Lighthouse op de nieuwe eenvoudige weergave is niet bevestigd (oude weergave: toegankelijkheid 95 of hoger).
• Bare metal, de x86_64-prijs van de worker op KVM, Firefox en Safari voor de emulator: niet gemeten.

Wat volgt

• D1: openbare demobroker. De emulator uit de browser kunnen we niet openbaar maken: hij leeft in het tabblad van één bezoeker, is 20 tot 100 keer langzamer dan KVM, heeft geen inkomend netwerk en verdwijnt wanneer het tabblad wordt gesloten; het internet doorsturen naar de browser van een ander zou ook misbruik zijn. Een echte demobroker is mogelijk: urMQTT op een VPS achter een naam op aldo.tech, met een gepubliceerde proef-CA, een strikte ACL en kleine limieten. Dat is voorlopig alleen een idee, geen bouwwerk, en vraagt uitdrukkelijke toestemming voor openbare blootstelling.
• Tweede ronde voor de enkele stroom (branch perf-single-flow-wip): pas wanneer ze op de VPS is gemeten en samengevoegd.
• Het gewone pad tegen Mosquitto op de VPS, aanmelding en intrekking van accounts voor gewone MQTT via een ondertekend beheerkanaal.
• Na de release: bare metal (X12 tot X16), IOMMU en Secure Boot, schijfversleuteling.

De code staat op github.com/zeljan-alduk/urMQTT, en docs/PROGRESS.md blijft de enige bron van waarheid over wat echt werkt, docs/PERFORMANCE.md over wat is gemeten. Pre-alfa, zoals eerder; foutmeldingen en beveiligingsmeldingen volgens de aanwijzingen in SECURITY.md zijn welkom.