Poznámka vopred ostáva rovnaká: projekt je pred-alfa, prvé vydanie je len pre VPS s KVM a čísla merajú kód, testy a určité pokusy, nie zrelosť v produkcii.

Ako to vyzeralo v čase

Od predchádzajúceho textu (31.10. o 23:00) do dnes (1.11. o 20:41) pribudlo v repozitári 59 nových commitov, spolu 178. Všetky vznikli v jednom kalendárnom dni, takže platí rovnaké upozornenie ako predtým: projekt sa buduje s Claude Code (commity nesú Co-Authored-By: Claude), plán, kód, testy a ADR vznikajú v krátkych uzavretých slučkách a čísla nižšie hovoria o množstve kódu a overovaní, nie o tom, koľko ľudskej práce v nich je.

Čísla sú vypočítané rovnakou metódou ako v minulom texte: všetky súbory .rs mimo vendor/ a fuzz/, funkcie #[test], nadpisy ## ADR- v docs/DECISIONS.md.

Pracovalo sa paralelne na viacerých vetvách, takže poradie commitov nie je presne poradím práce. ADR sú číslované až do 232, ale číslovanie má medzery (časť sa pri zlučovaní vetiev premenovala); počítame nadpisy, nie najvyššie číslo. Vydania: v0.2.0 (1.11., 18:45 UTC) a v0.2.1 (1.11., 20:22 UTC), obe označené ako pre-release.

H6: SQLite v používateľskom režime

Čo sme plánovali. SQLite je 254 268 riadkov C, ktoré parsujú databázu, WAL a žurnál z disku, a disk môže byť vyrobený alebo zmenený. Dovtedy bežal v jadre, s právami jadra. Čo sme postavili (ADR-210 až ADR-212): SQLite, jeho časti libc a heap sa presunuli do samostatného programu, dbworker, ktorý beží na EL0 (aarch64), resp. ring 3 (x86_64), vo vlastnom adresnom priestore. Jadro už SQLite nelinkuje. Worker komunikuje s jadrom cez spoločné okno pamäte a dvanásť systémových volaní a každá dĺžka a posun, ktoré sa vrátia, sa pred použitím kontrolujú. Chyba vo workeri (nepovolený prístup, nedefinovaná inštrukcia, prekročený časový rozpočet 30 s) ukončí volanie, worker sa znova spustí a databáza sa otvorí z WAL ako pri zavádzaní; po 5 opätovných spusteniach za minútu sa úložisko vyhlási za chybné a nespúšťa sa donekonečna.

Cena, nameraná na aarch64 pod HVF, tá istá VM, jadro so zabudovaným SQLite oproti jadru s workerom, šesť striedavých spustení každého:

Zápisy na disk (1 572) a flushe (319) sú identické, ako to má byť. Toto nie je izolované: jadro stále verí tomu, čo worker vráti, po kontrole tvaru. Kompromitovaný worker môže klamať (napríklad vrátiť prázdny zoznam zrušených certifikátov a tým ich „odrušiť"), ale nemôže čítať pamäť jadra, kľúče TLS ani kľúče tiketov. Nie je tu KPTI, takže úniky typu Spectre/Meltdown nie sú zabránené a nič o nich netvrdíme; kľúč PAC zdieľajú EL0 a EL1. Na x86_64 sme cenu prepínania na KVM nemerali (pod TCG by bolo číslo nezmyselné) a samotné fuzzovanie workera a protokolu nie je hotové. Súbor testov pre úložisko (79 scenárov, každý točí SQLite vo workeri) prechádza na aarch64 HVF a x86_64 TCG, na aarch64 TCG 76 (jeden sa preskakuje, lebo TCG nemá MSI-X).

H7 je uzavretý, ale nie tak, ako sme ohlásili. Dolná hranica času (ADR-050) a SNTP s konsenzom (T1) pokrývajú rozsah H7; NTS (RFC 8915) ostáva mimo rozsahu a je zapísaný ako zvyškové riziko, nie ako niečo, čo funguje. Nepovažujeme bezpečnosť času za „vyriešenú", ale za hotovú v jej dokázateľnej časti.

Nová sieťová možnosť. Contabo nedáva DHCP vlastnému ISO, takže VPS dovtedy potreboval iný obraz než laboratórna VM. Teraz network.mode = "auto" (ADR-214) najprv sa opýta DHCP a ak prenájom nepríde v danej lehote (dhcp_timeout_s, predvolene 15 s) alebo ho stratí, použije zadanú statickú adresu. Vyskúšané ručne na QEMU (s DHCP použije prenájom, bez siete sa po 5 s vráti na statickú adresu); smoke scenár na to ešte nie je.

X11: porovnanie s Mosquittom na tom istom VPS

Rovnaký druh stroja ako v minulom texte (Contabo, 4 vCPU AMD EPYC, 8 GiB), záťaž z linuxového hostiteľa vzdialeného 15 ms, vzájomné TLS 1.3 s rovnakými certifikátmi na oboch stranách, Mosquitto 2.0.21 na Debiane 13 bez trvanlivosti. Metóda a rozhodnutia sú v ADR-213, surové dáta v docs/perf-results/. Medián z troch spustení.

Čo to znamená a čo nie. Podania rúk sú dolné hranice pre oba servery: generátor záťaže je zdieľaná VM s 60 až 70% ukradnutého procesorového času a pri 128 vláknach bol blízko vlastného limitu, kým pracovné jadrá urMQTT boli zaneprázdnené iba 12 až 13%. Pomer pri 128 klientoch (približne 2,2-krát) je najzmysluplnejší; pri 32 a 64 väčšinou meria čakanie klientov. Čísla pamäte nepočítajú to isté (halda jadra oproti RSS procesu), takže „približne 50-krát menej" je rádovo, nie presný pomer. Latencia 14 ms je jedno kolo siete (približne 15 ms), teda „žiadny merateľný čas brokera"; chvosty (p99 približne 100 až 200 ms) sú pri oboch brokeroch ovládané zdieľanými hostiteľmi. Rozdiely pod približne 20% netvrdíme.

Čo nešlo v náš prospech a zostalo v tabuľkách: jeden TCP tok cez urMQTT niesol 2 až 8-krát menej než cez Mosquitto, so zmenami od nuly do 7,7 tisíc správ za sekundu medzi spusteniami, a 20 ms watchdog handlera prerušoval živé spojenia, keď hypervízor zastavil vCPU (v produkčnom nastavení action = "drop", 6 až 8 spojení na spustenie pri zaplavení QoS 0). Obe veci sú opísané v ďalšej časti, lebo mali príčiny v našom kóde.

Prečo bol jeden tok pomalý: príčiny, nie výhovorky

Najjednoduchšie by bolo povedať „zdieľaný VPS". Nepovedali sme to, ale pri tom istom VPS a tej istej metóde sme hľadali príčiny. Našlo sa ich päť, štyri v dátovej ceste a jedna vo watchdogu (ADR-221 až ADR-224):

Zastavenia sú skutočné: na tomto VPS mali jadrá 0 až 2 medián 36 až 80 oneskorených tikov za 5 sekúnd a najhoršie zastavenie v okne bolo v mediáne približne 70 ms a až 0,9 s (jadro 3, databáza a žurnál: až 1,55 s), kým hostiteľ nehlási ukradnutý čas (host steal 0 us). Preto watchdog potreboval druhé hodiny, nie väčší rozpočet.

Watchdog: 148 prerušených spojení v 30 zaťažených spusteniach predtým, 0 v 24 spusteniach potom; na lokálnom zariadení, ktoré oneskoruje a stráca rámce, má pri strate 0,1% jeden tok 64 B s 14,3k správ/s (jadro X11) teraz 41,0k, a pri 0,5% 5,0k namiesto 17,7k.

Čo toto nehovorí. urMQTT stále nie je rýchlejší než Mosquitto na jednom toku: pri 64 B publikuje približne 80% jeho rýchlosti a doručuje približne 40%, lebo zahadzuje QoS 0, keď je tok odberateľa pomalší než tok vydavateľa (Mosquitto bez hranice zaraďuje do radu). Pri 1 KiB v 16-párovom zaplavení je Mosquitto popredu približne o 15%, čo je v rámci šumu. Generátor bol znova zdieľaná VM s 58 až 77% ukradnutého času. Druhé kolo (zamykanie haldy mimo dátovej cesty, SACK na strane odosielania a ďalšie) je na neintegrovanej vetve perf-single-flow-wip; jeho čísla zatiaľ nie sú tvrdenia a neuvádzame ich tu.

Sľub, ktorý sme nedali, ale splnili sme ho: konfigurácia je dáta

Doteraz bola každá konfigurácia novým zostavením: kľúče a limity boli zabudované v obraze. C1 to obracia (ADR-215 až ADR-219): jadro sa zostavuje raz a konfigurácia sú dáta.

• Blob urmqtt-cfg (C1a): verzovaný, kanonický zápis (polia podľa rastúcich značiek, odtlačok SHA-256, voliteľný oddelený podpis Ed25519), 70 polí s predvolenými hodnotami a hranicami, dekodér, ktorý odmieta všetko chybné.
• Jadro ho číta ako modul Limine (C1b), pred čímkoľvek iným, na aarch64 a x86_64. Existuje jedno vydané jadro pre každé ENV okrem dev (ELF-y aarch64 pre release, prod a bench majú rovnaké SHA-256; overené iba na aarch64). Vydané jadro odmieta vývojovú konfiguráciu a bez konfigurácie napíše „refusing to serve" a nič neposkytuje.
• Nainštalovaný disk nesie konfiguráciu a aktualizácia ju zachováva (C1c).
• urmqtt-config a šablóna ISO (C1d): pack, show, verify, a pack --iso nahrádza obe kópie miesta pre konfiguráciu a 24 súhrnov modulov v hotovom ISO. Výsledok je bajt po bajte rovnaký ako ISO, ktoré zostavuje mkiso.sh --config. Šablóna vydania v0.2.0 má 63 111 168 bajtov.
• Vyhlásenie o dôvere (ADR-219): nakonfigurovaný obraz pri zavádzaní vypíše odtlačok konfigurácie (config: fingerprint ...) a podpis je voliteľný a predvolene vypnutý. Zmenené ISO nemá oficiálny súhrn; odtlačok je spôsob, ako vidieť, čo je v ňom.

Zostavovač na aldo.tech

To isté, čo robí urmqtt-config pack --iso, robí aj webová stránka, tým istým kódom: knižnica nástroja preložená do WebAssembly (1,06 MB, bez importov a bez bloku unsafe). Stránka je na aldo.tech/sk/produkty/urmqtt-builder/ a existuje vo všetkých 15 jazykoch stránky (napríklad hr).

• Nič neopúšťa prehliadač. Certifikáty, súkromné kľúče a hotové ISO ostávajú v počítači; stránka sťahuje iba súbory vydania z tohto miesta, nie je tu sledovanie ani skripty tretích strán. V teste naživo žiadna požiadavka nenies kľúčový materiál.
• Zrkadlo vydaní (ADR-227): hodinu po hodine (systemd timer, nízka priorita) kopíruje vydania z GitHubu, každé skontroluje pred zverejnením a stránka v prehliadači overuje podpis SHA256SUMS kľúčom zabudovaným v stránke, a až potom zapíše konfiguráciu do šablóny. Neúspešná kontrola blokuje stiahnutie.
• Jednoducho podľa predvoleného, pokročilo podľa potreby (ADR-232): prvá obrazovka sú tri kroky (kde to pobeží, vaše certifikáty, názov obrazu). Jedno pole na pretiahnutie súborov roztriedi certifikát, kľúč a CA podľa obsahu. Pokročilé zobrazenie otvára každé zo 70 polí, vyhľadávanie, import a export TOML; obe zobrazenia upravujú rovnaký stav. Šablóna (63 MB) sa sťahuje, kým používateľ vypĺňa formulár. V skúške naživo, so skúšobným zrkadlom a skúšobným kľúčom, zostavenie ISO v prehliadači trvalo 5 až 18 s.

Emulátor, voliteľne. Vedľa „Stiahnuť ISO" stojí „Vyskúšať v emulátore": QEMU preložené do WebAssembly spustí práve zostavený obraz v karte prehliadača. Nič z neho sa nesťahuje pred kliknutím (približne 3 MB prvýkrát). Emulátor je len BIOS, bez siete (aby prevádzka používateľa neprešla cez nejakého sprostredkovateľa a nenarušila „nič neopúšťa prehliadač"), vyžaduje približne 1,5 GB pamäte a počítačový prehliadač (testovaný Chrome; Firefox a Safari nie). V ňom urMQTT dosiahne URMQTT READY približne za 8 s (s preskočeným odpočítavaním) a vypíše rovnaký odtlačok konfigurácie ako stránka, čo je dôkaz, že sa zaviedla práve tá konfigurácia. Zavedenie je približne 2-krát pomalšie než pôvodné QEMU na tom istom Macu (0,82 s oproti 1,9 s) a kryptografia približne 58-krát pomalšia, lebo hardvérové inštrukcie sú emulované. Preto z emulátora nevyvodzujeme žiadne tvrdenia o rýchlosti a stránka to hovorí pred spustením. Pri zostavení bolo treba záplatovať štyri bajty v .wasm kvôli chybe v preklade inštrukcie POPCNT v pôvodnom emulátore (ešte sme ju nenahlásili); samotný emulátor je pod GPL, s ponukou zdrojového kódu.

Obyčajný MQTT, len pre siete, ktorým dôverujete

Obyčajný MQTT (TCP 1883, bez TLS) je v IoT veľmi bežný: je predvolený v Mosquittu, vo väčšine firmvérov pre Arduino a ESP, v Tasmote, Zigbee2MQTT a Home Assistante a používa sa aj vo vnútri segmentovaných priemyselných sietí, za VPN a na súkromných LAN, ba aj na zariadeniach bez hodín (certifikáty vyžadujú dátum), bez dostatku flash pamäte alebo procesora pre TLS. Cez nespoľahlivú sieť neprichádza do úvahy: kto je na ceste, číta a mení prevádzku. Preto je P1 (ADR-229 až ADR-231) výslovná, obmedzená voľba, predvolene vypnutá, a port TLS ostáva; TLS sa tým nevypína, obyčajný port prichádza popri ňom.

• Zoznam povolených sietí je povinný (allow_from, CIDR) a kontroluje sa pri SYN: mimo zoznamu nie je SYN-ACK ani stav. Celý internet (0.0.0.0/0) vyžaduje samostatnú výslovnú možnosť.
• Tri spôsoby prihlásenia: heslo (predvolené, keď je zapnuté; PBKDF2-HMAC-SHA-256, soľ, 10 000 iterácií, porovnanie v konštantnom čase, zamykanie podľa adresy), anonymne (jedna nakonfigurovaná identita s vlastným ACL) a podľa adresy (ip). Zostavovač heslo rozptyľuje v prehliadači a v pamäti drží iba súhrn.
• Menej práv než mTLS: obyčajný klient nikdy nemá servisné, operátorské ani riadiace práva, nemá $SYS ani konzolu, má vlastné relácie ($plain/<identita>/<id klienta>, iba čisté), vlastné limity a register povolených ho stále zaväzuje.
• Čo sa stráca, je napísané v SECURITY.md: dôvernosť, integrita, autentickosť brokera a opakovanie zachyteného prihlásenia. To sa konfiguráciou nedá opraviť; tak to je bez TLS.

Namerané na laptope (Apple silicon, HVF, používateľská sieť QEMU), 16 párov, 64 B, tri spustenia po 10 s: pri 8 000 správach za sekundu TLS aj obyčajná cesta doručia všetky správy s rovnakou latenciou (p50 0,17 ms oproti 0,13 až 0,18 ms), nové spojenia za sekundu: TLS približne 2 600 až 2 750, anonymné obyčajné približne 4 900 až 7 800, a prihlásenie heslom je drahá časť: jeden PBKDF2 stojí približne 2,5 ms, takže počet nových prihlásení je obmedzený na približne 200 na dátové jadro za sekundu (namerané 308 až 342 na dvoch jadrách). Zaplavenie na tomto stroji nie je stabilný nástroj (20k až 440k doručených za sekundu medzi spusteniami) a z neho nevyvodzujeme záver. Porovnanie obyčajnej cesty s Mosquittom na VPS ešte nie je urobené. Testy: smoke skupina plaintext 7 zo 7 na aarch64 HVF a na x86_64 TCG, nový fuzz cieľ plain_input (2,3 milióna spustení bez nálezov).

Chyby, ktoré našla práca naživo

Dve veci neodchytili testy, ale prvé zapnutie na skutočnom mieste:

• Stránka hľadala súbory vydania o jeden adresár vyššie, takže každé overenie podpisu odpovedalo 404 (oprava 13af301). Test používal skúšobné zrkadlo na inej ceste.
• Klávesnica emulátora nikdy nedorazila k hosťovi: príčinou nebol zlý preklad kláves, ale to, že dialóg klávesy vôbec nepočúval (oprava v ADR-232, spolu so vstupom na zavedenie bez kláves).

Lekcie

• Hľadajte príčinu, neobviňujte prostredie. Väčšina slabín jedného toku a všetky prerušené spojenia boli naše; hypervízor je skutočný, ale bolo ho treba merať, nie predpokladať.
• Porovnanie s iným produktom musí zahŕňať aj straty. Tabuľka, v ktorej sú iba naše víťazstvá, by nebola porovnaním.
• Merací prístroj má hranice. Zdieľaný generátor so 60 až 70% ukradnutého času mení, čo čísla znamenajú; preto píšeme „dolná hranica" a netvrdíme rozdiely pod 20%.
• Izolácia nie je dôkaz. SQLite v EL0 zmenšuje, čo môže chyba v ňom, nie to, čo môže klamať.
• Skutočná inštalácia nájde to, čo testy nehľadajú: cestu, ktorá bola nesprávne poskladaná, a klávesy, ktoré nikto nepočúva.

Čo ešte nie je dokázané

• Podpisový kľúč vydaní je zatiaľ skúšobný kľúč; v0.2.0 a v0.2.1 sú pre-release a obrazy k nim sú vývojové so skúšobnými certifikátmi (okrem šablóny, ktorá je bez konfigurácie).
• 13 prekladov stránky zostavovača (a tohto textu) napísala AI a overili ich testy a vzorky, nie rodení hovoriaci.
• Porovnanie s Mosquittom je jedna relácia, jedna cesta a jeden zdieľaný generátor, na zdieľanom VPS; rozdiely pod 20% nie sú tvrdenia.
• Obyčajná cesta nebola meraná na VPS ani proti Mosquittu.
• Lighthouse na novom jednoduchom zobrazení nie je potvrdený (staré zobrazenie: dostupnosť 95 alebo viac).
• Bare metal, cena workera na x86_64 na KVM, Firefox a Safari pre emulátor: nemerané.

Čo bude ďalej

• D1: verejný demo broker. Emulátor z prehliadača nemôžeme sprístupniť verejne: žije v karte jedného návštevníka, je 20 až 100-krát pomalší než KVM, nemá prichádzajúcu sieť a zmizne so zatvorením karty; presmerovanie internetu do cudzieho prehliadača by bolo aj zneužitie. Možný je skutočný demo broker: urMQTT na VPS za menom na aldo.tech, so zverejnenou skúšobnou CA, prísnym ACL a malými limitmi. Je to zatiaľ len nápad, nie stavba, a vyžaduje výslovný súhlas na verejné vystavenie.
• Druhé kolo pre jeden tok (vetva perf-single-flow-wip): až keď bude namerané na VPS a zlúčené.
• Obyčajná cesta proti Mosquittu na VPS, prihlásenie a zrušenie účtu pre obyčajný MQTT cez podpísaný riadiaci kanál.
• Po vydaní: bare metal (X12 až X16), IOMMU a Secure Boot, šifrovanie disku.

Kód je na github.com/zeljan-alduk/urMQTT a docs/PROGRESS.md je naďalej jediným zdrojom pravdy o tom, čo skutočne funguje, docs/PERFORMANCE.md o tom, čo je namerané. Pred-alfa, ako predtým; hlásenia chýb a bezpečnostné hlásenia podľa pokynov v SECURITY.md sú vítané.

Jedna poznámka vopred: projekt je stále pred-alfa. Čísla v texte merajú kód a testy, nie zrelosť v produkcii, a prvé vydanie je zámerne obmedzené na VPS s KVM. Bare metal ostáva na neskôr.

Ako to vyzeralo v čase

Prvý commit vznikol 28. októbra 2026 o 23:48 (M0). Do 31. októbra do 23:00 má repozitár 119 commitov, rozložených ako 3, 39, 38 a 39 podľa kalendárnych dní. Hneď povedzme aj to, ako je to možné: projekt sa buduje s Claude Code a commity nesú trailery Co-Authored-By: Claude. Štyri kalendárne dni histórie neznamenajú, že jeden človek napísal za štyri dni 90 000 riadkov; znamenajú, že plán, implementácia, testy a ADR sa píšu v krátkych, uzavretých slučkách a každý krok sa končí rovnakým rituálom overenia ako predtým. Čísla nižšie hovoria o množstve kódu a testov, nie o tom, koľko z toho prešlo skutočnou prácou.

Graf ukazuje tri krivky, ktoré rastú takmer spolu, čo je zámer: testy a zapísané rozhodnutia idú popri kóde, nezaostávajú za ním. Sklon je najstrmší 29. októbra, keď vzniká celá cesta od jadra po broker. Neskôr sa riadky pridávajú pomalšie, ale testy rastú rýchlejšie než kód (27 testov na 1,6 tisíc riadkov na začiatku, 739 na 89,8 tisíc dnes).

Riadky sú všetky súbory .rs mimo vendor/ a fuzz/, testy sú funkcie #[test]. Čo ktorá časť pridala, podľa dátumu z histórie gitu:

Sľub 1: jeden ISO pre viac platforiem

Čo sme plánovali. Jeden súbor, ktorý sa zavádza na aarch64 UEFI, x86_64 UEFI a x86_64 BIOS. Čo sme postavili. Port na x86_64 (X0 až X10) a univerzálny ISO s bootloaderom Limine, jeden hybridný ISO, z ktorého sa zavádzajú všetky tieto kombinácie; dymové testy ho zavádzajú na štyroch virtuálnych strojoch. Ponuka má tri položky: urMQTT (živý režim, beží z RAM, nič nezapisuje na disk), inštalácia na disk počítača, na ktorom beží (inštalácia zapíše GPT a dáta a potom stroj vypne) a Diagnostika (detekcia hardvéru a merania).

Prvým skutočným cieľom bol VPS, nie fyzický počítač: rozhodli sme, že prvé vydanie podporuje len VPS (KVM) a bare metal príde po ňom. Testovali sme na VPS u Contabo s procesorom AMD EPYC (rodina 23, Zen 1), 4 vCPU a 8 GiB RAM, so sieťou virtio-net a diskom virtio-scsi. Prvý pokus nás prekvapil: ISO pripojený ako virtuálny CD zaviedol predvolenú položku, produkčný obraz odmietol bežať z média len na čítanie a resetoval sa, takže sme dostali nekonečnú slučku ponuka, jadro, reset bez čohokoľvek čitateľného. Dnes fatálna chyba v produkčnom obraze necháva správu na konzole 60 sekúnd pred resetom a z optického média vypíše, že sa zaviedlo z média len na čítanie, a zastaví sa. Živý režim v RAM (O3) neskôr tento problém pre bežný prípad obišiel.

Diagnostická položka vznikla z tejto skúsenosti: stroj, ktorý nevidíme, sa musíme vedieť opýtať, čo má. Vypíše CPU, RAM, sieť, disky a zariadenia PCI, zmeria priepustnosť pamäte, disk a kryptografiu a tie isté merania vypíše ako JSON na sériový port. Zapisovať na disk sa smie len do nepridelenej oblasti a až po zadaní WIPE; na snímke nižšie sa to preskočilo.

Čo je otvorené. Skutočný hardvér. Po prvom vydaní príde bare metal (zavádzanie z USB, NVMe a AHCI, sieťová karta skutočného počítača) spolu s IOMMU a Secure Bootom, lebo bez IOMMU môže škodlivé alebo chybné zariadenie zapisovať do celej pamäte. V tejto verzii o tom netvrdíme nič.

Podanie rúk: z 1,2 ms na 0,24 ms

Prvé meranie diagnostiky na VPS dalo nepríjemné číslo: podanie rúk mTLS, len kryptografia na strane servera, trvalo 1,2 ms. Na aarch64 sme už používali hardvérové inštrukcie AES a SHA, ale x86_64 nemal nič podobné pre verejný kľúč: RustCrypto je prenosný a constant-time, a teda aj pomalý. Znížili to tri zmeny.

• Pre P-256 sme prevzali asembler nistz256 z OpenSSL a ring (ADR-130), spolu s tabuľkami s pevnou bázou na podpisovanie a overovanie podpisov CA (ADR-110, ADR-111).
• X25519 bol prepísaný na štyri 64-bitové končatiny s inštrukciami MULX/ADX (ADR-131).
• Potom sme profilovali aj zvyšok (ADR-132, ADR-200).

Čísla sa medzi behmi líšia asi o 10%, preto sme zapísali rozsah namiesto jednej hodnoty. Spolu je to približne päťkrát menej času CPU na podanie rúk.

Čo sme sa naučili o memcpy. Keď kryptografia klesla, profil ukázal niečo, čo sme nečakali: funkcie mem* (memcpy, memmove, memset) zaberali 7% podania rúk, 13 až 39% cesty záznamu TLS (39% pre 64 B, 13% pre 4 KiB) a 17 až 34% rozdeľovania PUBLISH. Nahradili sme ich asemblerom SSE2 pre x86_64 (ADR-200), s diferenciálnymi testami voči referenčnej implementácii pre všetky veľkosti, zarovnania a prekrytia. Na volanie je to 55 až 75 cyklov oproti 7 až 12 pre 1 až 64 bajtov.

Čítanie grafu: čím menší záznam, tým väčšia časť času ide na kopírovanie, a preto je aj zisk väčší. Pre malé správy, ktorých je v premávke MQTT väčšina, to je to, na čom záleží.

Čo to neznamená. Na natívnom x86_64 sme OpenSSL 3.5.5 merali len ako referenciu pre asembler (ADR-130), nie ako porovnanie produktov. Porovnanie Linux plus Mosquitto na tom istom VPS (úloha X11) sme ešte neurobili. Preto netvrdíme, že urMQTT je rýchlejší než Linux: nie je to zmerané. Čísla vyššie porovnávajú urMQTT sám so sebou.

Preťaženie bolo druhým výsledkom. Na VPS, z jedného Macu (RTT 35 ms), 128 klientov dalo 618 podaní rúk za sekundu, 256 klientov 393 a 512 klientov 67, s tisíckami odmietnutých spojení. Nebola to plošina, ale zrútenie. Príčiny sme našli v kóde (dve sú potvrdené v QEMU/HVF, na VPS sa nedali zopakovať), viacero naraz: odmietnuté spojenie vracalo klienta cez ďalší segment, ktorý nesie platnú SYN cookie, odmietnutie pomocou RST hovorilo klientovi, aby to hneď skúsil znova, a príjem bol O(rad). Oprava (ADR-080 až ADR-082) zahadzuje SYN, ktorý by nebol prijatý, pamätá si odmietnuté toky, drží príjem v O(1) a počíta podania rúk na jadro. Je možné (hypotéza, neoverené), že časť príčiny bola aj na klientovi: nástroj na záťaž zatváral spojenie ako prvý, takže jeden Mac so 16 384 efemérnymi portmi a TIME_WAIT 30 sekúnd je obmedzený na približne 550 spojení za sekundu. Preto skutočný strop servera sme ešte nezmerali.

Sľub 2: surový disk, ale opatrný

Čo sme plánovali. Zachovať vlastné rozloženie bez súborového systému a pridať všetko, čo súborový systém inak dáva: zarovnanie, rast, discard, zálohy a kontroly. Prečo nie súborový systém. Diskutovali sme o tom a rozhodnutie sa potvrdilo: urMQTT zapisuje jednu databázu, jeden telemetrický denník a vlastné metaúdaje, nepotrebuje adresáre, oprávnenia ani názvy súborov, a každá ďalšia vrstva by bola ďalší kód v dôveryhodnej časti a ďalší spôsob, ako môže zápis ticho zmiznúť. Disk je GPT s partíciou ESP a jednou dátovou partíciou urMQTT, na ktorej je vlastné rozloženie.

Čo sme postavili (S2 až S6).

• Rozloženie v2 (S2). Topológia disku, zarovnanie na 1 MiB alebo optimálnu veľkosť I/O, celé fyzické bloky, pár superblokov A/B s generáciou (ADR-140). Rozloženie v1 jadro odmieta s jasnou správou a migruje ho offline nástroj urmqtt-disk migrate (ADR-141): predvolený je skúšobný prechod, kopíruje sa a až potom prepína, s návratom a vstrekovaním chýb pri každom zápise.
• Rast (S3). Pri zavádzaní môže disk rásť (nikdy sa nezmenšuje) a na virtio-blk aj počas behu, cez prerušenie zmeny konfigurácie (ADR-142, ADR-143).
• Discard a write-zeroes (S4). Tenko alokované disky vracajú miesto hostiteľovi. V teste klesol súbor qcow2 na hostiteľovi zo 62 na 16 MiB po vypršaní telemetrických segmentov a obnova nikdy neverí obsahu, ktorý bol zahodený.
• Záloha databázy na disku (S5). Kópia A/B pomocou online backup API SQLite v krokoch po 16 stránok: najdlhší krok 4,6 ms oproti 445 ms pri kopírovaní jedným volaním. Commity počas kopírovania mali maximum 2,4 ms oproti 2,2 ms bez nej. Ak quick_check pri zavádzaní zlyhá, databáza sa obnoví z kópie.
• Čistenie a obmedzené zavádzanie (S6). Scrubber číta disk s obmedzeným rozpočtom I/O a hlási poškodené záznamy, a zavádzanie číta len najnovší segment každého oddielu, takže čas zavádzania nerastie s veľkosťou telemetrickej oblasti. Tým sme uzavreli problém, ktorý sme vopred vypočítali: na veľkom disku by úplná obnova trvala od minút po desiatky minút.

Celá skupina dymových testov úložiska prechádza na oboch architektúrach: 79 úspešných, 0 neúspešných, na aarch64 pod HVF a na x86_64 pod TCG. Merali sme aj to, že S4 databázu nespomalil: 53,3 tisíc vložení za sekundu v dávkach pred aj po, bez meratelného rozdielu.

Čo prekvapilo. Koľko z „jednoduchého" rozloženia tvoria okrajové prípady: virtio-scsi a virtio-blk hlásia topológiu rôznymi spôsobmi a nedokončený zápis uprostred migrácie musí vždy zanechať aspoň jednu platnú verziu. Preto každý zápis na ceste migrácie a rastu prešiel vstrekovaním chýb.

Čo je otvorené. Stránky SQLite nemajú kontrolný súčet, takže zmenený bit vnútri hodnoty v riadku databáza neodhalí; telemetrické záznamy a obsah kópií majú CRC a odhalia sa. Šifrovanie disku (S7) nie je hotové.

Sľub 3: dokázateľne bezpečné, nakoľko sa nám to podarí

Spevnenie (H4). Alokátor maže uvoľnenú pamäť a kontroluje ju pri opätovnom použití, odhaľuje dvojité uvoľnenie, viaže ukazovatele voľného zoznamu cez XOR a pri uvoľnení nuluje kľúče (ADR-170). Ochrana zásobníka (-Zstack-protector=strong, 1315 funkcií, a SQLite s -fstack-protector-strong, ADR-171). Hlásenia o chybách v produkcii neobsahujú registre ani adresy (ADR-172). KASLR na oboch architektúrach: jadro je PIE a Limine ho posúva asi o 19 bitov, náhodne sa umiestňujú heap, zásobníky a okno MMIO (ADR-173). Na aarch64 MTE označuje heap (ADR-174), ale len pod TCG: HVF a x86 ho nemajú. kCFI sme posúdili a neprijali, lebo prekladač na pripnutom nightly padá s vnútornou chybou; IOMMU je odložený spolu s bare metalom (ADR-175, ADR-176).

Cena je zmeraná, nie predpokladaná. Na ceste podania rúk (dp-bench, aarch64 HVF, plné podania rúk TLS 1.3 + mTLS + CONNECT):

Celkovo je teda cena na ceste podania rúk približne 5% pre časti merané čisto, a s PIE a značkami vychádza okolo 7% na jednom a okolo 11% na štyroch jadrách, ale toto meranie je zašumené. Považujeme ju za prijateľnú, no neopakovali sme ju na VPS s x86_64.

Oplatí sa porovnať s číslom z prvého textu (862 podaní rúk za sekundu na jednom jadre). Ten istý nástroj dnes, s ovládačom hardvérového šifrovania na aarch64 (X0b) a radom zrýchlení, ktoré od tej doby pribudli, dáva 1941 pred spevnením. Neizolovali sme príspevok každej zmeny, takže o príčine netvrdíme nič.

Ako je to overené, a čo nie. H5 pridal Miri na podmnožinu hostiteľských balíkov, dôkazy Kani, sanitizery, model-fuzzer pre ACL a správy o pokrytí. Kani dokázal record_len v TLS, parse v TCP a dve aritmetiky kolesa časovačov. Nedokázané (vypršal čas): oba dekodéry MQTT, obe parsovania konfigurácie a správanie kolesa časovačov; úloha CI pre Kani preto zatiaľ neblokuje. Miri nevie vykonávať asembler. Dodávateľský reťazec (H9): CycloneDX SBOM s 215 komponentmi, cargo-vet prechádza s 39 plne preskúmanými a 140 výnimkami a cargo-deny je nastavený tak, aby upozornenia na zraniteľnosti považoval za pád CI (tieto úlohy CI sa zatiaľ overili len lokálne, nie na GitHube, a negatívny test sa nespustil), spolu s VULNERABILITY-HANDLING.md. Úprimný stav: zo 67 verzií cudzích balíkov zlinkovaných do jadra je 53 výnimiek, nie revízií. Vet dokazuje, že sa množina závislostí nemôže zmeniť bez viditeľného rozdielu, nie že TCB bola preskúmaná. Vlastnú revíziu žiadneho balíka sme nenapísali.

SNTP (T1) je v tomto zmysle malý príbeh o bezpečnosti: je voliteľný, len voči súkromným serverom IPv4, s maximálnym skokom a podmienkou, že sa zdroje zhodujú (medián, väčšina v rámci jednej sekundy). Hodiny, ktoré môže ktokoľvek na ceste posunúť, nie sú hodiny, ktorým smieme veriť pri platnosti certifikátov.

Na Macu: aarch64 natívne a x86_64 emuláciou

Vyvíjame na Macu a ten má dva spôsoby, ako spustiť ten istý kód, a sú veľmi odlišné.

Pravidlo je jednoduché: čísla pod TCG sú emulácia a necitujeme ich ako výkon. Výkon x86 meriame len na skutočnom VPS. Preto kryptografické čísla vyššie pochádzajú z VPS u Contabo, nie z Macu.

Lekcie

• Merajte na skutočnom stroji skôr, než začnete optimalizovať. Prvý prístup bol optimalizovať to, o čom sme si mysleli, že je pomalé; až diagnostika na VPS ukázala 1,2 ms a kam presne odchádza čas.
• Preťaženie je samostatná vlastnosť. Systém, ktorý je rýchly pod záťažou, sa môže zrútiť nad ňou; odmietnutie musí byť lacnejšie než prijatie.
• Profil prekvapí. Najväčší jednotlivý zisk pre malé správy nebol v kryptografii, ale v kopírovaní pamäte.
• Disk bez súborového systému chce viac práce, nie menej. To, čo súborový systém inak dáva (zarovnanie, rast, discard, kópie, kontroly), musíme napísať a overiť sami, každý krok so vstrekovaním chýb.
• Úprimnosť v číslach. Merania pamäte na zdieľanom VPS kolíšu až 10-násobne medzi behmi a o kóde nehovoria nič, preto ich neuvádzame. Kryptografické čísla sú stabilné do asi 10%.
• Rýchlosť vývoja nie je zrelosť. Testy a ADR rastú s kódom, ale štyri dni nie sú skutočná prevádzka.

Čo bude ďalej

• H6: SQLite izolovaný na úrovni EL0, aby chyba v databáze neotvorila jadro.
• H7: zvyšok bezpečnosti času (NTS a spracovanie skokov); SNTP je len prvý krok.
• X11: porovnanie s Linuxom a Mosquittom na tom istom VPS, až vtedy má zmysel hovoriť o relatívnej rýchlosti.
• Vydanie: prvé verejné vydanie pre VPS (KVM), s podpísanými artefaktmi a návodmi.
• Po vydaní: bare metal (X12 až X16), IOMMU a Secure Boot a šifrovanie disku.

Kód je na github.com/zeljan-alduk/urMQTT a docs/PROGRESS.md je naďalej jediným zdrojom pravdy o tom, čo naozaj funguje. Pred-alfa, ako predtým; hlásenia chýb a bezpečnostné hlásenia podľa pokynov v SECURITY.md sú vítané.

Tak vznikol urMQTT: unikernel, ktorý je MQTT broker. Jadro, TCP/IP, TLS 1.3, MQTT a vstavaná databáza v jedinom binárnom programe v Ruste, ktorý sa spúšťa z jedného ISO. Žiadne procesy, žiadne systémové volania, žiadny shell. Prvou platformou, na ktorej sa buduje a testuje, je aarch64, a ten istý kód smeruje na x86_64, cez UEFI aj klasický BIOS, a na skutočný hardvér: cieľom je jeden ISO, ktorý sa zavedie na všetkých z nich. Projekt je open source pod licenciou MIT alebo Apache 2.0 a v tomto texte chceme zapísať, kam sme sa dostali, ako je vo vnútri poskladaný a čo sme sa popritom naučili.

Čo presne znamená „unikernel"

Bežný broker je program, ktorý beží na operačnom systéme. urMQTT pod sebou operačný systém nemá: samo sa zavedie cez UEFI firmware a bootloader Limine, nastaví si vlastné tabuľky stránok, naprogramuje kontrolér prerušení a časovač, nájde zariadenia virtio cez PCIe, získa adresu cez DHCP a počúva na jedinom porte. Všetko, čo by inak robilo jadro, ovládače, sieťový stack a aplikácia, je tu jeden ELF, ktorý beží na úrovni EL1.

Porovnanie s typickou inštaláciou hovorí samo za seba:

Priority sú v tomto poradí: bezpečnosť, škálovateľnosť, viacjadrový výkon, malá stopa a nemenná inštalácia. Keď sú dva ciele v konflikte, vyhráva ten, ktorý je v tomto zozname vyššie.

Kde sme teraz

Projekt je vo fáze pred-alfa, ale uzavretých je sedemnásť vývojových míľnikov, od M0 po M17. Dnes urMQTT obsluhuje MQTT 3.1.1 cez TLS 1.3 s povinnými klientskymi certifikátmi a stav uchováva v SQLite na surovom disku. Stručne, čo už funguje:

• Jadro: vlastné vektory výnimiek s dekódovanými hláseniami, vlastné tabuľky stránok s vynúteným W^X, ochranné stránky, PAC a BTI tam, kde ich procesor má, GICv3 a GICv2, generický časovač, SMP až do 64 jadier.
• Zisťovanie hardvéru z DTB alebo ACPI do jedného popisu platformy, s identickým výsledkom z oboch zdrojov.
• Ovládače: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi a virtio-rng, a CSPRNG zasiaty hardvérovou entropiou.
• Sieť: vlastný DHCPv4, ARP, ICMP a prísny IPv4, potom vlastný TCP len pre serverovú stranu: SYN cookies, hierarchické koleso časovačov, NewReno, spájanie ACK, bez stavu TIME_WAIT.
• TLS: iba TLS 1.3, povinné mTLS, identita zariadenia z CN alebo SAN URI; podanie rúk robí rustls a po ňom vlastná vrstva záznamov s AES-128-GCM a ChaCha20-Poly1305. Obnovenie relácie lístkami PSK, zoznam odvolaní, riadenie prijatia už pri podaní rúk.
• MQTT: kodek bez kopírovania, fuzzovaný a testovaný s pravými klientmi mosquitto; QoS 0 a 1, zástupné znaky, zachované správy, závet (LWT), trvalé relácie, ACL s obmedzením na devices/{id}/#, obmedzenia rýchlosti na zariadenie.
• Úložisko: SQLite vnútri jadra cez VFS nad surovým diskom, v režime WAL, s kontrolou integrity pri zavádzaní; register zariadení, odvolania, zachované správy, trvalé relácie s frontmi správ pre zariadenia, ktoré sú offline; na každé jadro samostatný telemetrický denník s CRC na záznam a obnovou po páde.
• Prevádzka a dohľad: strážny časovač pre obslužné rutiny, kontrola stavu, obmedzené logovanie, syslog a statsd cez UDP, prijatie, ktoré prežije búrky opätovných pripojení.
• Dodanie: bitovo identické opakované zostavenia overené v CI, ISO a surový GPT obraz disku, podpisy minisign, návody pre KVM, Proxmox a Hetzner.

Každý krok je označený míľnikom, ktorý ho priniesol, a súbor docs/PROGRESS.md v repozitári je jediným zdrojom pravdy o tom, čo naozaj funguje.

Architektúra v troch obrázkoch

Celý návrh je popísaný v docs/ARCHITECTURE.md a dôvody každého dôležitejšieho rozhodnutia sú zapísané ako ADR v docs/DECISIONS.md. Tu je prehľad.

Vrstvy

Zhora nadol: broker (relácie, strom tém, QoS, zachované správy, závety, ACL, obmedzenia), kodek MQTT, TLS, TCP, sieťová vrstva a potom ovládače. Popri tejto hlavnej ceste stojí úložisko (SQLite a telemetrický denník) a pod všetkým správa pamäte, zisťovanie platformy a konfigurácia, ktorá je v čase zostavenia preložená do konštánt, spolu so vstavaným certifikátom CA, serverovým certifikátom a kľúčom. Hypervízor so zariadeniami virtio je jediné, čo je mimo obrazu.

Vlákno na jadro, bez zdieľaného stavu

Každé dátové jadro točí vlastnú slučku s vlastným zásobníkom TCP, stavmi TLS, dielom brokera (relácie a strom tém), vyrovnávacou pamäťou heapu a oddielom telemetrie. Jadrá nezdieľajú žiadny meniteľný stav, iba ohraničené prstence bez zámkov, po jednom pre každý usporiadaný pár jadier. Najvyššie jadro spúšťa SQLite a nič iné.

Sieťová karta má dnes jeden pár front, ktorý drží jadro 0. To každý tok MQTT podľa hashu Toeplitz jeho štvorice nasmeruje na jedno z pracovných jadier a posiela to, čo pracovné jadrá vrátia. Relácia žije na svojom domovskom jadre, určenom hashom identifikátora klienta, takže prevzatie, závety a trvanlivosť nikdy neprekračujú hranice jadier. Spojenie, ktoré pristane na inom jadre, si tam ponechá svoj TCP a TLS, a bežný MQTT preposiela domovskému jadru s riadením toku založeným na kreditoch. Každá smerovaná správa sa rozosiela aj na ostatné diely brokera, z ktorých každý drží repliku zachovaných správ.

Tento model drží pohromade tri pravidlá. Spracovanie do konca: prijatý paket sa spracuje celý na jednom jadre, od TCP cez dešifrovanie TLS na mieste, parsovanie MQTT a smerovanie až po šifrovanú odpoveď, bez frontov úloh a bez kopírovania do aplikačných vyrovnávacích pamätí. Prispôsobivé vzorkovanie: pri záťaži sa fronty na príjem aktívne vzorkujú a v pokoji sa jadro vracia k prerušeniam a WFI; obslužné rutiny prerušení iba potvrdia prerušenie a označia prácu. Strážny časovač: tik 10 ms na jadro zachytí obslužné rutiny, ktoré prekročia svoj rozpočet.

Život jedného PUBLISH

Zariadenie pošle záznam TLS. Sieťová karta ho odovzdá slučke jadra deskriptorom, bez kopírovania. Slučka skontroluje TCP, dešifruje TLS na mieste a parsuje MQTT z požičanej vyrovnávacej pamäte, potom v pamäti skontroluje ACL, obmedzenie rýchlosti a cestu stromom tém. Ak sa iné jadro zaujíma o túto tému, dostane správu na smerovanie s odkazom na obsah a identifikátorom témy; databáza dostane telemetrický záznam alebo aktualizáciu zachovanej správy, v balíku. Odpoveď PUBACK sa zašifruje priamo do odchádzajúcej vyrovnávacej pamäte a spojí sa s TCP ACK, takže zariadeniu odíde jeden segment. Iné jadro stojí správa jedno šifrovanie na odberateľa v okamihu odoslania.

Koľko stojí jedno spojenie

Cieľom je najviac 512 bajtov na nečinné spojenie TLS, s ambíciou 256. Kým spojenie odpočíva, nič sa pre ňu nedrží vo vyrovnávacej pamäti: prijaté dáta sa spracúvajú priamo zo sieťového rámca a vyrovnávacie pamäte na odosielanie, záznamy a MQTT existujú len dovtedy, kým je niečo nedokončené alebo nepotvrdené. Jadro to aj samo meria: presné počítadlá heapu v požadovaných bajtoch aj v blokoch, ktoré zaberajú, zapisované každých desať sekúnd ako heap nad základnou úrovňou na otvorené spojenie.

Zmerané pod HVF so štyrmi virtuálnymi jadrami, z toho tri pracovné, pričom každé zariadenie drží spojenie mTLS a jeden odber s QoS 1, vrátane zaokrúhľovania alokátora:

Fond sieťových rámcov je pevný, okolo 2 MiB, čo je zhruba 200 B na spojenie pri desaťtisíc spojeniach a okolo 2 B pri milióne. Viac sme zmerať nedokázali: používateľská sieť QEMU na macOS prestala prijímať spojenia pri 10 197, zhruba na hranici 10 240 deskriptorov procesu QEMU. Číslo klesá, keď sa pevné časti rozdeľujú na viac spojení, takže s ich počtom nerastie.

Bezpečnostný model

Bezpečnosť je prvou prioritou a vyhráva všetky konflikty s ostatnými cieľmi. Model má niekoľko vrstiev:

• Jeden port. TCP 8883, iba TLS 1.3, povinné klientske certifikáty podpísané CA vstavanou do obrazu. Identifikátor klienta MQTT sa musí rovnať identifikátoru zariadenia z certifikátu.
• Žiadny vstup. Žiadny shell, konzolový vstup, SSH, administračné API, dynamický kód, SQL dostupný cez sieť ani súborový systém.
• Pamäťová bezpečnosť. Rust, s forbid(unsafe_code) v protokolových balíkoch; každý blok unsafe má komentár // SAFETY:, ktorý kontroluje lint, a na vonkajší vstup neexistuje panika: clippy v balíkoch na dátovej ceste zakazuje unwrap, expect, indexovanie a panic!.
• Zmierňovanie zneužitia. W^X sa vynucuje kódovaním deskriptorov a bitom SCTLR_EL1.WXN a kontroluje sa pri každom zavedení. Tabuľky stránok sú po zavedení iba na čítanie, bez zapisovateľného aliasu. Dolná polovica adresného priestoru je vypnutá. Každý zásobník má ochranné stránky a výnimky bežia na samostatnom zásobníku. PAC a BTI sa zapínajú, keď ich procesor podporuje, a overujú to dymové testy.
• Odolnosť voči zneužitiu. SYN cookies; prijatie odmieta nové spojenia, ešte pred akoukoľvek kryptografiou, keď je heap nízky, keď databáza zaostáva, keď je príliš veľa podaní rúk v priebehu na jadro alebo na zdrojovú adresu, alebo keď je rýchlosť podaní rúk príliš vysoká. Obmedzenia rýchlosti na zariadenie, ohraničené fronty, okno TCP viazané na spätný tlak brokera, obmedzené logovanie, strážny časovač a kontrola stavu.
• Nemennosť. Konfigurácia, CA a serverový kľúč sú vstavané do obrazu. Zmena čohokoľvek znamená nový obraz.

Model hrozieb je zapísaný v docs/SECURITY.md.

Úložisko bez súborového systému

Dáta žijú na samostatnom disku, virtio-blk alebo virtio-scsi, na ktorom nie je súborový systém. Rozloženie je minimálne a vlastné:

LBA 0      [ superblok: magické číslo · verzia rozloženia · uuid · tabuľka oblastí · CRC-32C ]
LBA 8, 16  [ tabuľka veľkostí súborov, sloty A/B (vyhráva najnovší platný) ]
LBA 64     [ SQLite hlavná databáza ½ ][ SQLite WAL ⅛ ][ denník 1 MiB ][ telemetrický denník: 8 oddielov … ]
posledné 4 KiB [ priestor na samokontrolu blokového zariadenia pri zavádzaní ]

SQLite (vendorovaný 3.54.1, s kontrolou odtlačku pri zostavení) je preložený do jadra pomocou clang, bez štandardnej knižnice, a používa pevný heap memsys5. Jeho VFS mapuje tri pevné súbory na oblasti disku. Beží v režime WAL s locking_mode=EXCLUSIVE, takže nepotrebuje index v zdieľanej pamäti, a so synchronous=FULL; ak quick_check pri zavádzaní nájde chybu, systém sa bezpečne zastaví. V databáze sú register zariadení, odvolania, zachované správy a trvalé relácie s frontmi správ QoS 1 pre zariadenia, ktoré nie sú pripojené.

Jadro pre databázu, to s najvyšším číslom, spúšťa SQLite a nič iné. Dátová rovina mu posiela zmeny stavu cez prstenec SPSC bez zámkov; ono ich zbiera do jednej transakcie každých 5 ms alebo každých 512 operácií a potvrdenia vracia druhým prstencom. Prázdny disk sa naformátuje pri prvom zavedení; nič iné sa nikdy nepreformátuje.

Telemetria ide inou cestou. Každý prijatý PUBLISH na témach zo storage.telemetry_topics odchádza do oddielu telemetrického denníka svojho jadra: prstenec segmentov s CRC na záznam, osolený poradovým číslom segmentu, takže sa staré prechody prstenca nikdy znova neobjavia. Jadrá odovzdávajú záznamy databáze vlastným prstencom, bez kopírovania, a ona ich zapisuje každých 5 ms alebo každých 256 KiB. Pri zavádzaní obnova zachová každý zapísaný záznam, odreže nedokončený chvost a pokračuje v novom segmente. Uchovávanie je podľa veľkosti, cez prstenec, aj podľa veku, cez retention_days. Overili sme to s miliónom záznamov a s kill -9 uprostred zápisu.

Čísla

Nástroj na záťaž v tools/loadgen robí tri veci: búrku podaní rúk TLS 1.3 s mTLS a CONNECT, dlhodobé spojenia s PINGREQ, ktoré každú sekundu publikujú telemetriu, a búrky opätovných pripojení. make bench na Apple M4 Pro pod HVF dáva:

Číslo v hosťovi, kde sú klient aj server v tom istom virtuálnom stroji a každé pracovné jadro beží samo za seba, ukazuje, že dátová rovina škáluje lineárne. Sieťové číslo je obmedzené jednovláknovou používateľskou sieťou QEMU, nie hosťom; aj to je zapísané ako ADR-032.

Búrky opätovných pripojení testujeme tak, že sa všetky zariadenia pripoja naraz, opakujú odmietnuté pokusy so oneskorením a potom všetky spadnú bez DISCONNECT. Parameter heap_limit_mb= vo vývojovom režime donúti prijatie považovať heap za menší, než je, takže sa búrka väčšia než heap dá vyskúšať s málo socketmi. V jednom takom kole s 3 000 zariadeniami sa pripojilo 1 368 za 36 sekúnd a 5 619 pokusov bolo riadne odmietnutých, pri obmedzení 8 MiB; pamäť sa po búrke vrátila.

Ako pracujeme

Projekt vedie písaná špecifikácia, PROMPT.md, s plánom míľnikov, a každý míľnik sa končí tým istým rituálom: make check a make smoke zelené, jeden commit so značkou M<n>, záznam v docs/PROGRESS.md a ADR pre každé rozhodnutie, ktoré nie je zrejmé. Pravidlá sú krátke a nevyjednávame o nich: žiadna panika na vonkajší vstup, unsafe iba v hardvérových a FFI balíkoch a vždy s komentárom, žiadne alokácie na horúcej ceste, komentár ku každému poradiu atomických operácií, každé obmedzenie pochádza z konfigurácie a zámerné dočasné časti padajú nahlas.

CI robí viac, než by sme stihli ručne: fmt, clippy pre hosta aj pre aarch64-unknown-none, typos, actionlint a shellcheck; testy na Linuxe a macOS na arm64; zostavenie jadra pre vývojovú aj produkčnú konfiguráciu s veľkosťou ELF v súhrne; zavedenie pod QEMU so všetkými scenármi dymového testu a uložením sériových záznamov; cargo-deny pre upozornenia, licencie a zdroje; minútu fuzzingu na každý z jedenástich cieľov a v noci desať minút na cieľ s korpusom v cache. K tomu CodeQL, OpenSSF Scorecard, Dependabot a vydanie s pôvodom SLSA. Každá cudzia akcia je pripnutá na plný commit SHA.

Reprodukovateľnosť chápeme doslovne: make repro zostaví HEAD dvakrát v čerstvých pracovných stromoch a porovná ELF, ISO a surový obraz bajt po bajte. Vydania sú podpísané pomocou minisign a artefakty sa dajú overiť cez gh attestation verify. Produkčný obraz obsahuje súkromný kľúč servera, takže samotný ISO je tajomstvo; obrazy pri vydaniach na GitHube sú vývojové, s dočasnými kľúčmi, a slúžia len na vyskúšanie.

Čo sme sa naučili

Niekoľko lekcií, ktoré zmenili plán:

• Vlastný TCP sa napokon oplatil. Prototyp bežal na smoltcp a dobre nám slúžil až do M13. Ale server, ktorý drží státisíce spojení, nepotrebuje klientsky TCP, potrebuje SYN cookies, koleso časovačov a stav s 96 bajtmi. V M14 sme smoltcp nahradili vlastným stackom len pre serverovú stranu, s testami simulovanej straty a fuzzingom segmentov.
• Merajte pamäť zvnútra. Odhady na spojenie boli bezcenné, kým jadro samo nezačalo počítať heap v blokoch alokátora, a nie v požadovaných bajtoch. Až vtedy sme uvideli, kam sa 512 bajtov naozaj podeje, a klesli sme na 494.
• Nástroj na testovanie je súčasť produktu. Najväčším obmedzením nebolo jadro, ale používateľská sieť QEMU a počet efemérnych portov na vývojovom počítači. Pre sto tisíc spojení a viac treba vmnet-shared na macOS alebo Linux s KVM, rozhraním tap a viacerými klientskymi adresami.
• SQLite bez operačného systému je možný, ale len za prísnych podmienok: pevný heap, exkluzívne zamykanie bez zdieľanej pamäte, VFS, ktorý nevie o súboroch, a prijatie, ktoré nenechá databázu zaostať.
• Búrky opätovných pripojení sú normálny stav, nie výnimka. Keď spadne mobilná sieť a vráti sa, tisíce zariadení klopú súčasne. Preto prijatie odmieta spojenie ešte pred akoukoľvek kryptografiou a každé odmietnuté spojenie stojí takmer nič.

Čo bude ďalej

Práca po M17 je plánovaná v troch smeroch a poradie medzi nimi je zapísané v docs/PLAN.md. Nič z toho ešte nie je postavené.

• Jeden ISO pre viac platforiem. Ten istý súbor urmqtt-<env>-<verzia>.iso a jeden surový obraz GPT, ktoré sa zavádzajú na aarch64 UEFI, x86_64 UEFI a x86_64 BIOS, vo virtuálnych strojoch aj na skutočnom hardvéri, počnúc jedným počítačom Intel. Naďalej zariadenie so všetkým vnútri, reprodukovateľné a podpísané.
• Surový disk, bez súborového systému. Špecifikácia formátu na úrovni bajtov, hostiteľský nástroj urmqtt-disk, ktorý zdieľa parsery s jadrom, zarovnanie oblastí na 1 MiB, rast disku s dátami, discard pre tenko alokované disky, snímky databázy A/B, kontrola bitov a podľa výberu šifrovanie AES-256-XTS s hardvérovým AES.
• Dokázateľne bezpečné. Odvolanie a zoznam povolených zariadení za behu cez podpísaný riadiaci kanál, bez nového obrazu; diferenciálne a konformančné testovanie vlastného TLS a TCP; KASLR, ochrana zásobníka, kCFI, MTE a spevnený alokátor; SQLite izolovaný na úrovni EL0; Secure Boot; SBOM a cargo-vet; a nakoniec balík pre externý audit.

Platformy, ktoré ponúkajú iba zariadenia, ktoré nie sú virtio, ako AWS ENA alebo Azure MANA, zatiaľ nie sú podporované. Raspberry Pi 4 a 5 ako hostiteľ KVM, Hetzner CAX a Oracle Ampere A1 sú zdokumentované a podporované kódom, ale ešte neboli vyskúšané na skutočnej službe.

Vyskúšajte

Repozitár je na github.com/zeljan-alduk/urMQTT. S Rustom s pripnutou nightly sadou nástrojov a QEMU stačia make certs, make run a jeden klient mosquitto na prvý PUBLISH cez mTLS na vlastnom počítači. Upozornenie z úvodu platí aj na konci: toto je pred-alfa a všetko, čo funguje, je napísané v docs/PROGRESS.md. Hlásenia chýb, otázky k návrhu a bezpečnostné hlásenia podľa pokynov v SECURITY.md sú vítané. O každom ďalšom míľniku sa tu ozveme.

Na tomto blogu si zapisujeme, čo sme sa cestou naučili. Nie marketingové texty, ale konkrétne poznámky: čo sa pokazilo, ako sme to vyriešili a čo by sme dnes urobili inak.

O čom budeme písať

• Odbavenie cestujúcich vo verejnej doprave. Bezkontaktné karty, moduly SAM, práca bez siete a všetko, čo musí terminál vydržať vo vozidle, ktoré sa dvanásť hodín denne trasie.
• Mobilné aplikácie v teréne. Android a Flutter na zariadeniach, ktoré nie sú obyčajné telefóny: s čítačkami kariet, tlačiarňami a batériami, ktoré musia vydržať celú zmenu.
• Backend a dohľad nad flotilou. Ako zistiť, že zariadenie vo vozidle má problém skôr, než ho nahlási vodič.
• Hardvér. Od prototypu na stole po dosku, ktorá ide do sériovej výroby, a všetky chyby medzi tým.
• Lokálne modely AI. Kde majú zmysel modely na vlastnom hardvéri a kde sú cloud a API jednoducho lepšia voľba.

Ako budeme písať

Krátko a konkrétne, s kódom a číslami tam, kde ich máme. Publikovať budeme, keď budeme mať čo povedať, nie podľa rozvrhu. Príspevky píšeme po chorvátsky a prekladáme ich do všetkých jazykov tohto webu; sledovať nás môžete aj cez RSS.

Ak vás zaujíma nejaká téma alebo riešite podobný problém, napíšte nám na info@aldo.tech.