Opomba vnaprej ostaja enaka: projekt je v predalfa fazi, prva izdaja je samo za VPS-je s KVM-jem, številke pa merijo kodo, teste in določene poskuse, ne zrelosti v produkciji.

Kako je to izgledalo skozi čas

Od prejšnjega besedila (31.10. ob 23:00) do danes (1.11. ob 20:41) je v repozitoriju 59 novih commitov, skupaj 178. Vsi so nastali v enem koledarskem dnevu, zato velja enako opozorilo kot prej: projekt gradimo s Claude Code (commiti nosijo Co-Authored-By: Claude), načrt, koda, testi in ADR-ji nastajajo v kratkih, zaprtih zankah, spodnje številke pa govorijo o količini kode in preverjanj, ne o tem, koliko človeškega dela je v njih.

Številke so izračunane z isto metodo kot v prejšnjem besedilu: vse datoteke .rs zunaj vendor/ in fuzz/, funkcije #[test], naslovi ## ADR- v docs/DECISIONS.md.

Delo je potekalo vzporedno na več vejah, zato vrstni red commitov ni strogo vrstni red dela. ADR-ji so oštevilčeni do 232, vendar ima oštevilčenje vrzeli (del jih je bil ob združevanju vej preimenovan); štejemo naslove, ne najvišje številke. Izdaji: v0.2.0 (1.11., 18:45 UTC) in v0.2.1 (1.11., 20:22 UTC), obe označeni kot pre-release.

H6: SQLite v uporabniškem načinu

Kaj smo načrtovali. SQLite je 254 268 vrstic C-ja, ki razčlenjuje bazo, WAL in dnevnik z diska, disk pa je lahko izdelan ali spremenjen. Dotlej je deloval v jedru, s pravicami jedra. Kaj smo zgradili (ADR-210 do ADR-212): SQLite, njegovi deli libc in kopica so bili premaknjeni v ločen program, dbworker, ki teče na EL0 (aarch64) oziroma v ring 3 (x86_64), v lastnem naslovnem prostoru. Jedro SQLite-a ne povezuje več vase. Delavec z jedrom komunicira prek skupnega pomnilniškega okna in dvanajstih sistemskih klicev, vsaka vrnjena dolžina in odmik pa se pred uporabo preverita. Napaka v delavcu (nedovoljen dostop, nedefiniran ukaz, preseženi časovni proračun 30 s) konča klic, delavec se znova zažene in baza se odpre iz WAL-a kot ob zagonu; po 5 ponovnih zagonih na minuto se shramba razglasi za neustrezno in se ne zaganja v nedogled.

Cena, izmerjena na aarch64 pod HVF-jem, ista VM, jedro z vgrajenim SQLite-om proti jedru z delavcem, šest izmeničnih zagonov vsakega:

Zapisi na disk (1 572) in flushi (319) so enaki, kot mora biti. Tole ni izolirano: jedro še vedno zaupa temu, kar delavec vrne, po preverjanju oblike. Ogrožen delavec lahko laže (na primer vrne prazen seznam preklicanih potrdil in jih tako »prekliče preklic«), ne more pa brati pomnilnika jedra, ključev TLS ali ključev vstopnic. KPTI-ja ni, zato uhajanja tipa Spectre/Meltdown niso preprečena in o njih ne trdimo ničesar; ključ PAC si delita EL0 in EL1. Na x86_64 cene preklopa na KVM-ju nismo izmerili (pod TCG-jem bi bila številka brez pomena), fuzziranje delavca in protokola pa še ni končano. Nabor testov za shrambo (79 scenarijev, vsak vrti SQLite v delavcu) uspešno teče na aarch64 HVF in x86_64 TCG, na aarch64 TCG jih teče 76 (eden se preskoči, ker TCG nima MSI-X).

H7 je zaprt, vendar ne tako, kot smo napovedali. Spodnja meja časa (ADR-050) in SNTP s konsenzom (T1) pokrivata obseg H7; NTS (RFC 8915) ostaja zunaj obsega in je zapisan kot preostalo tveganje, ne kot nekaj, kar deluje. Ne menimo, da je varnost časa »rešena«, ampak da je njen dokazljivi del končan.

Nova omrežna možnost. Contabo ne daje DHCP-ja prilagojenemu ISO-ju, zato je VPS doslej potreboval drugo sliko kot laboratorijska VM. Zdaj network.mode = "auto" (ADR-214) najprej vpraša DHCP, če zakupa v danem roku (dhcp_timeout_s, privzeto 15 s) ni ali ga izgubi, pa uporabi privzeti statični naslov. Ročno preizkušeno na QEMU-ju (z DHCP-jem uporabi zakup, brez omrežja se po 5 s vrne na statični naslov); smoke scenarija za to še ni.

X11: primerjava z Mosquittom na istem VPS-ju

Ista vrsta stroja kot v prejšnjem besedilu (Contabo, 4 vCPU AMD EPYC, 8 GiB), obremenitev z gostitelja Linux, oddaljenega 15 ms, vzajemni TLS 1.3 z istimi potrdili na obeh straneh, Mosquitto 2.0.21 na Debianu 13 brez trajnosti. Metoda in odločitve so v ADR-213, surovi podatki v docs/perf-results/. Mediana treh zagonov.

Kaj to pomeni in česa ne. Rokovanja so spodnje meje za oba strežnika: generator obremenitve je deljena VM z 60 do 70 % ukradenega procesorskega časa in je bil pri 128 nitih blizu lastne omejitve, delovna jedra urMQTT pa so bila zasedena le 12 do 13 %. Razmerje pri 128 odjemalcih (okoli 2,2-krat) je najsmiselnejše; pri 32 in 64 večinoma meri čakanje odjemalcev. Številke pomnilnika ne štejejo enakega (kopica jedra proti RSS procesa), zato je »okoli 50-krat manj« velikostni red, ne natančno razmerje. Zakasnitev 14 ms je en krog omrežja (okoli 15 ms), torej »ni merljivega časa posrednika«; repi (p99 okoli 100 do 200 ms) so pri obeh posrednikih pod prevlado deljenih gostiteljev. Razlik pod okoli 20 % ne zatrjujemo.

Kaj ni šlo v našo korist in je ostalo v tabelah: en tok TCP prek urMQTT je prenesel 2 do 8-krat manj kot prek Mosquitta, z nihanji od nič do 7,7 tisoč sporočil na sekundo med zagoni, 20 ms watchdog upravljalnika pa je prekinjal žive povezave, ko je hipervizor ustavil vCPU (v produkcijski nastavitvi action = "drop", 6 do 8 povezav na zagon pri preplavljanju QoS 0). Obe stvari sta opisani v naslednjem razdelku, ker sta imeli vzroka v naši kodi.

Zakaj je bil en tok počasen: vzroki, ne izgovori

Najlažje bi bilo reči »deljeni VPS«. Nismo, ampak smo pri istem VPS-ju in isti metodi iskali vzroke. Najdenih je bilo pet vzrokov, štirje v poti podatkov in eden v watchdogu (ADR-221 do ADR-224):

Ustavitve so resnične: na tem VPS-ju so imela jedra 0 do 2 mediano 36 do 80 zamujenih utripov na 5 sekund, najhujša ustavitev v oknu pa je bila po mediani okoli 70 ms in do 0,9 s (jedro 3, baza in dnevnik: do 1,55 s), medtem ko gostitelj ne sporoča ukradenega časa (host steal 0 us). Zato je watchdog potreboval drugo uro, ne večjega proračuna.

