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.

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:

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.

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):

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.

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.

Eén opmerking vooraf: het project is nog steeds pre-alfa. De cijfers in dit artikel meten code en tests, geen rijpheid in productie, en de eerste release is bewust beperkt tot VPS'en met KVM. Bare metal komt later.

Hoe het er in de tijd uitzag

De eerste commit is van 28 oktober 2026 om 23:48 (M0). Op 31 oktober om 23:00 telt de repository 119 commits, verdeeld als 3, 39, 38 en 39 per kalenderdag. Meteen ook hoe dat mogelijk is: het project wordt gebouwd met Claude Code, en de commits dragen Co-Authored-By: Claude-trailers. Vier kalenderdagen geschiedenis betekenen niet dat één persoon in vier dagen 90.000 regels heeft geschreven; ze betekenen dat plan, implementatie, tests en ADR's in korte, gesloten lussen worden geschreven, en dat elke stap eindigt met hetzelfde controleritueel als eerder. De cijfers hieronder zeggen iets over de hoeveelheid code en tests, niet over hoeveel daarvan in de praktijk is beproefd.

De grafiek toont drie krommen die bijna samen stijgen, en dat is ook de bedoeling: tests en vastgelegde beslissingen volgen de code in plaats van erachteraan te lopen. De helling is het steilst op 29 oktober, toen het hele pad van kernel naar broker ontstond. Daarna komen er langzamer regels bij, maar de tests groeien sneller dan de code (27 tests op 1,6 duizend regels aan het begin, 739 op 89,8 duizend nu).

De regels zijn alle .rs-bestanden buiten vendor/ en fuzz/, de tests zijn #[test]-functies. Wat elk onderdeel heeft toegevoegd, volgens de datum in de git-geschiedenis:

Belofte 1: één ISO voor meerdere platformen

Wat we hadden gepland. Eén bestand dat opstart op aarch64 UEFI, x86_64 UEFI en x86_64 BIOS. Wat we hebben gebouwd. De port naar x86_64 (X0 tot X10) en een universele ISO met de Limine-bootloader, één hybride ISO waarmee al die combinaties opstarten; smoke-tests starten hem op vier virtuele machines. Het menu heeft drie items: urMQTT (live-modus, draait vanuit RAM, schrijft niets naar schijf), installatie op de schijf van de machine waarop hij draait (de installatie schrijft GPT en gegevens en zet de machine daarna uit) en Diagnostiek (hardwaredetectie en metingen).

Het eerste echte doel was een VPS en geen fysieke computer: we hebben besloten dat de eerste release alleen VPS'en (KVM) ondersteunt en dat bare metal daarna komt. We testten op een Contabo-VPS met een AMD EPYC-processor (familie 23, Zen 1), 4 vCPU's en 8 GiB RAM, met een virtio-net-netwerk en een virtio-scsi-schijf. De eerste poging verraste ons: de ISO, gekoppeld als virtuele cd, startte het standaarditem op, de productie-image weigerde vanaf een alleen-lezen medium te draaien en herstartte, en we kregen een eindeloze lus van menu, kernel en reset zonder iets leesbaars. Tegenwoordig laat een fatale fout in de productie-image 60 seconden lang een bericht op de console staan voordat er wordt herstart, en vanaf een optisch medium meldt hij dat hij van een alleen-lezen medium is opgestart en stopt. De live-modus in RAM (O3) heeft dat probleem later voor het gewone geval omzeild.

Het diagnostiekitem is uit die ervaring voortgekomen: een machine die we niet kunnen zien, moeten we kunnen vragen wat erin zit. Het toont CPU, RAM, netwerk, schijven en PCI-apparaten, meet de doorvoer van geheugen, schijf en cryptografie, en schrijft dezelfde metingen als JSON naar de seriële poort. Schrijven naar schijf is alleen toegestaan in niet-toegewezen ruimte en pas nadat WIPE is ingetypt; op de opname hieronder is dat overgeslagen.

Wat openstaat. Echte hardware. Na de eerste release volgt bare metal (opstarten via USB, NVMe en AHCI, de netwerkkaart van een echte computer), samen met IOMMU en Secure Boot, want zonder IOMMU kan een kwaadwillend of defect apparaat over het hele geheugen schrijven. In deze versie beweren we daarover niets.

Handshake: van 1,2 ms naar 0,24 ms

De eerste meting van de diagnostiek op de VPS leverde een vervelend getal op: de mTLS-handshake, alleen de cryptografie aan de serverkant, duurde 1,2 ms. Op aarch64 gebruikten we al hardware-instructies voor AES en SHA, maar x86_64 had niets vergelijkbaars voor publieke sleutels: RustCrypto is overdraagbaar en constant-time, en dus ook traag. Drie wijzigingen brachten dat omlaag.

• Voor P-256 hebben we de nistz256-assembly uit OpenSSL en ring overgenomen (ADR-130), met tabellen met vaste basis voor het ondertekenen en voor het verifiëren van CA-handtekeningen (ADR-110, ADR-111).
• X25519 is herschreven naar vier 64-bits limbs met MULX/ADX-instructies (ADR-131).
• Daarna hebben we ook de rest geprofileerd (ADR-132, ADR-200).