Watchdog: 148 prekinjenih povezav v 30 obremenjenih zagonih prej, 0 v 24 zagonih potem; na lokalni napravi, ki zakasnjuje in izgublja okvire, ima pri izgubi 0,1 % en tok 64 B s 14,3k sporočil/s (jedro X11) zdaj 41,0k, pri 0,5 % pa s 5,0k na 17,7k.

Kaj to ne pove. urMQTT na enem toku še vedno ni hitrejši od Mosquitta: pri 64 B objavlja okoli 80 % njegove hitrosti, dostavlja pa okoli 40 %, ker zavrže QoS 0, ko je tok naročnika počasnejši od izdajateljevega (Mosquitto brez omejitve postavlja v vrsto). Pri 1 KiB je pri preplavljanju s 16 pari Mosquitto spredaj za okoli 15 %, kar je znotraj šuma. Generator je bil spet deljena VM z 58 do 77 % ukradenega časa. Drugi krog (zaklepanje kopice zunaj poti podatkov, SACK na strani pošiljanja in drugo) je na neintegrirani veji perf-single-flow-wip; njegove številke še niso trditve in jih tu ne navajamo.

Obljuba, ki je nismo dali, a smo jo izpolnili: konfiguracija je podatek

Doslej je bila vsaka konfiguracija nova gradnja: ključi in omejitve so bili vgrajeni v sliko. C1 to obrne (ADR-215 do ADR-219): jedro se zgradi enkrat, konfiguracija pa je podatek.

• Blob urmqtt-cfg (C1a): verzioniran, kanoničen zapis (polja po naraščajočih oznakah, prstni odtis SHA-256, neobvezen ločen podpis Ed25519), 70 polj s privzetimi vrednostmi in mejami, dekoder, ki zavrne vse neustrezno.
• Jedro ga prebere kot modul Limine (C1b), pred vsem drugim, na aarch64 in x86_64. Obstaja eno izdano jedro za vsak ENV razen dev (ELF-i aarch64 za release, prod in bench imajo isti SHA-256; preverjeno samo na aarch64). Izdano jedro zavrne razvojno konfiguracijo, brez konfiguracije pa izpiše »refusing to serve« in ne streže ničesar.
• Nameščeni disk nosi konfiguracijo in posodobitev jo ohrani (C1c).
• urmqtt-config in predloga ISO (C1d): pack, show, verify, pack --iso pa zamenja oba izvoda mesta za konfiguracijo in 24 povzetkov modulov v končnem ISO-ju. Rezultat je bajt za bajtom enak ISO-ju, ki ga zgradi mkiso.sh --config. Predloga izdaje v0.2.0 ima 63 111 168 bajtov.
• Izjava o zaupanju (ADR-219): konfigurirana slika ob zagonu izpiše prstni odtis konfiguracije (config: fingerprint ...), podpis pa je neobvezen in privzeto izključen. Spremenjen ISO nima uradnega povzetka; odtis je način, da se vidi, kaj je v njem.

Graditelj na aldo.tech

Isto, kar dela urmqtt-config pack --iso, dela tudi spletna stran, z isto kodo: knjižnica orodja, prevedena v WebAssembly (1,06 MB, brez uvozov in brez bloka unsafe). Stran je na aldo.tech/sl/izdelki/urmqtt-builder/ in obstaja v vseh 15 jezikih strani (na primer hr).

• Nič ne zapusti brskalnika. Potrdila, zasebni ključi in končni ISO ostanejo na računalniku; stran prenese samo datoteke izdaje s tega mesta, brez sledenja in skript tretjih strani. V testu v živo nobena zahteva ni nosila ključnega gradiva.
• Zrcalo izdaj (ADR-227): ura za uro (časovnik systemd, nizka prioriteta) kopira izdaje z GitHuba, vsako preveri pred objavo, stran v brskalniku pa preveri podpis SHA256SUMS s ključem, vgrajenim v stran, in šele nato vpiše konfiguracijo v predlogo. Neuspešno preverjanje blokira prenos.
• Enostavno privzeto, napredno po potrebi (ADR-232): prvi zaslon so trije koraki (kje deluje, vaša potrdila, ime slike). Eno polje za povlečenje datotek razvrsti potrdilo, ključ in CA po vsebini. Napredni pogled odpre vsako od 70 polj, iskanje, uvoz in izvoz TOML; oba pogleda urejata isto stanje. Predloga (63 MB) se prenaša, medtem ko uporabnik izpolnjuje obrazec. V preizkusu v živo, s preizkusnim zrcalom in preizkusnim ključem, je gradnja ISO-ja v brskalniku trajala 5 do 18 s.

Emulator, neobvezno. Ob »Prenesi ISO« stoji »Preizkusi v emulatorju«: QEMU, preveden v WebAssembly, zažene ravnokar zgrajeno sliko v zavihku brskalnika. Nič od njega se ne prenese pred klikom (okoli 3 MB prvič). Emulator je samo BIOS, brez omrežja (da promet uporabnika ne bi šel prek kakšnega posrednika in omajal »nič ne zapusti brskalnika«), potrebuje okoli 1,5 GB pomnilnika in namizni brskalnik (preizkušen Chrome; Firefox in Safari nista). V njem urMQTT doseže URMQTT READY v okoli 8 s (s preskočenim odštevanjem) in izpiše isti prstni odtis konfiguracije kot stran, kar je dokaz, da je bila zagnana prav ta konfiguracija. Zagon je okoli 2-krat počasnejši od izvirnega QEMU-ja na istem Macu (0,82 s proti 1,9 s), kriptografija pa okoli 58-krat počasnejša, ker so strojni ukazi emulirani. Zato iz emulatorja ne izpeljujemo nobenih trditev o hitrosti, stran pa to pove pred zagonom. Pri gradnji je bilo treba v .wasm zakrpati štiri bajte zaradi napake pri prevodu ukaza POPCNT v izvirnem emulatorju (še je nismo prijavili); sam emulator je pod GPL, s ponudbo izvorne kode.

Navaden MQTT, samo za omrežja, ki jim zaupate

Navaden MQTT (TCP 1883, brez TLS) je v IoT zelo pogost: je privzet v Mosquittu, v večini strojne programske opreme za Arduino in ESP, v Tasmoti, Zigbee2MQTT in Home Assistantu, uporablja pa se tudi znotraj segmentiranih industrijskih omrežij, za VPN-ji in v zasebnih omrežjih LAN, pa tudi na napravah brez ure (potrdila zahtevajo datum), brez dovolj flasha ali procesorja za TLS. Prek nezanesljivega omrežja ni sprejemljiv: kdor je na poti, bere in spreminja promet. Zato je P1 (ADR-229 do ADR-231) izrecna, omejena izbira, privzeto izključena, vrata TLS pa ostanejo; TLS se s tem ne izklopi, navadna vrata pridejo zraven.

• Seznam dovoljenih omrežij je obvezen (allow_from, CIDR-ji) in se preveri ob SYN: zunaj seznama ni SYN-ACK-a ne stanja. Cel internet (0.0.0.0/0) zahteva ločeno izrecno možnost.
• Trije načini prijave: geslo (privzeto, ko je vklopljeno; PBKDF2-HMAC-SHA-256, sol, 10 000 iteracij, primerjava v stalnem času, zaklepanje po naslovu), anonimno (ena konfigurirana identiteta z lastnim ACL) in po naslovu (ip). Graditelj geslo razprši v brskalniku, v pomnilniku pa hrani samo povzetek.
• Manj pravic kot mTLS: navaden odjemalec nikoli nima storitvenih, operaterskih ali upravljalskih pravic, nima $SYS ne konzole, ima lastne seje ($plain/<identiteta>/<id odjemalca>, samo čiste), lastne omejitve in register dovoljenih ga še vedno zavezuje.
• Kaj se izgubi, piše v SECURITY.md: zaupnost, celovitost, pristnost posrednika in ponavljanje posnete prijave. To se s konfiguracijo ne da popraviti; tako je, kadar ni TLS.

Izmerjeno na prenosniku (Apple silicon, HVF, uporabniško omrežje QEMU), 16 parov, 64 B, trije zagoni po 10 s: pri 8 000 sporočilih na sekundo TLS in navadna pot dostavita vsa sporočila z isto zakasnitvijo (p50 0,17 ms proti 0,13 do 0,18 ms), nove povezave na sekundo: TLS okoli 2 600 do 2 750, anonimni navaden okoli 4 900 do 7 800, prijava z geslom pa je drag del: en PBKDF2 stane okoli 2,5 ms, zato je število novih prijav omejeno na okoli 200 na podatkovno jedro na sekundo (izmerjeno 308 do 342 na dveh jedrih). Preplavljanje na tem stroju ni stabilen instrument (20k do 440k dostavljenih na sekundo med zagoni) in iz njega ne izpeljujemo zaključka. Primerjava navadne poti z Mosquittom na VPS-ju še ni narejena. Testi: smoke skupina plaintext 7 od 7 na aarch64 HVF in na x86_64 TCG, nov fuzz cilj plain_input (2,3 milijona zagonov brez najdb).

Napake, ki jih je našlo delo v živo

Dveh stvari niso ujeli testi, ampak prva vključitev na pravem mestu:

• Stran je datoteke izdaje iskala en imenik previsoko, zato je vsako preverjanje podpisa odgovorilo 404 (popravek 13af301). Test je uporabljal preizkusno zrcalo na drugi poti.
• Tipkovnica emulatorja nikoli ni prišla do gosta: vzrok ni bil slab prevod tipk, ampak to, da pogovorno okno sploh ni poslušalo tipk (popravek v ADR-232, z vnosom za zagon brez tipk).

Lekcije

• Iščite vzrok, ne obtožujte okolja. Večina slabosti enega toka in vse prekinjene povezave so bile naše; hipervizor je resničen, vendar ga je bilo treba meriti, ne predpostavljati.
• Primerjava z drugim izdelkom mora vključevati tudi izgube. Tabela, v kateri so samo naše zmage, ne bi bila primerjava.
• Merilni instrument ima meje. Deljen generator z 60 do 70 % ukradenega časa spremeni, kaj številke pomenijo; zato pišemo »spodnja meja« in ne zatrjujemo razlik pod 20 %.
• Izolacija ni dokaz. SQLite v EL0 zmanjša, kaj lahko stori napaka v njem, ne tega, o čemer lahko laže.
• Resnična namestitev najde tisto, česar testi ne iščejo: pot, ki je bila narobe sestavljena, in tipke, ki jih nihče ne posluša.

Kaj še ni dokazano

• Podpisni ključ izdaje je za zdaj preizkusni ključ; v0.2.0 in v0.2.1 sta pre-release, slike zraven njiju pa razvojne s preizkusnimi potrdili (razen predloge, ki je brez konfiguracije).
• 13 prevodov strani graditelja (in tega besedila) je napisala umetna inteligenca, preverili pa so jih testi in vzorci, ne materni govorci.
• Primerjava z Mosquittom je ena seja, ena pot in en deljen generator, na deljenem VPS-ju; razlike pod 20 % niso trditve.
• Navadna pot ni bila merjena na VPS-ju ne proti Mosquittu.
• Lighthouse na novem enostavnem pogledu ni potrjen (stari pogled: dostopnost 95 ali več).
• Bare metal, cena delavca x86_64 na KVM-ju, Firefox in Safari za emulator: ni merjeno.

Kaj sledi

• D1: javni demo posrednik. Emulatorja iz brskalnika ne moremo narediti javnega: živi v zavihku enega obiskovalca, je 20 do 100-krat počasnejši od KVM-ja, nima dohodnega omrežja in izgine z zaprtjem zavihka; preusmerjanje interneta v tuj brskalnik bi bilo tudi zloraba. Mogoč je pravi demo posrednik: urMQTT na VPS-ju za imenom na aldo.tech, z objavljenim preizkusnim CA, strogim ACL in majhnimi omejitvami. To je zaenkrat samo zamisel, ne gradnja, in potrebuje izrecno soglasje za javno izpostavitev.
• Drugi krog za en tok (veja perf-single-flow-wip): šele ko je izmerjen na VPS-ju in združen.
• Navadna pot proti Mosquittu na VPS-ju, prijava in preklic računa za navaden MQTT prek podpisanega upravljalskega kanala.
• Po izdaji: bare metal (X12 do X16), IOMMU in Secure Boot, šifriranje diska.

Koda je na github.com/zeljan-alduk/urMQTT, docs/PROGRESS.md pa je še vedno edini vir resnice o tem, kaj dejansko deluje, docs/PERFORMANCE.md o tem, kaj je izmerjeno. Predalfa, kot prej; prijave napak in varnostne prijave po navodilih v SECURITY.md so dobrodošle.

Ena opomba vnaprej: projekt je še vedno v predalfa fazi. Številke v besedilu merijo kodo in teste, ne zrelosti v produkciji, prva objava pa je namenoma omejena na VPS-je s KVM-jem. Bare metal ostaja za pozneje.

Kako je to izgledalo skozi čas

Prvi commit je nastal 28. oktobra 2026 ob 23:48 (M0). Do 31. oktobra ob 23:00 je v repozitoriju 119 commitov, razporejenih kot 3, 39, 38 in 39 po koledarskih dneh. Takoj povejmo tudi, kako je to mogoče: projekt gradimo s Claude Code, commiti pa nosijo trailerje Co-Authored-By: Claude. Štirje koledarski dnevi zgodovine ne pomenijo, da je ena oseba v štirih dneh napisala 90 000 vrstic; pomenijo, da se načrt, implementacija, testi in ADR-ji pišejo v kratkih, zaprtih zankah, vsak korak pa se konča z enakim obredom preverjanja kot prej. Spodnje številke govorijo o količini kode in testov, ne o tem, koliko dejanskega dela je bilo vloženega.

Graf kaže tri krivulje, ki rastejo skoraj skupaj, kar je tudi namen: testi in zapisane odločitve sledijo kodi, ne zaostajajo za njo. Naklon je najstrmejši 29. oktobra, ko nastane celotna pot od jedra do posrednika. Pozneje se vrstice dodajajo počasneje, testi pa rastejo hitreje od kode (27 testov na 1,6 tisoč vrstic na začetku, 739 na 89,8 tisoč danes).

Vrstice so vse datoteke .rs zunaj vendor/ in fuzz/, testi so funkcije #[test]. Kaj je dodal kateri del, po datumu iz zgodovine gita:

Obljuba 1: en ISO za več platform

Kaj smo načrtovali. Ena datoteka, ki se zažene na aarch64 UEFI, x86_64 UEFI in x86_64 BIOS. Kaj smo zgradili. Port na x86_64 (X0 do X10) in univerzalni ISO z zagonskim nalagalnikom Limine, en hibridni ISO, s katerega se zaženejo vse te kombinacije; dimni testi ga zaženejo na štirih virtualnih strojih. Meni ima tri vnose: urMQTT (živi način, teče iz RAM-a, nič ne piše na disk), namestitev na disk računalnika, na katerem je zagnan (namestitev zapiše GPT in podatke, nato ugasne stroj), in Diagnostika (zaznavanje strojne opreme in meritve).