De cijfers verschillen per run ongeveer 10%, dus hebben we een bereik genoteerd in plaats van één waarde. In totaal is dat ongeveer vijf keer minder CPU-tijd voor de handshake.

Wat we over memcpy hebben geleerd. Toen de cryptografie was gedaald, liet het profiel iets zien wat we niet verwachtten: de mem*-functies (memcpy, memmove, memset) kostten 7% van de handshake, 13 tot 39% van het pad van een TLS-record (39% voor 64 B, 13% voor 4 KiB) en 17 tot 34% van de verdeling van een PUBLISH. We hebben ze vervangen door SSE2-assembly voor x86_64 (ADR-200), met differentiële tests tegen de referentie-implementatie voor alle groottes, uitlijningen en overlappingen. Per aanroep is dat 55 tot 75 cycli tegen 7 tot 12 voor 1 tot 64 bytes.

De grafiek lezen: hoe kleiner het record, hoe groter het deel van de tijd dat naar kopiëren gaat, en dus hoe groter de winst. Voor kleine berichten, het grootste deel van het MQTT-verkeer, is dat waar het om gaat.

Wat dit niet betekent. Op native x86_64 hebben we alleen OpenSSL 3.5.5 gemeten als referentie voor de assembly (ADR-130), niet als productvergelijking. De vergelijking van Linux plus Mosquitto op dezelfde VPS (taak X11) hebben we nog niet gedaan. Daarom beweren we niet dat urMQTT sneller is dan Linux: dat is niet gemeten. De cijfers hierboven vergelijken urMQTT met zichzelf.

Overbelasting was het tweede resultaat. Op de VPS, vanaf één Mac (RTT 35 ms), leverden 128 clients 618 handshakes per seconde op, 256 clients 393 en 512 clients 67, met duizenden geweigerde verbindingen. Dat was geen plateau maar een instorting. De oorzaken hebben we in de code gevonden (twee zijn bevestigd in QEMU/HVF, op de VPS konden ze niet worden nagebootst), meerdere tegelijk: een geweigerde verbinding stuurde de client via het volgende segment met een geldige SYN-cookie weer naar binnen, het weigeren met een RST zei de client meteen opnieuw te proberen, en de ontvangst was O(wachtrij). De fix (ADR-080 tot ADR-082) laat een SYN vallen die toch niet zou worden geaccepteerd, onthoudt geweigerde stromen, houdt de ontvangst in O(1) en telt handshakes per core. Mogelijk (hypothese, niet gecontroleerd) lag een deel van de oorzaak ook bij de client: de belastingstool sloot als eerste af, waardoor één Mac met 16.384 efemere poorten en een TIME_WAIT van 30 seconden beperkt was tot ongeveer 550 verbindingen per seconde. Daarom hebben we het echte plafond van de server nog niet gemeten.

Belofte 2: een rauwe schijf, maar zorgvuldig

Wat we hadden gepland. Onze eigen indeling zonder bestandssysteem behouden en alles toevoegen wat een bestandssysteem normaal biedt: uitlijning, groei, discard, back-ups en controles. Waarom geen bestandssysteem. Daarover hebben we gediscussieerd en het besluit is bevestigd: urMQTT schrijft één database, één telemetriejournaal en zijn eigen metadata, heeft geen mappen, rechten of bestandsnamen nodig, en elke extra laag zou meer code in het vertrouwde deel zijn en nog een manier waarop een schrijfactie stilletjes verdwijnt. De schijf is GPT met een ESP-partitie en één urMQTT-gegevenspartitie, met daarop onze eigen indeling.

Wat we hebben gebouwd (S2 tot S6).

• Indeling v2 (S2). Schijftopologie, uitlijning op 1 MiB of de optimale I/O-grootte, hele fysieke blokken, een A/B-paar superblokken met een generatie (ADR-140). Indeling v1 wordt door de kernel geweigerd met een duidelijke melding, en gemigreerd door de offline tool urmqtt-disk migrate (ADR-141): standaard is dat een proefrun, er wordt eerst gekopieerd en pas daarna omgeschakeld, met rollback en foutinjectie bij elke schrijfactie.
• Groei (S3). Bij het opstarten kan de schijf groeien (nooit krimpen), en op virtio-blk ook tijdens bedrijf, via de interrupt voor configuratiewijziging (ADR-142, ADR-143).
• Discard en write-zeroes (S4). Thin-provisioned schijven geven ruimte terug aan de host. In een test daalde het qcow2-bestand op de host van 62 naar 16 MiB nadat telemetriesegmenten waren verlopen, en het herstel vertrouwt nooit op inhoud die is weggegooid.
• Back-up van de database op schijf (S5). Een A/B-kopie met de online backup-API van SQLite in stappen van 16 pagina's: de langste stap is 4,6 ms tegen 445 ms wanneer in één aanroep wordt gekopieerd. Commits tijdens het kopiëren hadden een maximum van 2,4 ms tegen 2,2 ms zonder kopie. Als quick_check bij het opstarten faalt, wordt de database uit de kopie hersteld.
• Scrubben en begrensd opstarten (S6). De scrubber leest de schijf met een begrensd I/O-budget en meldt beschadigde records, en het opstarten leest alleen het nieuwste segment van elke partitie, zodat de opstarttijd niet meegroeit met de grootte van het telemetriegebied. Daarmee hebben we een probleem opgelost dat we vooraf hadden uitgerekend: op een grote schijf zou volledig herstel minuten tot tientallen minuten duren.

De hele groep smoke-tests voor opslag slaagt op beide architecturen: 79 geslaagd, 0 mislukt, op aarch64 onder HVF en op x86_64 onder TCG. We hebben ook gemeten dat S4 de database niet heeft vertraagd: 53,3 duizend inserts per seconde in batches ervoor en erna, zonder meetbaar verschil.

Wat ons verraste. Hoeveel van een "eenvoudige" indeling uit randgevallen bestaat: virtio-scsi en virtio-blk melden de topologie op verschillende manieren, en een onvolledige schrijfactie midden in een migratie moet altijd minstens één geldige versie achterlaten. Daarom is elke schrijfactie op het pad van migratie en groei door foutinjectie gegaan.

Wat openstaat. SQLite-pagina's hebben geen controlesom, dus een gewijzigde bit binnen een waarde in een rij ontdekt de database niet; telemetrierecords en de inhoud van kopieën hebben een CRC en worden wel ontdekt. Schijfversleuteling (S7) is niet af.

Belofte 3: aantoonbaar veilig, voor zover we het redden

Hardening (H4). De allocator wist vrijgegeven geheugen en controleert het bij hergebruik, detecteert dubbel vrijgeven, bindt de pointers van de vrije lijst met XOR en nult sleutels bij het vrijgeven (ADR-170). Stackbescherming (-Zstack-protector=strong, 1315 functies, en SQLite met -fstack-protector-strong, ADR-171). Foutrapporten in productie bevatten geen registers of adressen (ADR-172). KASLR op beide architecturen: de kernel is PIE en Limine verschuift hem met ongeveer 19 bits, en heap, stacks en het MMIO-venster worden willekeurig geplaatst (ADR-173). Op aarch64 markeert MTE de heap (ADR-174), maar alleen onder TCG: HVF en x86 hebben het niet. kCFI hebben we beoordeeld en niet overgenomen omdat de compiler op de vastgezette nightly crasht met een interne fout; IOMMU is uitgesteld samen met bare metal (ADR-175, ADR-176).

De prijs is gemeten, niet aangenomen. Op het handshake-pad (dp-bench, aarch64 HVF, volledige TLS 1.3 + mTLS + CONNECT-handshakes):

In totaal is de prijs op het handshake-pad dus ongeveer 5% voor de onderdelen die schoon zijn gemeten, en met PIE en tags komt het uit op ongeveer 7% op één en ongeveer 11% op vier cores, al is die meting ruisachtig. We vinden dat acceptabel, maar we hebben het niet herhaald op de x86_64-VPS.

Het is de moeite waard om dit te vergelijken met het cijfer uit het eerste artikel (862 handshakes per seconde op één core). Dezelfde tool geeft vandaag, met de hardwareversnelde cryptografie op aarch64 (X0b) en een reeks versnellingen die sindsdien zijn gekomen, 1941 vóór hardening. We hebben de bijdrage van elke wijziging niet geïsoleerd, dus over de oorzaak beweren we niets.

Hoe het is gecontroleerd, en wat niet. H5 voegde Miri toe op een deel van de host-crates, Kani-bewijzen, sanitizers, een model-fuzzer voor de ACL en dekkingsrapporten. Kani heeft record_len in TLS bewezen, parse in TCP en twee rekenkundige onderdelen van het timerwiel. Niet bewezen (time-out): beide MQTT-decoders, beide configuratieparsers en het gedrag van het timerwiel; de CI-taak voor Kani blokkeert daarom nog niet. Miri kan geen assembly uitvoeren. Toeleveringsketen (H9): een CycloneDX-SBOM met 215 componenten, cargo-vet slaagt met 39 volledig beoordeelde en 140 uitzonderingen, en cargo-deny is zo geconfigureerd dat advisories over kwetsbaarheden als CI-fout tellen (die CI-taken zijn tot nu toe alleen lokaal gecontroleerd, niet op GitHub, en de negatieve test is niet uitgevoerd), plus VULNERABILITY-HANDLING.md. De eerlijke stand: van 67 kernel-gelinkte versies van crates van derden zijn er 53 uitzonderingen en geen beoordelingen. Vet bewijst dat de verzameling afhankelijkheden niet zonder zichtbaar verschil kan veranderen, niet dat de TCB is nagekeken. Een eigen beoordeling van geen enkele crate hebben we geschreven.