Prva prava tarča je bil VPS, ne fizični računalnik: odločitev je, da prva izdaja podpira samo VPS (KVM), bare metal pa pride za njo. Testirali smo na VPS-ju Contabo s procesorjem AMD EPYC (družina 23, Zen 1), 4 vCPU-ji in 8 GiB RAM-a, z omrežjem virtio-net in diskom virtio-scsi. Prvi poskus nas je presenetil: ISO, priključen kot virtualni CD, je zagnal privzeti vnos, produkcijska slika pa je zavrnila streženje z medija samo za branje in se ponastavila, tako da smo dobili neskončno zanko meni, jedro, ponastavitev brez česar koli berljivega. Danes usodna napaka v produkcijski sliki pusti sporočilo na konzoli 60 sekund pred ponastavitvijo, z optičnega medija pa izpiše, da je bil zagon z medija samo za branje, in se ustavi. Živi način v RAM-u (O3) je pozneje to težavo za običajni primer zaobšel.

Diagnostični vnos je nastal iz te izkušnje: stroj, ki ga ne vidimo, moramo znati vprašati, kaj ima. Izpiše CPU, RAM, omrežje, diske in naprave PCI, izmeri prepustnost pomnilnika, disk in kriptografijo, enake meritve pa izpiše tudi kot JSON na serijska vrata. Pisanje na disk je dovoljeno samo v nerazporejenem prostoru in šele, ko vtipkate WIPE; na spodnjem posnetku je bilo to preskočeno.

Kaj je odprto. Prava strojna oprema. Po prvi izdaji sledi bare metal (zagon z USB-ja, NVMe in AHCI, omrežna kartica pravega računalnika), skupaj z IOMMU-jem in Secure Bootom, ker brez IOMMU-ja lahko zlonamerna ali okvarjena naprava piše po celotnem pomnilniku. V tej različici o tem ne trdimo ničesar.

Rokovanje: od 1,2 ms do 0,24 ms

Prva meritev diagnostike na VPS-ju je dala neprijetno številko: rokovanje mTLS, samo kriptografija na strani strežnika, je trajalo 1,2 ms. Na aarch64 smo že uporabljali strojne ukaze AES in SHA, na x86_64 pa nismo imeli nič podobnega za javni ključ: RustCrypto je prenosljiv in constant-time, zato pa tudi počasen. Spustile so ga tri spremembe.

• Za P-256 smo prevzeli zbirnik nistz256 iz OpenSSL-a in ringa (ADR-130), s tabelami s fiksno bazo za podpisovanje in preverjanje podpisov CA (ADR-110, ADR-111).
• X25519 je prepisan na štiri 64-bitne ude z ukazi MULX/ADX (ADR-131).
• Nato smo profilirali še preostanek (ADR-132, ADR-200).

Številke se med zagoni razlikujejo za okoli 10%, zato smo zapisali razpon namesto ene vrednosti. Skupaj je to približno petkrat manj procesorskega časa za rokovanje.

Kaj smo se naučili o memcpy-ju. Ko je kriptografija padla, je profil pokazal nekaj, česar nismo pričakovali: funkcije mem* (memcpy, memmove, memset) so porabile 7% rokovanja, 13 do 39% poti zapisa TLS (39% za 64 B, 13% za 4 KiB) in 17 do 34% razdeljevanja PUBLISH-a. Zamenjali smo jih z zbirnikom SSE2 za x86_64 (ADR-200), z diferencialnimi testi proti referenčni implementaciji za vse velikosti, poravnave in prekrivanja. Na klic je to 55 do 75 ciklov proti 7 do 12 za 1 do 64 bajtov.

Branje grafa: manjši ko je zapis, večji del časa odide za kopiranje, zato je tudi dobitek večji. Za majhna sporočila, ki so večina prometa MQTT, je to tisto, kar šteje.

Kaj to ne pomeni. Na izvornem x86_64 smo OpenSSL 3.5.5 merili samo kot referenco za zbirnik (ADR-130), ne kot primerjavo izdelkov. Primerjave Linux plus Mosquitto na istem VPS-ju (naloga X11) še nismo naredili. Zato ne trdimo, da je urMQTT hitrejši od Linuxa: ni izmerjeno. Zgornje številke primerjajo urMQTT sam s seboj.

Preobremenitev je bil drugi rezultat. Na VPS-ju, z enega Maca (RTT 35 ms), je 128 odjemalcev dalo 618 rokovanj na sekundo, 256 odjemalcev 393, 512 odjemalcev pa 67, z na tisoče zavrnjenih povezav. To ni bil plato, ampak sesutje. Vzroke smo našli v kodi (dva sta potrjena v QEMU-ju/HVF-ju, na VPS-ju se ju ni dalo ponoviti), več hkrati: zavrnjena povezava je odjemalca vrnila prek naslednjega segmenta, ki nosi veljaven piškotek SYN, zavrnitev z RST je odjemalcu sporočala, naj takoj poskusi znova, sprejem pa je bil O(vrsta). Popravek (ADR-080 do ADR-082) izpusti SYN, ki ne bi bil sprejet, si zapomni zavrnjene tokove, drži sprejem v O(1) in šteje rokovanja po jedru. Možno je (hipoteza, ni preverjeno), da je bil del vzroka tudi na odjemalcu: orodje za obremenitev je zapiralo prvo, zato je en Mac s 16 384 efemernimi vrati in TIME_WAIT-om 30 sekund omejen na okoli 550 povezav na sekundo. Zato pravega stropa strežnika še nismo izmerili.

Obljuba 2: surovi disk, a previden

Kaj smo načrtovali. Obdržati lasten razpored brez datotečnega sistema in dodati vse tisto, kar datotečni sistem sicer daje: poravnavo, rast, discard, varnostne kopije in preverjanja. Zakaj ne datotečni sistem. O tem smo razpravljali in odločitev je potrjena: urMQTT piše eno bazo, en telemetrijski dnevnik in lastne metapodatke, ne potrebuje imenikov, dovoljenj ali imen datotek, vsaka dodatna plast pa bi bila še več kode v zaupanja vrednem delu in še en način, da zapis tiho izgine. Disk je GPT s particijo ESP in eno particijo podatkov urMQTT, na kateri je lasten razpored.

Kaj smo zgradili (S2 do S6).

• Razpored v2 (S2). Topologija diska, poravnava na 1 MiB ali optimalno velikost V/I, celi fizični bloki, par superblokov A/B z generacijo (ADR-140). Razpored v1 kernel zavrne z jasnim sporočilom, preseli pa ga izvenmrežno orodje urmqtt-disk migrate (ADR-141): privzeto je poskusni prehod, kopira se in šele nato preklopi, z vrnitvijo in vbrizgavanjem napak pri vsakem zapisu.
• Rast (S3). Ob zagonu lahko disk zraste (nikoli se ne zmanjša), na virtio-blk pa tudi med delovanjem, prek prekinitve spremembe konfiguracije (ADR-142, ADR-143).
• Discard in write-zeroes (S4). Tanko dodeljeni diski vračajo prostor gostitelju. V testu je datoteka qcow2 na gostitelju padla s 62 na 16 MiB, ko so potekli telemetrijski segmenti, obnovitev pa nikoli ne zaupa vsebini, ki je bila zavržena.
• Varnostna kopija baze na disku (S5). Kopija A/B s SQLite online backup API-jem v korakih po 16 strani: najdaljši korak 4,6 ms proti 445 ms, kadar se kopira z enim klicem. Commiti med kopiranjem so imeli maksimum 2,4 ms proti 2,2 ms brez njega. Če quick_check ob zagonu ne uspe, se baza obnovi iz kopije.
• Čiščenje in omejen zagon (S6). Scrubber bere disk z omejenim V/I proračunom in poroča o poškodovanih zapisih, zagon pa prebere samo najnovejši segment vsake particije, tako da čas zagona ne raste z velikostjo telemetrijske regije. Tako smo zaprli težavo, ki smo jo izračunali vnaprej: na velikem disku bi popolna obnovitev trajala od minut do več deset minut.