SNTP (T1) is in dat opzicht een klein veiligheidsverhaal: het is optioneel, alleen naar privé-IPv4-servers, met een maximale sprong en de voorwaarde dat de bronnen het eens zijn (mediaan, meerderheid binnen één seconde). Een klok die iedereen op het pad kan verzetten, is geen klok die we mogen vertrouwen bij de geldigheid van certificaten.

Op de Mac: aarch64 native en x86_64 via emulatie

We ontwikkelen op een Mac, en die heeft twee manieren om dezelfde code uit te voeren, die erg verschillend zijn.

De regel is eenvoudig: cijfers onder TCG zijn emulatie en die citeren we niet als prestaties. x86-prestaties meten we alleen op een echte VPS. Daarom komen de cryptografiecijfers hierboven van de Contabo-VPS en niet van de Mac.

Lessen

• Meet op een echte machine voordat je optimaliseert. Onze eerste aanpak was optimaliseren wat we traag dachten te zijn; pas de diagnostiek op de VPS liet 1,2 ms zien en waar de tijd precies heen gaat.
• Overbelasting is een aparte eigenschap. Een systeem dat onder belasting snel is, kan erboven instorten; weigeren moet goedkoper zijn dan accepteren.
• Het profiel verrast. De grootste afzonderlijke winst voor kleine berichten zat niet in de cryptografie maar in het kopiëren van geheugen.
• Een schijf zonder bestandssysteem vraagt meer werk, niet minder. Wat een bestandssysteem normaal biedt (uitlijning, groei, discard, kopieën, controles) moeten we zelf schrijven en controleren, elke stap met foutinjectie.
• Eerlijkheid in cijfers. Geheugenmetingen op een gedeelde VPS variëren tot 10 keer tussen runs en zeggen niets over de code, dus noemen we ze niet. De cryptocijfers zijn stabiel tot ongeveer 10%.
• Ontwikkelsnelheid is geen rijpheid. Tests en ADR's groeien mee met de code, maar vier dagen zijn geen echte productie.

Wat volgt

• H6: SQLite geïsoleerd op EL0-niveau, zodat een fout in de database de kernel niet openzet.
• H7: de rest van de tijdveiligheid (NTS en het afhandelen van sprongen); SNTP is slechts een eerste stap.
• X11: vergelijking met Linux en Mosquitto op dezelfde VPS, pas dan is het zinvol om over relatieve snelheid te praten.
• Release: de eerste openbare release voor VPS (KVM), met ondertekende artefacten en instructies.
• Na de release: bare metal (X12 tot X16), IOMMU en Secure Boot, en schijfversleuteling.

De code staat op github.com/zeljan-alduk/urMQTT, en docs/PROGRESS.md blijft de enige bron van waarheid over wat er werkelijk werkt. Pre-alfa, net als eerder; foutmeldingen en beveiligingsmeldingen volgens de instructies in SECURITY.md zijn welkom.

Zo is urMQTT ontstaan: een unikernel die zelf de MQTT-broker is. Kernel, TCP/IP, TLS 1.3, MQTT en een ingebouwde database in één Rust-binary die vanaf één ISO wordt gestart. Geen processen, geen systeemaanroepen, geen shell. Het eerste platform waarop het wordt gebouwd en getest is aarch64, en dezelfde code gaat richting x86_64, via UEFI en klassieke BIOS, en richting echte hardware: het doel is één ISO die op al die platformen opstart. Het project is open source onder de licentie MIT of Apache 2.0, en in dit artikel leggen we vast waar we staan, hoe het van binnen in elkaar zit en wat we onderweg hebben geleerd.

Wat "unikernel" precies betekent

Een gebruikelijke broker is een programma dat op een besturingssysteem draait. urMQTT heeft geen besturingssysteem onder zich: het start zichzelf op via UEFI-firmware en de Limine-bootloader, zet eigen paginatabellen op, programmeert de interruptcontroller en de timer, vindt virtio-apparaten via PCIe, krijgt een adres via DHCP en luistert op één poort. Alles wat normaal door de kernel, de stuurprogramma's, de netwerkstack en de applicatie wordt gedaan, is hier één ELF dat op EL1-niveau draait.

Een vergelijking met een typische installatie zegt genoeg:

De prioriteiten zijn, in deze volgorde: veiligheid, schaalbaarheid, multicoreprestaties, kleine footprint en een onveranderlijke installatie. Wanneer twee doelen botsen, wint het doel dat hoger op deze lijst staat.

Waar we nu staan

Het project bevindt zich in de pre-alfafase, maar zeventien ontwikkelmijlpalen, van M0 tot en met M17, zijn afgerond. Vandaag bedient urMQTT MQTT 3.1.1 over TLS 1.3 met verplichte clientcertificaten en bewaart het zijn toestand in SQLite op een rauwe schijf. In het kort wat al werkt:

• Kernel: eigen exceptievectoren met gedecodeerde rapporten, eigen paginatabellen met afgedwongen W^X, guard pages, PAC en BTI waar de processor ze heeft, GICv3 en GICv2, generieke timer, SMP tot 64 cores.
• Hardwaredetectie uit DTB of ACPI naar één platformbeschrijving, met een identiek resultaat uit beide bronnen.
• Stuurprogramma's: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi en virtio-rng, plus een CSPRNG die met hardware-entropie wordt geïnitialiseerd.
• Netwerk: eigen DHCPv4, ARP, ICMP en strikt IPv4, daarnaast een eigen TCP alleen voor de serverkant: SYN-cookies, hiërarchisch timerwiel, NewReno, samenvoegen van ACK's, geen TIME_WAIT-toestand.
• TLS: alleen TLS 1.3, verplichte mTLS, apparaatidentiteit uit de CN of de SAN-URI; de handshake wordt door rustls afgehandeld, daarna volgt een eigen recordlaag met AES-128-GCM en ChaCha20-Poly1305. Sessiehervatting met PSK-tickets, een intrekkingslijst, toelatingscontrole al tijdens de handshake.
• MQTT: codec zonder kopiëren, gefuzzd en getest met echte mosquitto-clients; QoS 0 en 1, wildcards, retained berichten, last will (LWT), persistente sessies, ACL met beperking tot devices/{id}/#, snelheidslimieten per apparaat.
• Opslag: SQLite in de kernel via een VFS bovenop een rauwe schijf, in WAL-modus, met een integriteitscontrole bij het opstarten; apparaatregister, intrekkingen, retained berichten, persistente sessies met berichtenwachtrijen voor offline apparaten; per core een afzonderlijk telemetriejournaal met een CRC per record en herstel na een crash.
• Bedrijf en bewaking: een watchdogtimer voor handlers, een gezondheidscontrole, begrensde logging, syslog en statsd via UDP, een toelatingslaag die stormen van heropgebouwde verbindingen overleeft.
• Oplevering: bitgewijs identieke herbouwen, gecontroleerd in CI, ISO en rauw GPT-schijfimage, minisign-handtekeningen, handleidingen voor KVM, Proxmox en Hetzner.

Elke stap is gemarkeerd met de mijlpaal die hem heeft opgeleverd, en het bestand docs/PROGRESS.md in de repository is de enige bron van waarheid over wat er werkelijk werkt.

De architectuur in drie plaatjes

Het volledige ontwerp staat beschreven in docs/ARCHITECTURE.md, en de redenen achter elke belangrijke beslissing zijn vastgelegd als ADR's in docs/DECISIONS.md. Hier volgt een overzicht.

Lagen

Van boven naar beneden: de broker (sessies, onderwerpenboom, QoS, retained berichten, last wills, ACL, limieten), de MQTT-codec, TLS, TCP, de netwerklaag en dan de stuurprogramma's. Naast dat hoofdpad staat de opslag (SQLite en het telemetriejournaal), en onder alles het geheugenbeheer, de platformdetectie en de configuratie die tijdens de build in constanten is omgezet, samen met het ingebouwde CA-certificaat, het servercertificaat en de sleutel. De hypervisor met de virtio-apparaten is het enige wat buiten de image valt.

Eén thread per core, geen gedeelde toestand

Elke datacore draait een eigen lus met een eigen TCP-stack, eigen TLS-toestanden, een eigen deel van de broker (sessies en onderwerpenboom), een heapcache en een telemetriepartitie. De cores delen geen enkele veranderlijke toestand, alleen begrensde lock-vrije ringen, één voor elk geordend paar cores. De hoogste core draait SQLite en niets anders.

De netwerkkaart heeft op dit moment één paar wachtrijen, dat door core 0 wordt beheerd. Die stuurt elke MQTT-stroom op basis van de Toeplitz-hash van zijn viertal naar een van de werkcores en verstuurt wat de werkcores teruggeven. Een sessie leeft op haar thuiscore, bepaald door de hash van de client-ID, zodat overname, last wills en persistentie nooit cores overschrijden. Een verbinding die op een andere core terechtkomt, houdt daar haar TCP en TLS en stuurt gewone MQTT door naar de thuiscore, met flowcontrol op basis van credits. Elk doorgestuurd bericht wordt bovendien verspreid naar de overige delen van de broker, die elk een replica van de retained berichten bijhouden.

Drie regels houden dat model bijeen. Run-to-completion: een ontvangen pakket wordt volledig op één core afgehandeld, van TCP via TLS-ontsleuteling ter plekke, MQTT-parsing en routering tot het versleutelde antwoord, zonder taakwachtrijen en zonder kopieën naar applicatiebuffers. Adaptieve polling: onder belasting worden de ontvangstwachtrijen actief gepold, en in rust keert de core terug naar interrupts en WFI; interrupthandlers bevestigen alleen de interrupt en markeren werk. Watchdogtimer: een tik van 10 ms per core vangt handlers op die hun budget overschrijden.

Het leven van één PUBLISH

Het apparaat verstuurt een TLS-record. De netwerkkaart geeft het via een descriptor zonder kopiëren aan de lus van de core. De lus controleert TCP, ontsleutelt TLS ter plekke en parset MQTT uit de geleende buffer, en controleert daarna in het geheugen de ACL, de snelheidslimiet en het pad door de onderwerpenboom. Als een andere core in dat onderwerp geïnteresseerd is, krijgt die een routeringsbericht met een verwijzing naar de payload en de onderwerp-ID; de database krijgt een telemetrierecord of een update van een retained bericht, gebundeld. Het PUBACK-antwoord wordt rechtstreeks in de uitgaande buffer versleuteld en samengevoegd met de TCP-ACK, zodat er één segment naar het apparaat gaat. Voor een andere core kost het bericht één versleuteling per abonnee op het moment van verzenden.

Wat een verbinding kost

Het doel is maximaal 512 bytes per inactieve TLS-verbinding, met 256 als streven. Zolang een verbinding rust, wordt er niets voor haar in een buffer bewaard: ontvangen gegevens worden rechtstreeks uit het netwerkframe verwerkt, en de buffers voor verzenden, records en MQTT bestaan alleen zolang er iets onafgemaakt of onbevestigd is. De kernel meet dat zelf: exacte heaptellers in gevraagde bytes en in de blokken die ze innemen, elke tien seconden vastgelegd als heap boven het basisniveau per open verbinding.

Gemeten onder HVF met vier virtuele cores, waarvan drie werkcores, waarbij elk apparaat een mTLS-verbinding en één abonnement met QoS 1 vasthoudt, inclusief afronding door de allocator:

De pool met netwerkframes is vast ongeveer 2 MiB groot, wat neerkomt op circa 200 B per verbinding bij tienduizend verbindingen en circa 2 B bij een miljoen. Verder konden we niet meten: de gebruikersnetwerkmodus van QEMU op macOS accepteerde bij 10.197 geen verbindingen meer, ongeveer op de grens van 10.240 descriptors van het QEMU-proces. Het getal daalt naarmate de vaste delen over meer verbindingen worden verdeeld, en groeit dus niet met hun aantal.

Het beveiligingsmodel

Veiligheid is de eerste prioriteit en wint alle conflicten met de andere doelen. Het model heeft meerdere lagen:

• Eén poort. TCP 8883, alleen TLS 1.3, verplichte clientcertificaten die zijn ondertekend door de in de image ingebouwde CA. De MQTT-client-ID moet gelijk zijn aan de apparaat-ID uit het certificaat.
• Geen ingang. Geen shell, geen console-invoer, geen SSH, geen beheer-API, geen dynamische code, geen via het netwerk bereikbare SQL en geen bestandssysteem.
• Geheugenveiligheid. Rust, met forbid(unsafe_code) in de protocolpakketten; elk unsafe-blok heeft een // SAFETY:-commentaar dat door een lint wordt gecontroleerd, en bij externe invoer treedt er geen panic op: clippy verbiedt in de pakketten op het datapad unwrap, expect, indexering en panic!.
• Beperking van exploits. W^X wordt afgedwongen via de codering van descriptors en het bit SCTLR_EL1.WXN en bij elke start gecontroleerd. De paginatabellen zijn na het opstarten alleen-lezen, zonder beschrijfbare alias. De onderste helft van de adresruimte is uitgesloten. Elke stack heeft guard pages en exceptions draaien op een aparte stack. PAC en BTI worden ingeschakeld wanneer de processor ze ondersteunt, en dat wordt door smoke-tests gecontroleerd.
• Weerstand tegen misbruik. SYN-cookies; de toelatingslaag weigert nieuwe verbindingen, vóór enige cryptografie, wanneer de heap laag is, de database achterloopt, er per core of per bronadres te veel handshakes lopen of de handshake-snelheid te hoog is. Snelheidslimieten per apparaat, begrensde wachtrijen, een TCP-venster dat aan de tegendruk van de broker is gekoppeld, begrensde logging, een watchdogtimer en een gezondheidscontrole.
• Onveranderlijkheid. Configuratie, CA en serversleutel zijn in de image ingebouwd. Iets wijzigen betekent een nieuwe image.

Het dreigingsmodel is vastgelegd in docs/SECURITY.md.

Opslag zonder bestandssysteem

De gegevens leven op een aparte schijf, virtio-blk of virtio-scsi, waarop geen bestandssysteem staat. De indeling is minimaal en eigen:

LBA 0      [ superblok: magic · indelingsversie · uuid · regiotabel · CRC-32C ]
LBA 8, 16  [ tabel met bestandsgroottes, slots A/B (de nieuwste geldige wint) ]
LBA 64     [ SQLite-hoofddatabase ½ ][ SQLite WAL ⅛ ][ journaal 1 MiB ][ telemetriejournaal: 8 partities … ]
laatste 4 KiB [ ruimte voor de zelftest van het blokapparaat bij het opstarten ]

SQLite (gevendord 3.54.1, met controle van de hash tijdens de build) is met clang in de kernel gecompileerd, zonder standaardbibliotheek, en gebruikt een vaste memsys5-heap. Zijn VFS koppelt drie vaste bestanden aan schijfregio's. Het draait in WAL-modus met locking_mode=EXCLUSIVE, zodat het geen index in gedeeld geheugen nodig heeft, en met synchronous=FULL; als quick_check bij het opstarten een fout vindt, stopt het systeem veilig. In de database staan het apparaatregister, intrekkingen, retained berichten en persistente sessies met wachtrijen van QoS 1-berichten voor apparaten die niet verbonden zijn.