Celotna skupina dimnih testov za shranjevanje prehaja na obeh arhitekturah: 79 uspešnih, 0 neuspešnih, na aarch64 pod HVF-jem in na x86_64 pod TCG-jem. Izmerili smo tudi, da S4 ni upočasnil baze: 53,3 tisoč vstavljanj na sekundo v paketih prej in potem, brez merljive razlike.

Kaj je presenetilo. Koliko »preprostega« razporeda odpade na robne primere: virtio-scsi in virtio-blk poročata topologijo na različne načine, nepopoln zapis sredi migracije pa mora vedno pustiti vsaj eno veljavno različico. Zato je vsak zapis na poti migracije in rasti šel skozi vbrizgavanje napak.

Kaj je odprto. Strani SQLite nimajo kontrolne vsote, zato spremenjenega bita znotraj vrednosti v vrstici baza ne bo zaznala; telemetrijski zapisi in vsebina kopij imajo CRC in se zaznajo. Šifriranje diska (S7) ni končano.

Obljuba 3: dokazljivo varno, kolikor nam uspe

Utrjevanje (H4). Alokator briše sproščeni pomnilnik in ga preverja ob ponovni uporabi, zazna dvojno sprostitev, kazalce proste liste veže z XOR-om in ob sprostitvi ničli ključe (ADR-170). Zaščita sklada (-Zstack-protector=strong, 1315 funkcij, SQLite pa s -fstack-protector-strong, ADR-171). Poročila o napakah v produkciji ne vsebujejo registrov ali naslovov (ADR-172). KASLR na obeh arhitekturah: kernel je PIE in ga Limine premakne za okoli 19 bitov, naključno pa se postavijo tudi kopica, skladi in okno MMIO (ADR-173). Na aarch64 MTE označuje kopico (ADR-174), vendar samo pod TCG-jem: HVF in x86 ga nimata. kCFI smo ovrednotili in ga nismo sprejeli, ker prevajalnik na pripetem nightlyju pade z notranjo napako; IOMMU je odložen skupaj z bare metalom (ADR-175, ADR-176).

Ceno smo izmerili, ne predpostavili. Na poti rokovanja (dp-bench, aarch64 HVF, polna rokovanja TLS 1.3 + mTLS + CONNECT):

Skupaj je torej cena na poti rokovanja približno 5% za dele, izmerjene čisto, s PIE-jem in oznakami pa pride okoli 7% na enem in okoli 11% na štirih jedrih, a je ta meritev šumna. Menimo, da je sprejemljiva, vendar je nismo ponovili na VPS-ju x86_64.

Vredno je primerjati s številko iz prvega besedila (862 rokovanj na sekundo na enem jedru). Isto orodje danes, s strojnim šifriranjem na aarch64 (X0b) in nizom pospešitev, ki so prišle od takrat, da 1941 pred utrjevanjem. Prispevka vsake spremembe nismo izolirali, zato o vzroku ne trdimo ničesar.

Kako je preverjeno in kaj ni. H5 je dodal Miri na podmnožico gostiteljskih cratov, dokaze Kani, sanitizerje, model-fuzzer za ACL in poročila o pokritosti. Kani je dokazal record_len v TLS-u, parse v TCP-ju in dve aritmetiki kolesa časovnikov. Ni dokazano (potekel čas): oba dekodirnika MQTT, oba razčlenjevanja konfiguracije in obnašanje kolesa časovnikov; delo CI za Kani zato še ne blokira. Miri ne more izvajati zbirnika. Dobavna veriga (H9): CycloneDX SBOM s 215 komponentami, cargo-vet prehaja s 39 v celoti pregledanimi in 140 izjemami, cargo-deny pa je nastavljen tako, da varnostna obvestila obravnava kot padec CI-ja (ta dela CI so bila doslej preverjena samo lokalno, ne na GitHubu, negativni test pa ni bil zagnan), skupaj z VULNERABILITY-HANDLING.md. Iskreno stanje: od 67 različic tretjih cratov, povezanih v kernel, jih je 53 izjem, ne pregledov. Vet dokazuje, da se množica odvisnosti ne more spremeniti brez vidne razlike, ne da je bil TCB pregledan. Lastnega pregleda nobenega cratea nismo napisali.

SNTP (T1) je v tem smislu majhna zgodba o varnosti: je neobvezen, samo proti zasebnim strežnikom IPv4, z največjim skokom in pogojem, da se viri ujemajo (mediana, večina znotraj ene sekunde). Ura, ki jo lahko premakne kdor koli na poti, ni ura, ki ji smemo zaupati pri veljavnosti certifikatov.

Na Macu: aarch64 izvorno in x86_64 z emulacijo

Razvijamo na Macu, ta pa ima dva načina za zagon iste kode in sta zelo različna.

Pravilo je preprosto: številke pod TCG-jem so emulacija in jih ne navajamo kot zmogljivost. Zmogljivost x86 merimo samo na pravem VPS-ju. Zato kripto številke zgoraj izhajajo z VPS-ja Contabo, ne z Maca.

Lekcije

• Merite na pravem stroju, preden optimirate. Prvi pristop je bil optimirati tisto, za kar smo mislili, da je počasno; šele diagnostika na VPS-ju je pokazala 1,2 ms in kje natančno odhaja čas.
• Preobremenitev je ločena lastnost. Sistem, ki je hiter pod obremenitvijo, se lahko sesuje nad njo; zavrnitev mora biti cenejša od sprejema.
• Profil preseneča. Največji posamični dobitek za majhna sporočila ni bil v kriptografiji, ampak v kopiranju pomnilnika.
• Disk brez datotečnega sistema zahteva več dela, ne manj. Tisto, kar datotečni sistem sicer daje (poravnavo, rast, discard, kopije, preverjanja), moramo napisati in preveriti sami, vsak korak z vbrizgavanjem napak.
• Poštenost v številkah. Meritve pomnilnika na deljenem VPS-ju se med zagoni razlikujejo do 10-krat in o kodi ne povedo ničesar, zato jih ne navajamo. Kripto številke so stabilne do okoli 10%.
• Hitrost razvoja ni zrelost. Testi in ADR-ji rastejo skupaj s kodo, a štirje dnevi niso pravo obratovanje.

Kaj sledi

• H6: SQLite, izoliran na ravni EL0, tako da napaka v bazi ne odpre jedra.
• H7: preostanek varnosti časa (NTS in obdelava skokov); SNTP je šele prvi korak.
• X11: primerjava z Linuxom in Mosquittom na istem VPS-ju, šele takrat je smiselno govoriti o relativni hitrosti.
• Izdaja: prva javna objava za VPS (KVM), s podpisanimi artefakti in navodili.
• Po izdaji: bare metal (X12 do X16), IOMMU in Secure Boot ter šifriranje diska.

Koda je na github.com/zeljan-alduk/urMQTT, docs/PROGRESS.md pa je še naprej edini vir resnice o tem, kaj res deluje. Predalfa, kot prej; prijave napak in varnostne prijave po navodilih v SECURITY.md so dobrodošle.

Tako je nastal urMQTT: unikernel, ki je MQTT posrednik. Jedro, TCP/IP, TLS 1.3, MQTT in vgrajena podatkovna baza v enem Rustovem binarnem programu, ki se zažene z enega ISO-a. Ni procesov, ni sistemskih klicev, ni lupine. Prva platforma, na kateri se gradi in preizkuša, je aarch64, isto kodo pa pripravljamo za x86_64, prek UEFI in klasičnega BIOS-a, ter za pravo strojno opremo: cilj je en ISO, ki se zažene na vseh. Projekt je odprtokoden pod licenco MIT ali Apache 2.0, v tem besedilu pa želimo zapisati, kje smo, kako je zgrajen znotraj in česa smo se med delom naučili.

Kaj natančno pomeni »unikernel«

Običajen posrednik je program, ki teče na operacijskem sistemu. urMQTT pod sabo nima operacijskega sistema: sam se zažene prek UEFI firmwara in zagonskega nalagalnika Limine, vzpostavi lastne tabele strani, programira krmilnik prekinitev in časovnik, prek PCIe poišče naprave virtio, naslov pridobi z DHCP in posluša na enih vratih. Vse, kar bi sicer počeli jedro, gonilniki, omrežni sklad in aplikacija, je tu en ELF, ki teče na ravni EL1.

Primerjava s tipično namestitvijo govori sama zase:

Prednostne naloge so v tem vrstnem redu: varnost, razširljivost, večjedrna zmogljivost, majhen odtis in nespremenljiva namestitev. Kadar sta dva cilja v navzkrižju, zmaga tisti, ki je na tem seznamu višje.

Kje smo zdaj

Projekt je v predalfa fazi, vendar je zaprtih sedemnajst razvojnih mejnikov, od M0 do M17. Danes urMQTT streže MQTT 3.1.1 prek TLS 1.3 z obveznimi odjemalskimi certifikati, stanje pa hrani v SQLite na surovem disku. Na kratko, kaj že deluje:

• Jedro: lastni vektorji izjem z dekodiranimi poročili, lastne tabele strani z uveljavljenim W^X, zaščitne strani, PAC in BTI, kjer ju procesor ima, GICv3 in GICv2, generični časovnik, SMP do 64 jeder.
• Odkrivanje strojne opreme iz DTB ali ACPI v en opis platforme, z enakim rezultatom iz obeh virov.
• Gonilniki: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi in virtio-rng ter CSPRNG, zasejan s strojno entropijo.
• Omrežje: lasten DHCPv4, ARP, ICMP in strogi IPv4, nato lasten TCP samo za strežniško stran: piškotki SYN, hierarhično kolo časovnikov, NewReno, združevanje ACK-jev, brez stanja TIME_WAIT.
• TLS: samo TLS 1.3, obvezni mTLS, identiteta naprave iz CN ali SAN URI; rokovanje opravi rustls, nato pa lasten sloj zapisov z AES-128-GCM in ChaCha20-Poly1305. Nadaljevanje seje s PSK-vstopnicami, seznam preklicev, nadzor sprejema že pri rokovanju.
• MQTT: kodek brez kopiranja, fuzziran in testiran s pravimi odjemalci mosquitto; QoS 0 in 1, nadomestni znaki, obdržana sporočila, oporoka (LWT), trajne seje, ACL z omejitvijo na devices/{id}/#, omejitve hitrosti po napravi.
• Shranjevanje: SQLite znotraj jedra prek VFS nad surovim diskom, v načinu WAL, s preverjanjem celovitosti ob zagonu; register naprav, preklici, obdržana sporočila, trajne seje z vrstami sporočil za naprave, ki niso povezane; za vsako jedro ločen telemetrijski dnevnik s CRC na zapis in obnovitvijo po sesutju.
• Delovanje in nadzor: nadzorni časovnik za obdelovalce, preverjanje zdravja, omejeno beleženje, syslog in statsd prek UDP, sprejem, ki preživi nevihte ponovnih povezav.
• Dostava: bitno enake ponovne izgradnje, preverjene v CI, ISO in surova GPT slika diska, podpisi minisign, navodila za KVM, Proxmox in Hetzner.

Vsak korak je označen z mejnikom, ki ga je prinesel, datoteka docs/PROGRESS.md v repozitoriju pa je edini vir resnice o tem, kaj res deluje.

Arhitektura v treh slikah

Celoten načrt je opisan v docs/ARCHITECTURE.md, razlogi za vsako pomembnejšo odločitev pa so zapisani kot ADR-ji v docs/DECISIONS.md. Tu je pregled.

Plasti

Od vrha navzdol: posrednik (seje, drevo tem, QoS, obdržana sporočila, oporoke, ACL, omejitve), kodek MQTT, TLS, TCP, omrežna plast in nato gonilniki. Ob tej glavni poti stoji shranjevanje (SQLite in telemetrijski dnevnik), pod vsem pa upravljanje pomnilnika, odkrivanje platforme in konfiguracija, ki je ob izgradnji prevedena v konstante, skupaj z vgrajenim certifikatom CA, strežniškim certifikatom in ključem. Hipervizor z napravami virtio je edino, kar je zunaj slike.

Nit na jedro, brez skupnega stanja

Vsako podatkovno jedro poganja lastno zanko z lastnim skladom TCP, stanji TLS, delom posrednika (seje in drevo tem), predpomnilnikom kopice in particijo telemetrije. Jedra ne delijo nobenega spremenljivega stanja, le omejene obroče brez ključavnic, po enega za vsak urejen par jeder. Najvišje jedro poganja SQLite in nič drugega.

Omrežna kartica ima danes en par vrst, ki ga drži jedro 0. To vsak tok MQTT glede na Toeplitzev hash njegove četverice usmeri na eno od delovnih jeder in pošlje tisto, kar delovna jedra vrnejo. Seja živi na svojem domačem jedru, določenem s hashem identifikatorja odjemalca, zato prevzem, oporoke in trajnost nikoli ne prečkajo jeder. Povezava, ki pristane na drugem jedru, tam obdrži svoj TCP in TLS, navaden MQTT pa posreduje domačemu jedru z nadzorom pretoka, ki temelji na kreditih. Vsako usmerjeno sporočilo se razdeli tudi na preostale dele posrednika, od katerih vsak drži repliko obdržanih sporočil.

Ta model drže skupaj tri pravila. Obdelava do konca: prejeti paket se v celoti obdela na enem jedru, od TCP prek dešifriranja TLS na mestu, razčlenjevanja MQTT in usmerjanja do šifriranega odgovora, brez vrst opravil in brez kopiranja v aplikacijske medpomnilnike. Prilagodljivo poizvedovanje: pod obremenitvijo se vrste za sprejem aktivno poizvedujejo, v mirovanju pa se jedro vrne k prekinitvam in WFI; obdelovalci prekinitev prekinitev le potrdijo in označijo delo. Nadzorni časovnik: utrip na 10 ms na jedro ujame obdelovalce, ki presežejo svoj proračun.

Življenje enega PUBLISH-a