De core voor de database, die met het hoogste nummer, draait SQLite en niets anders. Het datavlak stuurt haar toestandswijzigingen via een lock-vrije SPSC-ring; zij bundelt ze elke 5 ms of elke 512 operaties in één transactie en stuurt de bevestigingen via een tweede ring terug. Een lege schijf wordt bij de eerste start geformatteerd; al het andere wordt nooit overschreven.

Telemetrie gaat langs een andere weg. Elke geaccepteerde PUBLISH op onderwerpen uit storage.telemetry_topics gaat naar de partitie van het telemetriejournaal van zijn core: een ring van segmenten met een CRC per record, gezouten met het volgnummer van het segment, zodat oude rondes van de ring nooit opnieuw opduiken. De cores geven records via een eigen ring zonder kopiëren aan de database door, die ze elke 5 ms of elke 256 KiB wegschrijft. Bij het opstarten behoudt het herstel elk weggeschreven record, snijdt het onvoltooide einde af en gaat verder in een nieuw segment. Bewaren gebeurt op grootte, via de ring, en op leeftijd, via retention_days. We hebben dit getest met een miljoen records en met kill -9 midden in het schrijven.

De cijfers

De belastingstool in tools/loadgen doet drie dingen: een storm van TLS 1.3-handshakes met mTLS en CONNECT, langlevende verbindingen met PINGREQ die elke seconde telemetrie publiceren, en reconnect-stormen. make bench op een Apple M4 Pro onder HVF geeft:

Het getal in de gast, waar client en server binnen dezelfde virtuele machine zitten en elke werkcore voor zichzelf werkt, laat zien dat het datavlak lineair schaalt. Het netwerkgetal wordt begrensd door het enkelvoudig-threadige gebruikersnetwerk van QEMU, niet door de gast; ook dat is vastgelegd als ADR-032.

Reconnect-stormen testen we door alle apparaten tegelijk te laten verbinden, geweigerde pogingen met uitstel te herhalen en ze daarna allemaal zonder DISCONNECT te laten wegvallen. De parameter heap_limit_mb= laat de toelatingslaag in de ontwikkelmodus de heap kleiner inschatten dan hij is, zodat een storm die groter is dan de heap met weinig sockets kan worden uitgeprobeerd. In één zo'n ronde met 3.000 apparaten maakten er 1.368 verbinding in 36 seconden, en 5.619 pogingen werden netjes geweigerd, met een limiet van 8 MiB; na de storm keerde het geheugen terug.

Hoe we werken

Het project wordt geleid door een geschreven specificatie, PROMPT.md, met een mijlpalenplan, en elke mijlpaal eindigt met hetzelfde ritueel: make check en make smoke groen, één commit met het label M<n>, een aantekening in docs/PROGRESS.md en een ADR voor elke beslissing die niet vanzelfsprekend is. De regels zijn kort en we onderhandelen er niet over: geen panic bij externe invoer, unsafe alleen in hardware- en FFI-pakketten en altijd met commentaar, geen allocaties op het hete pad, commentaar bij elke volgorde van atomaire operaties, elke limiet komt uit de configuratie, en bewuste tijdelijke onderdelen falen luid.

CI doet meer dan wij met de hand zouden halen: fmt, clippy voor de host en voor aarch64-unknown-none, typos, actionlint en shellcheck; tests op Linux en macOS op arm64; een build van de kernel voor de ontwikkel- en productieconfiguratie met de grootte van de ELF in de samenvatting; opstarten onder QEMU met alle smoke-testscenario's en het bewaren van seriële logs; cargo-deny voor advisories, licenties en bronnen; een minuut fuzzing per elk van de elf doelen, en 's nachts tien minuten per doel met een gecachet corpus. Daarnaast CodeQL, OpenSSF Scorecard, Dependabot en publicatie met SLSA-herkomst. Elke actie van derden is vastgezet op een volledige commit-SHA.

Reproduceerbaarheid nemen we letterlijk: make repro bouwt HEAD tweemaal in verse werkbomen en vergelijkt de ELF, de ISO en het rauwe image byte voor byte. Releases zijn ondertekend met minisign en de artefacten kunnen worden gecontroleerd met gh attestation verify. De productie-image bevat de privésleutel van de server, dus de ISO zelf is een geheim; de images bij de releases op GitHub zijn ontwikkelimages, met tijdelijke sleutels, en dienen alleen om te proberen.

Wat we hebben geleerd

Een paar lessen die het plan hebben veranderd:

• Een eigen TCP bleek toch de moeite waard. Het prototype draaide op smoltcp en heeft ons tot en met M13 goed gediend. Maar een server die honderdduizenden verbindingen vasthoudt, heeft geen client-TCP nodig, maar SYN-cookies, een timerwiel en een toestand van 96 bytes. In M14 hebben we smoltcp vervangen door een eigen stack alleen voor de serverkant, met tests met gesimuleerd pakketverlies en fuzzing van segmenten.
• Meet het geheugen van binnenuit. Schattingen per verbinding waren nutteloos totdat de kernel zelf de heap ging tellen in allocatorblokken in plaats van in gevraagde bytes. Pas toen zagen we waar die 512 bytes werkelijk blijven en kwamen we uit op 494.
• Testgereedschap is deel van het product. De grootste beperking was niet de kernel, maar de gebruikersnetwerkmodus van QEMU en het aantal efemere poorten op de ontwikkelcomputer. Voor honderdduizend verbindingen of meer heeft u vmnet-shared op macOS nodig, of Linux met KVM, een tap-interface en meerdere clientadressen.
• SQLite zonder besturingssysteem is mogelijk, maar alleen onder strenge voorwaarden: een vaste heap, exclusieve vergrendeling zonder gedeeld geheugen, een VFS die niets van bestanden weet, en een toelatingslaag die de database niet laat achterlopen.
• Reconnect-stormen zijn de normale toestand, geen uitzondering. Wanneer een mobiel netwerk uitvalt en terugkomt, kloppen duizenden apparaten tegelijk aan. Daarom weigert de toelatingslaag een verbinding vóór enige cryptografie, en kost elke geweigerde verbinding vrijwel niets.

Wat volgt

Het werk na M17 is in drie richtingen gepland, en de volgorde daartussen staat in docs/PLAN.md. Niets hiervan is al gebouwd.

• Eén ISO voor meerdere platformen. Hetzelfde bestand urmqtt-<env>-<versie>.iso en één rauw GPT-image die opstarten op aarch64 UEFI, x86_64 UEFI en x86_64 BIOS, in virtuele machines en op echte hardware, te beginnen met één Intel-pc. Nog steeds een appliance met alles erin, reproduceerbaar en ondertekend.
• Rauwe schijf, zonder bestandssysteem. Een formaatspecificatie op byteniveau, de hosttool urmqtt-disk die de parsers met de kernel deelt, uitlijning van regio's op 1 MiB, groei van de schijf met de gegevens, discard voor thin-provisioned schijven, A/B-snapshots van de database, bitcontrole en, naar keuze, versleuteling met AES-256-XTS met hardware-AES.
• Aantoonbaar veilig. Intrekking en een lijst met toegestane apparaten tijdens bedrijf via een ondertekend controlekanaal, zonder nieuwe image; differentiële tests en conformiteitstests van de eigen TLS en TCP; KASLR, stackbescherming, kCFI, MTE en een geharde allocator; SQLite geïsoleerd op EL0-niveau; Secure Boot; SBOM en cargo-vet; en tot slot een pakket voor een externe audit.

Platformen die alleen niet-virtio-apparaten aanbieden, zoals AWS ENA of Azure MANA, worden voorlopig niet ondersteund. Raspberry Pi 4 en 5 als KVM-host, Hetzner CAX en Oracle Ampere A1 zijn gedocumenteerd en in code ondersteund, maar nog niet getest op een echte dienst.

Probeer het uit

De repository staat op github.com/zeljan-alduk/urMQTT. Met Rust met een vastgezette nightly-toolchain en QEMU zijn make certs, make run en één mosquitto-client genoeg voor de eerste PUBLISH over mTLS op uw eigen computer. De waarschuwing van het begin geldt ook aan het eind: dit is pre-alfa, en alles wat werkt staat in docs/PROGRESS.md. Foutmeldingen, vragen over het ontwerp en beveiligingsmeldingen volgens de instructies in SECURITY.md zijn welkom. Over elke volgende mijlpaal laten we hier van ons horen.

Op dit blog schrijven we op wat we onderweg hebben geleerd. Geen marketingteksten, maar concrete notities: wat er misging, hoe we het hebben opgelost en wat we vandaag anders zouden doen.

Waarover we gaan schrijven

• Tariefinning in het openbaar vervoer. Contactloze kaarten, SAM-modules, offline werken en alles wat een terminal moet doorstaan in een voertuig dat twaalf uur per dag schudt.
• Mobiele apps in het veld. Android en Flutter op apparaten die geen gewone telefoons zijn: met kaartlezers, printers en accu's die een hele dienst moeten volhouden.
• Backend en vlootbewaking. Hoe je weet dat een apparaat in een voertuig een probleem heeft voordat de chauffeur het meldt.
• Hardware. Van een prototype op de werkbank tot een printplaat die in serieproductie gaat, en alle fouten daartussen.
• Lokale AI-modellen. Waar modellen op eigen hardware zinvol zijn, en waar de cloud en een API gewoon de betere keuze zijn.

Hoe we gaan schrijven

Kort en concreet, met code en cijfers waar we die hebben. We publiceren als we iets te zeggen hebben, niet volgens een schema. De berichten worden in het Kroatisch geschreven en vertaald naar alle talen van deze site; via RSS blijft u op de hoogte.

Interesseert een onderwerp u, of werkt u aan een vergelijkbaar probleem? Schrijf ons op info@aldo.tech.