Naprava pošlje zapis TLS. Omrežna kartica ga preda zanki jedra z deskriptorjem, brez kopiranja. Zanka preveri TCP, dešifrira TLS na mestu in razčleni MQTT iz izposojenega medpomnilnika, nato v pomnilniku preveri ACL, omejitev hitrosti in pot skozi drevo tem. Če drugo jedro ta tema zanima, prejme sporočilo za usmerjanje s sklicem na vsebino in identifikatorjem teme; baza prejme telemetrijski zapis ali posodobitev obdržanega sporočila, v paketu. Odgovor PUBACK se šifrira neposredno v izhodni medpomnilnik in združi s TCP ACK, tako da napravi odide en segment. Drugo jedro sporočilo stane eno šifriranje na naročnika v trenutku pošiljanja.

Koliko stane ena povezava

Cilj je največ 512 bajtov na nedejavno povezavo TLS, z željo po 256. Medtem ko povezava miruje, zanjo ni v medpomnilniku ničesar: prejeti podatki se obdelajo neposredno iz omrežnega okvirja, medpomnilniki za pošiljanje, zapise in MQTT pa obstajajo samo, dokler je kaj nedokončanega ali nepotrjenega. Jedro to meri samo: natančni števci kopice v zahtevanih bajtih in v blokih, ki jih zasedajo, zapisani vsakih deset sekund kot kopica nad osnovno ravnjo na odprto povezavo.

Izmerjeno pod HVF s štirimi virtualnimi jedri, od tega tremi delovnimi, pri čemer vsaka naprava drži povezavo mTLS in eno naročnino s QoS 1, vključno z zaokroževanjem alokatorja:

Bazen omrežnih okvirjev je fiksnih približno 2 MiB, kar je okoli 200 B na povezavo pri desettisoč povezavah in okoli 2 B pri milijonu. Več od tega nismo mogli izmeriti: uporabniško omrežje QEMU na macOS je prenehalo sprejemati povezave pri 10 197, približno na meji 10 240 deskriptorjev procesa QEMU. Število pada, ko se fiksni deli porazdelijo na več povezav, zato ne raste z njihovim številom.

Varnostni model

Varnost je prva prednostna naloga in dobi vse spore z ostalimi cilji. Model ima več plasti:

• Ena vrata. TCP 8883, samo TLS 1.3, obvezni odjemalski certifikati, podpisani s CA, vgrajenim v sliko. Identifikator odjemalca MQTT mora biti enak identifikatorju naprave iz certifikata.
• Brez vhodov. Ni lupine, konzolnega vnosa, SSH, administracijskega API-ja, dinamične kode, SQL, dostopnega prek omrežja, niti datotečnega sistema.
• Pomnilniška varnost. Rust, s forbid(unsafe_code) v protokolnih paketih; vsak blok unsafe ima komentar // SAFETY:, ki ga preverja lint, na zunanji vnos pa ni panike: clippy v paketih na podatkovni poti prepoveduje unwrap, expect, indeksiranje in panic!.
• Ublažitev izkoriščanja. W^X se uveljavlja s kodiranjem deskriptorjev in bitom SCTLR_EL1.WXN ter se revidira ob vsakem zagonu. Tabele strani so po zagonu samo za branje, brez zapisljivega aliasa. Spodnja polovica naslovnega prostora je izključena. Vsak sklad ima zaščitne strani, izjeme pa tečejo na ločenem skladu. PAC in BTI se vklopita, ko ju procesor podpira, to pa preverjajo dimni testi.
• Odpornost na zlorabe. Piškotki SYN; sprejem zavrne nove povezave, pred kakršno koli kriptografijo, ko je kopica nizka, ko baza zaostaja, ko je v teku preveč rokovanj na jedro ali na izvorni naslov ali ko je hitrost rokovanj previsoka. Omejitve hitrosti po napravi, omejene vrste, okno TCP, vezano na protipritisk posrednika, omejeno beleženje, nadzorni časovnik in preverjanje zdravja.
• Nespremenljivost. Konfiguracija, CA in strežniški ključ so vgrajeni v sliko. Sprememba česar koli pomeni novo sliko.

Model groženj je zapisan v docs/SECURITY.md.

Shranjevanje brez datotečnega sistema

Podatki živijo na ločenem disku, virtio-blk ali virtio-scsi, na katerem ni datotečnega sistema. Razpored je minimalen in lasten:

LBA 0      [ superblok: magija · različica razporeda · uuid · tabela regij · CRC-32C ]
LBA 8, 16  [ tabela velikosti datotek, reži A/B (zmaga najnovejša veljavna) ]
LBA 64     [ SQLite glavna baza ½ ][ SQLite WAL ⅛ ][ dnevnik 1 MiB ][ telemetrijski dnevnik: 8 particij … ]
zadnjih 4 KiB [ prostor za samopreverjanje blokovne naprave ob zagonu ]

SQLite (vendorirana 3.54.1, s preverjanjem izvlečka ob izgradnji) je v jedro preveden s clangom, brez standardne knjižnice, in uporablja fiksno kopico memsys5. Njegov VFS preslika tri fiksne datoteke na regije diska. Deluje v načinu WAL z locking_mode=EXCLUSIVE, zato ne potrebuje indeksa v deljenem pomnilniku, in s synchronous=FULL; če quick_check ob zagonu najde napako, se sistem varno ustavi. V bazi so register naprav, preklici, obdržana sporočila in trajne seje z vrstami sporočil QoS 1 za naprave, ki niso povezane.

Jedro za bazo, tisto z najvišjo številko, poganja SQLite in nič drugega. Podatkovna ravnina mu pošilja spremembe stanja prek obroča SPSC brez ključavnic; te zbira v eno transakcijo vsakih 5 ms ali vsakih 512 operacij, potrditve pa vrača z drugim obročem. Prazen disk se formatira ob prvem zagonu; vsega drugega se nikoli ne formatira čez.

Telemetrija gre po drugi poti. Vsak sprejeti PUBLISH na temah iz storage.telemetry_topics odide v particijo telemetrijskega dnevnika svojega jedra: obroč segmentov s CRC na zapis, osoljenim z zaporedjem segmenta, tako da se stari prehodi obroča nikoli ne pojavijo znova. Jedra zapise predajo bazi z lastnim obročem, brez kopiranja, ta pa jih izpiše vsakih 5 ms ali vsakih 256 KiB. Ob zagonu obnovitev ohrani vsak izpisani zapis, odreže nedokončan rep in nadaljuje v novem segmentu. Hramba je po velikosti, prek obroča, in po starosti, prek retention_days. To smo preverili z milijonom zapisov in z kill -9 sredi pisanja.

Številke

Orodje za obremenitev v tools/loadgen počne tri stvari: nevihto rokovanj TLS 1.3 z mTLS in CONNECT, dolgotrajne povezave s PINGREQ, ki vsako sekundo objavljajo telemetrijo, in nevihte ponovnih povezav. make bench na Apple M4 Pro pod HVF daje:

Število v gostu, kjer sta odjemalec in strežnik znotraj istega virtualnega stroja in vsako delovno jedro dela samo zase, kaže, da podatkovna ravnina skalira linearno. Omrežno število omejuje enonitno uporabniško omrežje QEMU, ne gost; tudi to je zapisano kot ADR-032.

Nevihte ponovnih povezav testiramo tako, da se vse naprave povežejo naenkrat, zavrnjene poskuse ponavljajo z zakasnitvijo in nato vse padejo brez DISCONNECT. Parameter heap_limit_mb= v razvojnem načinu prisili sprejem, da kopico šteje za manjšo, kot je, tako da je nevihto, večjo od kopice, mogoče preizkusiti z malo vtičnicami. V enem takem krogu s 3 000 napravami se jih je v 36 sekundah povezalo 1 368, 5 619 poskusov pa je bilo urejeno zavrnjenih, z omejitvijo 8 MiB; pomnilnik se je po nevihti vrnil.

Kako delamo

Projekt vodi pisna specifikacija, PROMPT.md, z načrtom mejnikov, in vsak mejnik se konča z istim obredom: make check in make smoke zelena, en commit z oznako M<n>, zapis v docs/PROGRESS.md in ADR za vsako odločitev, ki ni očitna. Pravila so kratka in o njih se ne pogajamo: brez panike na zunanji vnos, unsafe samo v strojnih paketih in paketih FFI ter vedno s komentarjem, brez alokacij na vroči poti, komentar ob vsakem vrstnem redu atomskih operacij, vsaka omejitev prihaja iz konfiguracije, namerni začasni deli pa padejo glasno.

CI dela več, kot bi jih mi ročno zmogli: fmt, clippy za gostitelja in za aarch64-unknown-none, typos, actionlint in shellcheck; teste na Linuxu in macOS na arm64; izgradnjo jedra za razvojno in produkcijsko konfiguracijo z velikostjo ELF-a v povzetku; zagon pod QEMU z vsemi scenariji dimnega testa in shranjevanjem serijskih zapisov; cargo-deny za svetovalna obvestila, licence in vire; minuto fuzzinga na vsako od enajstih tarč, ponoči pa deset minut na tarčo s predpomnjenim korpusom. Poleg tega CodeQL, OpenSSF Scorecard, Dependabot in objava s poreklom SLSA. Vsaka tuja akcija je pripeta na polni commit SHA.

Ponovljivost razumemo dobesedno: make repro zgradi HEAD dvakrat v svežih delovnih drevesih in primerja ELF, ISO in surovo sliko bajt za bajtom. Objave so podpisane z minisign, artefakte pa je mogoče preveriti z gh attestation verify. Produkcijska slika vsebuje zasebni ključ strežnika, zato je sam ISO skrivnost; slike ob objavah na GitHubu so razvojne, z začasnimi ključi, in služijo samo za preizkušanje.

Kaj smo se naučili

Nekaj lekcij, ki so spremenile načrt:

• Lasten TCP se je vendarle izplačal. Prototip je tekel na smoltcp in nam je dobro služil do M13. A strežnik, ki drži stotisoče povezav, ne potrebuje odjemalskega TCP, potrebuje piškotke SYN, kolo časovnikov in stanje s 96 bajti. V M14 smo smoltcp zamenjali z lastnim skladom samo za strežniško stran, s testi simulirane izgube in fuzzingom segmentov.
• Pomnilnik merite od znotraj. Ocene na povezavo so bile neuporabne, dokler jedro ni samo začelo šteti kopice v blokih alokatorja in ne v zahtevanih bajtih. Šele takrat smo videli, kam dejansko odhaja 512 bajtov, in se spustili na 494.
• Orodje za testiranje je del izdelka. Največja omejitev ni bilo jedro, temveč uporabniško omrežje QEMU in število efemernih vrat na razvojnem računalniku. Za sto tisoč in več povezav potrebujete vmnet-shared na macOS ali Linux s KVM, vmesnikom tap in več odjemalskimi naslovi.
• SQLite brez operacijskega sistema je mogoč, a le ob strogih pogojih: fiksna kopica, izključno zaklepanje brez deljenega pomnilnika, VFS, ki ne ve za datoteke, in sprejem, ki bazi ne pusti zaostati.
• Nevihte ponovnih povezav so običajno stanje, ne izjema. Ko mobilno omrežje pade in se vrne, tisoči naprav trkajo hkrati. Zato sprejem povezavo zavrne pred kakršno koli kriptografijo, vsaka zavrnjena povezava pa stane skoraj nič.

Kaj sledi

Delo po M17 je načrtovano v treh smereh, vrstni red med njimi pa je zapisan v docs/PLAN.md. Nič od tega še ni zgrajeno.

• En ISO za več platform. Ista datoteka urmqtt-<env>-<različica>.iso in ena surova slika GPT, ki se zaganjata na aarch64 UEFI, x86_64 UEFI in x86_64 BIOS, v virtualnih strojih in na pravi strojni opremi, začenši z enim računalnikom Intel. Še vedno naprava z vsem znotraj, ponovljiva in podpisana.
• Surovi disk, brez datotečnega sistema. Specifikacija formata na ravni bajta, gostiteljsko orodje urmqtt-disk, ki si s jedrom deli razčlenjevalnike, poravnava regij na 1 MiB, rast diska s podatki, discard za tanko dodeljene diske, posnetki baze A/B, preverjanje bitov in, po izbiri, šifriranje AES-256-XTS s strojnim AES.
• Dokazljivo varno. Preklic in seznam dovoljenih naprav med delovanjem prek podpisanega kontrolnega kanala, brez nove slike; diferencialno in skladnostno testiranje lastnega TLS in TCP; KASLR, zaščita sklada, kCFI, MTE in utrjen alokator; SQLite, izoliran na ravni EL0; Secure Boot; SBOM in cargo-vet; in na koncu paket za zunanjo revizijo.

Platforme, ki ponujajo samo naprave, ki niso virtio, kot sta AWS ENA ali Azure MANA, zaenkrat niso podprte. Raspberry Pi 4 in 5 kot gostitelj KVM, Hetzner CAX in Oracle Ampere A1 so dokumentirani in podprti s kodo, vendar še niso preizkušeni na pravi storitvi.

Preizkusite

Repozitorij je na github.com/zeljan-alduk/urMQTT. Z Rustom s pripeto nightly verigo orodij in QEMU so make certs, make run in en odjemalec mosquitto dovolj za prvi PUBLISH prek mTLS na vašem računalniku. Opozorilo z začetka velja tudi na koncu: to je predalfa in vse, kar deluje, piše v docs/PROGRESS.md. Prijave napak, vprašanja o zasnovi in varnostne prijave po navodilih v SECURITY.md so dobrodošle. O vsakem naslednjem mejniku se bomo oglasili tukaj.

Na tem blogu zapisujemo, kar smo se na tej poti naučili. Ne marketinških besedil, temveč konkretne zapiske: kaj je šlo narobe, kako smo to rešili in kaj bi danes naredili drugače.

O čem bomo pisali

• Plačevanje vozovnic v javnem prevozu. Brezstične kartice, moduli SAM, delovanje brez omrežja in vse, kar mora terminal prenesti v vozilu, ki se trese dvanajst ur na dan.
• Mobilne aplikacije na terenu. Android in Flutter na napravah, ki niso navadni telefoni: s čitalniki kartic, tiskalniki in baterijami, ki morajo zdržati celo izmeno.
• Backend in nadzor voznega parka. Kako vedeti, da ima naprava v vozilu težavo, preden jo prijavi voznik.
• Strojna oprema. Od prototipa na mizi do tiskanega vezja, ki gre v serijsko proizvodnjo, in vse napake vmes.
• Lokalni modeli umetne inteligence. Kje imajo modeli na lastni strojni opremi smisel in kje sta oblak in API preprosto boljša izbira.

Kako bomo pisali

Kratko in konkretno, s kodo in številkami, kjer jih imamo. Objavljali bomo, ko bomo imeli kaj povedati, ne po urniku. Objave pišemo v hrvaščini in jih prevajamo v vse jezike te strani; spremljate nas lahko tudi prek RSS.

Če vas zanima kakšna tema ali delate na podobnem problemu, nam pišite na info@aldo.tech.