Napomena unaprijed ostaje ista: projekt je pred-alfa, prvo izdanje je samo za VPS-ove s KVM-om, a brojke mjere kod, testove i određene pokuse, ne zrelost u produkciji.

Kako je to izgledalo u vremenu

Od prošlog teksta (31.10. u 23:00) do danas (1.11. u 20:41) u repozitoriju je 59 novih commitova, ukupno 178. Svi su nastali u jednom kalendarskom danu, pa vrijedi isto upozorenje kao prije: projekt se gradi uz Claude Code (commitovi nose Co-Authored-By: Claude), plan, kod, testovi i ADR-ovi nastaju u kratkim zatvorenim petljama, a brojke ispod govore o količini koda i provjera, ne o tome koliko je ljudskog rada u njima.

Brojke su izračunate istom metodom kao u prošlom tekstu: svi .rs fajlovi izvan vendor/ i fuzz/, #[test] funkcije, naslovi ## ADR- u docs/DECISIONS.md.

Radilo se paralelno na više grana, pa redoslijed commitova nije strogo redoslijed rada. ADR-ovi su numerirani do 232, ali numeracija ima praznina (dio je preimenovan pri spajanju grana); brojimo naslove, ne najveći broj. Izdanja: v0.2.0 (1.11., 18:45 UTC) i v0.2.1 (1.11., 20:22 UTC), oba označena kao pre-release.

H6: SQLite u korisničkom načinu rada

Što smo planirali. SQLite je 254 268 redaka C-a koji parsira bazu, WAL i dnevnik s diska, a disk može biti izrađen ili izmijenjen. Dotad je radio u jezgri, s pravima jezgre. Što smo izgradili (ADR-210 do ADR-212): SQLite, njegovi libc dijelovi i heap premješteni su u zaseban program, dbworker, koji radi na EL0 (aarch64) odnosno ring 3 (x86_64), u vlastitom adresnom prostoru. Jezgra više ne linka SQLite. Radnik s jezgrom razgovara kroz zajednički prozor memorije i dvanaest sistemskih poziva, a svaka duljina i pomak koji se vrate provjeravaju se prije upotrebe. Greška u radniku (nedopušten pristup, nedefinirana instrukcija, prekoračen vremenski proračun od 30 s) završava poziv, radnik se ponovno pokreće i baza se otvara iz WAL-a kao pri podizanju; nakon 5 ponovnih pokretanja u minuti pohrana se proglašava neispravnom, a ne pokreće se u beskraj.

Cijena, izmjerena na aarch64 pod HVF-om, ista VM, jezgra s ugrađenim SQLite-om prema jezgri s radnikom, šest naizmjeničnih pokretanja svake:

Zapisi na disk (1 572) i flushevi (319) su identični, kako i mora biti. Nije izolirano ovo: jezgra i dalje vjeruje onome što radnik vrati, nakon provjere oblika. Kompromitirani radnik može lagati (na primjer vratiti praznu listu opozvanih certifikata, a time ih "odopozvati"), ali ne može čitati memoriju jezgre, TLS ključeve ni ključeve tiketa. Nema KPTI-ja, pa curenja tipa Spectre/Meltdown nisu spriječena i ne tvrdimo ništa o njima; PAC ključ dijele EL0 i EL1. Na x86_64 cijenu prebacivanja nismo izmjerili na KVM-u (pod TCG-om bi broj bio besmislen), a samo fuzziranje radnika i protokola nije gotovo. Skup testova za pohranu (79 scenarija, svaki vrti SQLite u radniku) prolazi na aarch64 HVF-u i x86_64 TCG-u, na aarch64 TCG-u 76 (jedan se preskače jer TCG nema MSI-X).

H7 je zatvoren, ali ne onako kako smo najavili. Donja granica vremena (ADR-050) i SNTP s konsenzusom (T1) pokrivaju opseg H7; NTS (RFC 8915) ostaje izvan opsega i zapisan je kao preostali rizik, a ne kao nešto što radi. Ne smatramo da je sigurnost vremena "riješena", nego da je njezin dokaziv dio gotov.

Nova mrežna opcija. Contabo ne daje DHCP prilagođenom ISO-u, pa je VPS dotad tražio drugu sliku od laboratorijske VM. Sada network.mode = "auto" (ADR-214) prvo pita DHCP, a ako zakupa nema u zadanom roku (dhcp_timeout_s, zadano 15 s) ili ga izgubi, primjenjuje zadanu statičku adresu. Isprobano ručno na QEMU-u (s DHCP-om koristi zakup, bez mreže se nakon 5 s vraća na statičku adresu); smoke scenarija za to još nema.

X11: usporedba s Mosquittom na istom VPS-u

Ista vrsta stroja kao u prošlom tekstu (Contabo, 4 vCPU AMD EPYC, 8 GiB), opterećenje s Linux domaćina 15 ms dalje, uzajamni TLS 1.3 s istim certifikatima na obje strane, Mosquitto 2.0.21 na Debianu 13 bez trajnosti. Metoda i odluke su u ADR-213, sirovi podaci u docs/perf-results/. Medijan od tri pokretanja.

Što to znači, a što ne. Rukovanja su donje granice za oba poslužitelja: generator opterećenja je dijeljena VM s 60 do 70 % ukradenog procesorskog vremena i pri 128 niti bio je blizu vlastitog ograničenja, a urMQTT-ove radne jezgre bile su zauzete samo 12 do 13 %. Omjer pri 128 klijenata (oko 2,2 puta) najsmisleniji je; pri 32 i 64 većinom mjeri čekanje klijenata. Brojke memorije ne broje isto (hep jezgre nasuprot RSS-u procesa), pa je "oko 50 puta manje" red veličine, ne precizan omjer. Latencija od 14 ms je jedan krug mreže (oko 15 ms), dakle "nema mjerljivog vremena brokera"; repovi (p99 oko 100 do 200 ms) su kod oba brokera dominirani dijeljenim domaćinima. Razlike ispod oko 20 % ne tvrdimo.

Što nije išlo u našu korist i ostalo je u tablicama: jedan TCP tok kroz urMQTT nosio je 2 do 8 puta manje nego kroz Mosquitto, s promjenama od nule do 7,7 tisuća poruka u sekundi među pokretanjima, a 20 ms watchdog rukovatelja prekidao je žive veze kad je hipervizor zaustavio vCPU (u produkcijskoj postavci action = "drop", 6 do 8 veza po pokretanju pri QoS 0 preplavljivanju). Obje stvari su opisane u sljedećem odjeljku jer su imale uzroke u našem kodu.

Zašto je jedan tok bio spor: uzroci, a ne izgovori

Najlakše bi bilo reći "dijeljeni VPS". Nismo, nego smo uz isti VPS i istu metodu tražili uzroke. Pronađeno je pet uzroka, četiri u putu podataka i jedan u watchdogu (ADR-221 do ADR-224):

Zaustavljanja su stvarna: na ovom VPS-u jezgre 0 do 2 imale su medijan 36 do 80 zakašnjelih otkucaja po 5 sekundi, a najgore zaustavljanje u prozoru bilo je medijan oko 70 ms i do 0,9 s (jezgra 3, baza i dnevnik: do 1,55 s), dok domaćin ne javlja ukradeno vrijeme (host steal 0 us). Zato je watchdog trebao drugi sat, ne veći proračun.

Watchdog: 148 prekinutih veza u 30 opterećenih pokretanja prije, 0 u 24 pokretanja poslije; na lokalnoj napravi koja odgađa i gubi okvire, pri gubitku od 0,1 % jedan tok od 64 B s 14,3k poruka/s (jezgra X11) sada ima 41,0k, a pri 0,5 % s 5,0k na 17,7k.

Što ovo ne kaže. urMQTT i dalje nije brži od Mosquitta na jednom toku: pri 64 B objavljuje oko 80 % njegove brzine, a isporučuje oko 40 %, jer odbacuje QoS 0 kad je tok pretplatnika sporiji od izdavačeva (Mosquitto bez granice stavlja u red). Pri 1 KiB u 16-parnom preplavljivanju Mosquitto je ispred za oko 15 %, što je unutar šuma. Generator je ponovno bio dijeljena VM s 58 do 77 % ukradenog vremena. Druga runda (zaključavanje heapa izvan puta podataka, SACK na strani slanja i drugo) je na neintegriranoj grani perf-single-flow-wip; njezine brojke još nisu tvrdnje i ovdje ih ne navodimo.

Obećanje koje nismo dali, ali smo ga ispunili: konfiguracija je podatak

Do sada je svaka konfiguracija bila nova gradnja: ključevi i ograničenja bili su ugrađeni u sliku. C1 to okreće (ADR-215 do ADR-219): jezgra se gradi jednom, a konfiguracija je podatak.

• Blob urmqtt-cfg (C1a): verzionirani, kanonski zapis (polja po rastućim oznakama, SHA-256 otisak, neobavezni odvojeni Ed25519 potpis), 70 polja s zadanim vrijednostima i granicama, dekoder koji odbija sve neispravno.
• Jezgra ga čita kao Limine modul (C1b), prije bilo čega drugog, na aarch64 i x86_64. Postoji jedna izdana jezgra za svaki ENV osim dev (aarch64 ELF-ovi za release, prod i bench imaju isti SHA-256; provjereno samo na aarch64). Izdana jezgra odbija razvojnu konfiguraciju, a bez konfiguracije piše "refusing to serve" i ne poslužuje ništa.
• Instalirani disk nosi konfiguraciju i ažuriranje je zadržava (C1c).
• urmqtt-config i predložak ISO (C1d): pack, show, verify, a pack --iso zamjenjuje oba primjerka mjesta za konfiguraciju i 24 sažetka modula u gotovom ISO-u. Rezultat je bajt za bajt isti kao ISO koji mkiso.sh --config gradi. Predložak izdanja v0.2.0 ima 63 111 168 bajtova.
• Izjava o povjerenju (ADR-219): konfigurirana slika pri podizanju ispisuje otisak konfiguracije (config: fingerprint ...), a potpis je neobavezan i isključen po zadanom. Izmijenjeni ISO nema službeni sažetak; otisak je način da se vidi što je u njemu.

Graditelj na aldo.tech

Isto što radi urmqtt-config pack --iso, radi i web stranica, istim kodom: biblioteka alata prevedena u WebAssembly (1,06 MB, bez uvoza i bez unsafe bloka). Stranica je na aldo.tech/proizvodi/urmqtt-builder/ i u svih 15 jezika stranice (na primjer en).

• Ništa ne napušta preglednik. Certifikati, privatni ključevi i gotov ISO ostaju na računalu; stranica skida samo datoteke izdanja s ovog sjedišta, nema praćenja ni skripti trećih strana. U testu uživo nijedan zahtjev nije nosio ključni materijal.
• Zrcalo izdanja (ADR-227): sat po sat (systemd timer, nisko prioritetan) kopira izdanja s GitHuba, svako provjerava prije objave, a stranica u pregledniku provjerava potpis SHA256SUMS ključem ugrađenim u stranicu, pa tek onda upisuje konfiguraciju u predložak. Neuspjela provjera blokira preuzimanje.
• Jednostavno prema zadanom, napredno po potrebi (ADR-232): prvi zaslon su tri koraka (gdje radi, vaši certifikati, ime slike). Jedno polje za povlačenje datoteka razvrstava certifikat, ključ i CA po sadržaju. Napredni prikaz otvara svako od 70 polja, pretraživanje, uvoz i izvoz TOML-a; oba prikaza uređuju isto stanje. Predložak (63 MB) skida se dok korisnik ispunjava formu. U probi uživo, s probnim zrcalom i probnim ključem, izgradnja ISO-a u pregledniku trajala je 5 do 18 s.

Emulator, neobavezno. Pored "Preuzmi ISO" stoji "Isprobaj u emulatoru": QEMU preveden u WebAssembly pokreće upravo izgrađenu sliku u kartici preglednika. Ništa od njega se ne skida prije klika (oko 3 MB prvi put). Emulator je BIOS-only, bez mreže (da promet korisnika ne bi prošao kroz neki posrednik i narušio "ništa ne napušta preglednik"), traži oko 1,5 GB memorije i računalni preglednik (testiran Chrome; Firefox i Safari nisu). U njemu urMQTT stiže do URMQTT READY za oko 8 s (s preskočenim odbrojavanjem) i ispisuje isti otisak konfiguracije kao stranica, što je dokaz da je podignuta upravo ta konfiguracija. Podizanje je oko 2 puta sporije od izvornog QEMU-a na istom Macu (0,82 s prema 1,9 s), a kriptografija oko 58 puta sporija jer su sklopovske instrukcije emulirane. Zato iz emulatora ne izvlačimo nikakve tvrdnje o brzini, a stranica to kaže prije pokretanja. Pri izgradnji je trebalo zakrpati četiri bajta u .wasm-u zbog greške u prijevodu instrukcije POPCNT u izvornom emulatoru (još je nismo prijavili); sam emulator je pod GPL-om, uz ponudu izvornog koda.

Običan MQTT, samo za mreže kojima vjerujete

Običan MQTT (TCP 1883, bez TLS-a) vrlo je čest u IoT-u: zadano je u Mosquittu, u većini firmwarea za Arduino i ESP, u Tasmoti, Zigbee2MQTT-u i Home Assistantu, a koristi se i unutar segmentiranih industrijskih mreža, iza VPN-a i na privatnim LAN-ovima, pa i na uređajima bez sata (certifikati traže datum), bez dovoljno flasha ili procesora za TLS. Preko nepouzdane mreže nije prihvatljiv: tko je na putu, čita i mijenja promet. Zato je P1 (ADR-229 do ADR-231) izričit, ograničen izbor, isključen po zadanom, a TLS port ostaje; TLS se ovim ne isključuje, običan port dolazi uz njega.

• Popis dopuštenih mreža je obavezan (allow_from, CIDR-ovi) i provjerava se pri SYN-u: izvan popisa nema SYN-ACK-a ni stanja. Cijeli internet (0.0.0.0/0) traži zasebnu izričitu opciju.
• Tri načina prijave: lozinka (zadano kad je uključeno; PBKDF2-HMAC-SHA-256, sol, 10 000 iteracija, usporedba u stalnom vremenu, zaključavanje po adresi), anonimno (jedan konfiguriran identitet s vlastitim ACL-om) i po adresi (ip). Graditelj lozinku raspršuje u pregledniku i u memoriji drži samo sažetak.
• Manje prava nego mTLS: običan klijent nikad nema servisna, operatorska ni upravljačka prava, nema $SYS ni konzole, ima vlastite sesije ($plain/<identitet>/<id klijenta>, samo čiste), vlastita ograničenja i registar dopuštenih ga i dalje obvezuje.
• Što se gubi, piše u SECURITY.md: povjerljivost, cjelovitost, autentičnost brokera i ponavljanje snimljene prijave. To se konfiguracijom ne može popraviti; tako je kad nema TLS-a.

Izmjereno na laptopu (Apple silicon, HVF, QEMU korisnička mreža), 16 parova, 64 B, tri pokretanja od 10 s: pri 8 000 poruka u sekundi TLS i običan put isporučuju sve poruke s istom latencijom (p50 0,17 ms prema 0,13 do 0,18 ms), nove veze po sekundi: TLS oko 2 600 do 2 750, anonimni običan oko 4 900 do 7 800, a prijava lozinkom je skupi dio: jedan PBKDF2 stoji oko 2,5 ms, pa se broj novih prijava ograničuje na oko 200 po jezgri podataka u sekundi (izmjereno 308 do 342 na dvije jezgre). Preplavljivanje na tom stroju nije stabilan instrument (20k do 440k isporučenih u sekundi među pokretanjima) i iz njega ne izvlačimo zaključak. Usporedba običnog puta s Mosquittom na VPS-u još nije napravljena. Testovi: smoke skupina plaintext 7 od 7 na aarch64 HVF-u i na x86_64 TCG-u, novi fuzz cilj plain_input (2,3 milijuna pokretanja bez nalaza).

Greške koje je pronašao rad uživo

Dvije stvari nisu ulovili testovi, nego prvo uključenje na pravom sjedištu:

• Stranica je datoteke izdanja tražila jedan direktorij previsoko, pa je svaka provjera potpisa odgovorila 404 (ispravak 13af301). Test je koristio probno zrcalo na drugoj putanji.
• Tipkovnica emulatora nikad nije stigla do gosta: uzrok nije bio loš prijevod tipki, nego to što dijalog uopće nije slušao tipke (ispravak u ADR-232, uz unos za podizanje bez tipki).

Lekcije

• Tražite uzrok, ne okrivljavajte okolinu. Većina slabosti jednog toka i sve prekinute veze bile su naše; hipervizor je stvaran, ali ga je trebalo mjeriti, ne pretpostavljati.
• Usporedba s drugim proizvodom mora uključiti i gubitke. Tablica u kojoj su samo naše pobjede ne bi bila usporedba.
• Mjerni instrument ima granice. Dijeljeni generator s 60 do 70 % ukradenog vremena mijenja što brojke znače; zato pišemo "donja granica" i ne tvrdimo razlike ispod 20 %.
• Izolacija nije dokaz. SQLite u EL0 smanjuje što greška u njemu može, ne ono što može lagati.
• Stvarna instalacija nalazi ono što testovi ne traže: putanju koja je krivo složena i tipke koje nitko ne sluša.

Što još nije dokazano

• Potpisni ključ izdanja za sada je probni ključ; v0.2.0 i v0.2.1 su pre-release, a slike uz njih razvojne uz probne certifikate (osim predloška, koji je bez konfiguracije).
• 13 prijevoda stranice graditelja (i ovog teksta) napisao je AI i provjerili su ih testovi i uzorci, ne izvorni govornici.
• Usporedba s Mosquittom je jedna sjednica, jedan put i jedan dijeljeni generator, na dijeljenom VPS-u; razlike ispod 20 % nisu tvrdnje.
• Običan put nije mjeren na VPS-u ni protiv Mosquitta.
• Lighthouse na novom jednostavnom prikazu nije potvrđen (stari prikaz: pristupačnost 95 ili više).
• Bare metal, x86_64 cijena radnika na KVM-u, Firefox i Safari za emulator: nije mjereno.

Što slijedi

• D1: javni demo broker. Emulator iz preglednika ne možemo učiniti javnim: živi u kartici jednog posjetitelja, 20 do 100 puta je sporiji od KVM-a, nema dolazne mreže i nestaje sa zatvaranjem kartice; preusmjeravanje interneta u tuđi preglednik bilo bi i zlouporaba. Moguć je pravi demo broker: urMQTT na VPS-u iza imena na aldo.tech, s objavljenim probnim CA-om, strogim ACL-om i malim ograničenjima. To je zasad samo ideja, ne gradnja, i treba izričit pristanak za javno izlaganje.
• Druga runda za jedan tok (grana perf-single-flow-wip): tek kad je izmjerena na VPS-u i spojena.
• Običan put protiv Mosquitta na VPS-u, prijava i opoziv računa za običan MQTT preko potpisanog upravljačkog kanala.
• Poslije izdanja: bare metal (X12 do X16), IOMMU i Secure Boot, šifriranje diska.

Kod je na github.com/zeljan-alduk/urMQTT, a docs/PROGRESS.md i dalje je jedini izvor istine o tome što stvarno radi, docs/PERFORMANCE.md o tome što je izmjereno. Pred-alfa, kao i prije; prijave grešaka i sigurnosne prijave po uputama u SECURITY.md dobrodošli su.

Jedna napomena unaprijed: projekt je i dalje pred-alfa. Brojke u tekstu mjere kod i testove, ne zrelost u produkciji, a prva objava je namjerno ograničena na VPS-ove s KVM-om. Bare metal ostaje za kasnije.

Kako je to izgledalo u vremenu

Prvi commit nastao je 28. listopada 2026. u 23:48 (M0). Do 31. listopada u 23:00 u repozitoriju je 119 commitova, raspoređenih kao 3, 39, 38 i 39 po kalendarskim danima. Odmah recimo i kako je to moguće: projekt se gradi uz Claude Code, a commitovi nose Co-Authored-By: Claude trailere. Četiri kalendarska dana povijesti ne znače da je jedna osoba za četiri dana napisala 90 000 redaka; znače da se plan, implementacija, testovi i ADR-ovi pišu u kratkim, zatvorenim petljama, a svaki korak završava istim ritualom provjere kao i prije. Brojke ispod govore o količini koda i testova, ne o tome koliko je sve to provedeno u stvarnom radu.

Graf pokazuje tri krivulje koje rastu skoro zajedno, što i je namjera: testovi i zapisane odluke prate kod, a ne zaostaju za njim. Nagib je najstrmiji 29. listopada, kad nastaje cijeli put od jezgre do brokera. Dalje se redovi dodaju sporije, ali testovi rastu brže od koda (27 testova na 1,6 tisuća redaka na početku, 739 na 89,8 tisuća danas).

Redovi su svi .rs fajlovi izvan vendor/ i fuzz/, testovi su #[test] funkcije. Što je koji dio dodao, po datumu iz git povijesti:

Obećanje 1: jedan ISO za više platformi

Što smo planirali. Jedna datoteka koja se podiže na aarch64 UEFI-ju, x86_64 UEFI-ju i x86_64 BIOS-u. Što smo izgradili. Port na x86_64 (X0 do X10) i univerzalni ISO s Limine bootloaderom, jedan hibridni ISO s kojeg se podižu sve te kombinacije; smoke testovi ga podižu na četiri virtualna stroja. Izbornik ima tri unosa: urMQTT (živi način rada, radi iz RAM-a, ništa ne piše na disk), instalacija na disk stroja na kojem je pokrenut (instalacija piše GPT i podatke, pa gasi stroj) i Dijagnostika (detekcija hardvera i mjerenja).

Prva stvarna meta bio je VPS, a ne fizičko računalo: odluka je da prvo izdanje podržava samo VPS (KVM), a bare metal dolazi nakon njega. Testirali smo na Contabo VPS-u s AMD EPYC procesorom (obitelj 23, Zen 1), 4 vCPU-a i 8 GiB RAM-a, s virtio-net mrežom i virtio-scsi diskom. Prvi pokušaj nas je iznenadio: ISO priključen kao virtualni CD podizao je zadani unos, produkcijska slika odbila je poslužiti s medija samo za čitanje i resetirala se, pa smo dobili beskonačnu petlju izbornik, jezgra, reset bez ičega čitljivog. Danas fatalna greška u produkcijskoj slici ostavlja poruku na konzoli 60 sekundi prije resetiranja, a s optičkog medija ispisuje da je podignuto s medija samo za čitanje i staje. Živi način rada u RAM-u (O3) kasnije je taj problem zaobišao za uobičajeni slučaj.

Dijagnostički unos nastao je iz tog iskustva: stroj koji ne vidimo moramo moći pitati što ima. Ispisuje CPU, RAM, mrežu, diskove i PCI uređaje, mjeri propusnost memorije, disk i kriptografiju, a ista mjerenja ispisuje kao JSON na serijski port. Zapisivanje na disk dopušteno je samo u neraspoređenom prostoru i tek nakon što se utipka WIPE; na snimci ispod to je preskočeno.

Što je otvoreno. Pravi hardver. Poslije prvog izdanja slijedi bare metal (USB podizanje, NVMe i AHCI, mrežna kartica stvarnog računala), zajedno s IOMMU-om i Secure Bootom, jer bez IOMMU-a zlonamjerni ili neispravni uređaj može pisati po cijeloj memoriji. U ovoj verziji o tome ne tvrdimo ništa.

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

Prvo mjerenje dijagnostike na VPS-u dalo je nezgodnu brojku: mTLS rukovanje, samo kriptografija na strani poslužitelja, trajalo je 1,2 ms. Na aarch64 smo već koristili hardverske AES i SHA instrukcije, ali x86_64 nije imao ništa slično za javni ključ: RustCrypto je prenosiv i constant-time, pa i spor. Tri promjene su to spustile.

• Za P-256 smo preuzeli nistz256 asembler iz OpenSSL-a i ring-a (ADR-130), uz tablice s fiksnom bazom za potpisivanje i provjeru potpisa CA (ADR-110, ADR-111).
• X25519 je prepisan na četiri 64-bitna uda s MULX/ADX instrukcijama (ADR-131).
• Nakon toga smo profilirali i ostatak (ADR-132, ADR-200).

Brojke se razlikuju po pokretanju oko 10%, pa smo zapisali raspon umjesto jedne vrijednosti. Ukupno je to otprilike pet puta manje CPU vremena za rukovanje.

Što smo naučili o memcpy-u. Kad je kriptografija pala, profil je pokazao nešto što nismo očekivali: funkcije mem* (memcpy, memmove, memset) trošile su 7% rukovanja, 13 do 39% puta TLS zapisa (39% za 64 B, 13% za 4 KiB) i 17 do 34% razdjeljivanja PUBLISH-a. Zamijenili smo ih SSE2 asemblerom za x86_64 (ADR-200), uz diferencijalne testove prema referentnoj implementaciji za sve veličine, poravnanja i preklapanja. Po pozivu je to 55 do 75 ciklusa prema 7 do 12 za 1 do 64 bajta.

Čitanje grafa: što je zapis manji, to veći dio vremena odlazi na kopiranje, pa je i dobitak veći. Za male poruke, koje su većina MQTT prometa, to je ono što znači.

Što ovo ne znači. Na nativnom x86_64 smo samo kao referencu za asembler mjerili OpenSSL 3.5.5 (ADR-130), a ne kao usporedbu proizvoda. Usporedbu Linux plus Mosquitto na istom VPS-u (zadatak X11) još nismo napravili. Zato ne tvrdimo da je urMQTT brži od Linuxa: nije izmjereno. Brojke iznad uspoređuju urMQTT sa samim sobom.

Preopterećenje je bio drugi rezultat. Na VPS-u, s jednog Maca (RTT 35 ms), 128 klijenata dalo je 618 rukovanja u sekundi, 256 klijenata 393, a 512 klijenata 67, uz tisuće odbijenih veza. Nije to bio plato nego urušavanje. Uzroke smo pronašli u kodu (dva su potvrđena u QEMU-u/HVF-u, na VPS-u se nisu mogli ponoviti), više njih odjednom: odbijena veza vraćala je klijenta preko sljedećeg segmenta koji nosi valjani SYN kolačić, odbijanje je RST-om govorilo klijentu da odmah proba ponovno, a prijem je bio O(red). Ispravak (ADR-080 do ADR-082) ispušta SYN koji ne bi bio prihvaćen, pamti odbijene tokove, drži prijem u O(1) i broji rukovanja po jezgri. Moguće je (hipoteza, nije provjereno) da je dio uzroka bio i na klijentu: alat za opterećenje je zatvarao prvi, pa je jedan Mac s 16 384 efemernih portova i TIME_WAIT-om od 30 sekundi ograničen na oko 550 veza u sekundi. Zato pravi strop poslužitelja još nismo izmjerili.

Obećanje 2: sirovi disk, ali pažljiv

Što smo planirali. Zadržati vlastiti raspored bez datotečnog sustava i dodati sve ono što datotečni sustav inače daje: poravnanje, rast, discard, sigurnosne kopije i provjere. Zašto ne datotečni sustav. O tome smo raspravljali i odluka je potvrđena: urMQTT piše jednu bazu, jedan telemetrijski dnevnik i vlastite metapodatke, ne treba imenike, dozvole, ni imena datoteka, a svaki dodatni sloj bio bi još kod u povjerljivom dijelu i još jedan način da zapis tiho nestane. Disk je GPT s ESP particijom i jednom urMQTT particijom podataka, na kojoj je vlastiti raspored.

Što smo izgradili (S2 do S6).

• Raspored v2 (S2). Topologija diska, poravnanje na 1 MiB ili optimalnu veličinu I/O-a, cijeli fizički blokovi, A/B par superblokova s generacijom (ADR-140). Raspored v1 kernel odbija uz jasnu poruku, a migrira ga izvanmrežni alat urmqtt-disk migrate (ADR-141): zadano je probni prolaz, kopira se pa tek onda prebacuje, uz povrat i ubrizgavanje greške na svakom zapisu.
• Rast (S3). Pri podizanju disk može narasti (nikad se ne smanjuje), a na virtio-blk i za vrijeme rada, preko prekida promjene konfiguracije (ADR-142, ADR-143).
• Discard i write-zeroes (S4). Tanko dodijeljeni diskovi vraćaju prostor domaćinu. U testu je qcow2 datoteka na domaćinu pala sa 62 na 16 MiB nakon što su istekli telemetrijski segmenti, a oporavak nikad ne vjeruje sadržaju koji je odbačen.
• Sigurnosna kopija baze na disku (S5). A/B kopija pomoću SQLite online backup API-ja u koracima po 16 stranica: najduži korak 4,6 ms naspram 445 ms kad se kopira u jednom pozivu. Komitovi tijekom kopije imali su maksimum 2,4 ms prema 2,2 ms bez nje. Ako quick_check pri podizanju ne uspije, baza se vraća iz kopije.
• Čišćenje i ograničeno podizanje (S6). Scrubber čita disk uz ograničen I/O proračun i prijavljuje oštećene zapise, a podizanje čita samo najnoviji segment svake particije, tako da vrijeme podizanja ne raste s veličinom telemetrijske regije. Time smo zatvorili problem koji smo izračunali unaprijed: na velikom disku bi potpuni oporavak trajao od minuta do desetaka minuta.

Cijela grupa smoke testova za pohranu prolazi na obje arhitekture: 79 uspješnih, 0 neuspjelih, na aarch64 pod HVF-om i na x86_64 pod TCG-om. Mjerili smo i da S4 nije usporio bazu: 53,3 tisuće umetanja u sekundi u paketima prije i poslije, bez izmjerive razlike.

Što je iznenadilo. Koliko od "jednostavnog" rasporeda otpada na rubne slučajeve: virtio-scsi i virtio-blk prijavljuju topologiju na različite načine, a nepotpuni zapis u sredini migracije mora uvijek ostaviti bar jednu valjanu verziju. Zato je svaki zapis na putu migracije i rasta prošao ubrizgavanje greške.

Što je otvoreno. SQLite stranice nemaju kontrolni zbroj, pa promijenjeni bit unutar vrijednosti u retku baza neće otkriti; telemetrijski zapisi i sadržaj kopija imaju CRC i otkrivaju se. Šifriranje diska (S7) nije gotovo.

Obećanje 3: dokazivo sigurno, koliko god to uspijemo

Ojačanje (H4). Alokator briše oslobođenu memoriju i provjerava je pri ponovnoj uporabi, otkriva dvostruko oslobađanje, veže pokazivače slobodne liste XOR-om i nulira ključeve pri oslobađanju (ADR-170). Zaštita stoga (-Zstack-protector=strong, 1315 funkcija, a SQLite s -fstack-protector-strong, ADR-171). Izvješća o greškama u produkciji ne sadrže registre ni adrese (ADR-172). KASLR na obje arhitekture: kernel je PIE i Limine ga pomiče za oko 19 bitova, a nasumično se postavljaju heap, stogovi i MMIO prozor (ADR-173). Na aarch64 MTE označava heap (ADR-174), ali samo pod TCG-om: HVF i x86 ga nemaju. kCFI smo procijenili i nismo ga prihvatili jer prevoditelj na prikvačenom nightlyju pada s unutarnjom greškom; IOMMU je odgođen s bare metalom (ADR-175, ADR-176).

Cijena je izmjerena, ne pretpostavljena. Na putu rukovanja (dp-bench, aarch64 HVF, puna TLS 1.3 + mTLS + CONNECT rukovanja):

Sveukupno je dakle cijena na putu rukovanja otprilike 5% za dijelove mjerene čisto, a s PIE-jem i oznakama izlazi oko 7% na jednoj i oko 11% na četiri jezgre, no to je mjerenje šumovito. Smatramo je prihvatljivom, ali nismo je ponovili na x86_64 VPS-u.

Vrijedi usporediti s brojkom iz prvog teksta (862 rukovanja u sekundi na jednoj jezgri). Isti alat danas, s pogonom hardverskog kriptiranja na aarch64 (X0b) i nizom ubrzanja koja su stigla otada, daje 1941 prije ojačanja. Nismo izolirali doprinos svake promjene, pa o uzroku ne tvrdimo ništa.

Kako je provjereno, i što nije. H5 je dodao Miri na podskup host crateova, Kani dokaze, sanitizere, model-fuzzer za ACL i izvješća o pokrivenosti. Kani je dokazao record_len u TLS-u, parse u TCP-u i dvije aritmetike kotača tajmera. Nije dokazano (isteklo vrijeme): oba MQTT dekodera, oba parsiranja konfiguracije i ponašanje kotača tajmera; CI posao za Kani zato još ne blokira. Miri ne može izvoditi asembler. Lanac nabave (H9): CycloneDX SBOM s 215 komponenti, cargo-vet prolazi s 39 potpuno revidiranih i 140 izuzetaka, a cargo-deny je konfiguriran da savjete o ranjivostima tretira kao pad CI-ja (ti CI poslovi do sada su provjereni samo lokalno, ne na GitHubu, a negativni test nije pokrenut), uz VULNERABILITY-HANDLING.md. Iskreno stanje: od 67 kernel-linkanih verzija trećih crateova, 53 su izuzeci, a ne revizije. Vet dokazuje da se skup ovisnosti ne može promijeniti bez vidljive razlike, ne da je TCB pregledan. Vlastitu reviziju ni jednog cratea nismo napisali.

SNTP (T1) je u tom smislu mala priča o sigurnosti: opcionalan je, samo prema privatnim IPv4 poslužiteljima, s maksimalnim skokom i uvjetom da se izvori slažu (medijan, većina unutar jedne sekunde). Sat koji bilo tko na putu može pomaknuti nije sat kojem smijemo vjerovati kod valjanosti certifikata.

Na Macu: aarch64 izvorno i x86_64 emulacijom

Razvijamo na Macu, a taj ima dva načina za pokretanje istog koda i oni su vrlo različiti.

Pravilo je jednostavno: brojke pod TCG-om su emulacija i ne citiramo ih kao performanse. x86 performanse mjerimo samo na pravom VPS-u. Zato kriptografske brojke iznad dolaze s Contabo VPS-a, a ne s Maca.

Lekcije

• Mjerite na stvarnom stroju prije optimiranja. Prvi pristup bio je optimizirati ono što smo mislili da je sporo; tek je dijagnostika na VPS-u pokazala 1,2 ms i gdje točno odlazi vrijeme.
• Preopterećenje je zasebna značajka. Sustav koji je brz pod opterećenjem može se urušiti iznad njega; odbijanje mora biti jeftinije od prihvaćanja.
• Profil iznenađuje. Najveći pojedinačni dobitak za male poruke nije bio u kriptografiji nego u kopiranju memorije.
• Disk bez datotečnog sustava traži više posla, ne manje. Ono što sustav datoteka inače daje (poravnanje, rast, discard, kopije, provjere) moramo napisati i provjeriti sami, svaki korak s ubrizgavanjem grešaka.
• Iskrenost u brojkama. Memorijska mjerenja na dijeljenom VPS-u variraju do 10 puta među pokretanjima i ne govore ništa o kodu, pa ih ne navodimo. Kripto brojke su stabilne do oko 10%.
• Brzina razvoja nije zrelost. Testovi i ADR-ovi rastu uz kod, ali četiri dana nisu pravi pogon.

Što slijedi

• H6: SQLite izoliran na razini EL0, tako da greška u bazi ne otvara jezgru.
• H7: ostatak sigurnosti vremena (NTS i obrada skokova); SNTP je tek prvi korak.
• X11: usporedba s Linuxom i Mosquittom na istom VPS-u, tek tada ima smisla govoriti o relativnoj brzini.
• Izdanje: prva javna objava za VPS (KVM), uz potpisane artefakte i upute.
• Poslije izdanja: bare metal (X12 do X16), IOMMU i Secure Boot, te šifriranje diska.

Kod je na github.com/zeljan-alduk/urMQTT, a docs/PROGRESS.md i dalje je jedini izvor istine o tome što stvarno radi. Pred-alfa, kao i prije; prijave grešaka i sigurnosne prijave po uputama u SECURITY.md dobrodošli su.

Tako je nastao urMQTT: unikernel koji jest MQTT broker. Jezgra, TCP/IP, TLS 1.3, MQTT i ugrađena baza podataka u jednom Rust binarnom programu koji se pokreće s jednog ISO-a. Nema procesa, nema sustavskih poziva, nema ljuske. Prva platforma na kojoj se gradi i testira je aarch64, a isti kod ide prema x86_64, po UEFI-ju i klasičnom BIOS-u, i prema pravom hardveru: cilj je jedan ISO koji se podiže na svemu tome. Projekt je otvorenog koda pod licencom MIT ili Apache 2.0, i u ovom tekstu želimo zapisati gdje smo stigli, kako je iznutra složen i što smo usput naučili.

Što točno znači "unikernel"

Uobičajeni broker je program koji radi na operacijskom sustavu. urMQTT nema operacijski sustav ispod sebe: sam se podiže kroz UEFI firmware i Limine bootloader, postavlja vlastite tablice stranica, programira kontroler prekida i tajmer, pronalazi virtio uređaje preko PCIe-a, dobiva adresu DHCP-om i sluša na jednom portu. Sve što bi inače radila jezgra, upravljački programi, mrežni stog i aplikacija, ovdje je jedan ELF koji radi na razini EL1.

Usporedba s tipičnom instalacijom govori sama za sebe:

Prioriteti su, tim redom: sigurnost, skalabilnost, višejezgrene performanse, mali otisak i nepromjenjiva instalacija. Kad god su dva cilja u sukobu, pobjeđuje onaj koji je viši na toj listi.

Gdje smo sada

Projekt je u pred-alfa fazi, ali je zatvoreno sedamnaest razvojnih prekretnica, od M0 do M17. Danas urMQTT poslužuje MQTT 3.1.1 preko TLS-a 1.3 s obaveznim klijentskim certifikatima, a stanje čuva u SQLite-u na sirovom disku. Ukratko, što već radi:

• Jezgra: vlastiti vektori iznimaka s dekodiranim izvještajima, vlastite tablice stranica s provedenim W^X-om, zaštitne stranice, PAC i BTI gdje ih procesor ima, GICv3 i GICv2, generički tajmer, SMP do 64 jezgre.
• Otkrivanje hardvera iz DTB-a ili ACPI-ja u jedan opis platforme, s identičnim rezultatom iz oba izvora.
• Upravljački programi: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi i virtio-rng, te CSPRNG zasijan hardverskom entropijom.
• Mreža: vlastiti DHCPv4, ARP, ICMP i strogi IPv4, pa vlastiti TCP samo za poslužiteljsku stranu: SYN kolačići, hijerarhijski kotač tajmera, NewReno, spajanje ACK-ova, bez TIME_WAIT stanja.
• TLS: samo TLS 1.3, obavezni mTLS, identitet uređaja iz CN-a ili SAN URI-ja; rukovanje radi rustls, a nakon njega vlastiti sloj zapisa s AES-128-GCM-om i ChaCha20-Poly1305. Nastavak sjednice PSK ulaznicama, lista opoziva, kontrola prijema već kod rukovanja.
• MQTT: kodek bez kopiranja, fuzziran i testiran s pravim mosquitto klijentima; QoS 0 i 1, džokeri, zadržane poruke, oporuka (LWT), trajne sjednice, ACL s ograničenjem na devices/{id}/#, ograničenja brzine po uređaju.
• Pohrana: SQLite unutar jezgre preko VFS-a nad sirovim diskom, u WAL načinu, s provjerom integriteta pri podizanju; registar uređaja, opozivi, zadržane poruke, trajne sjednice s redovima poruka za uređaje koji su offline; po jezgri zaseban telemetrijski dnevnik s CRC-om po zapisu i oporavkom nakon pada.
• Pogon i nadzor: nadzorni tajmer za obrađivače, zdravstvena provjera, ograničeno logiranje, syslog i statsd preko UDP-a, prijem koji preživljava oluje ponovnih spajanja.
• Isporuka: bitovno identične ponovne izgradnje provjerene u CI-ju, ISO i sirova GPT slika diska, minisign potpisi, upute za KVM, Proxmox i Hetzner.

Svaki je korak označen prekretnicom koja ga je donijela, a datoteka docs/PROGRESS.md u repozitoriju jedini je izvor istine o tome što stvarno radi.

Arhitektura u tri slike

Cijeli dizajn opisan je u docs/ARCHITECTURE.md, a razlozi za svaku važniju odluku zapisani su kao ADR-ovi u docs/DECISIONS.md. Ovdje je pregled.

Slojevi

Od vrha prema dnu: broker (sjednice, stablo tema, QoS, zadržane poruke, oporuke, ACL, ograničenja), MQTT kodek, TLS, TCP, mrežni sloj, pa upravljački programi. Pokraj tog glavnog puta stoji pohrana (SQLite i telemetrijski dnevnik), a ispod svega upravljanje memorijom, otkrivanje platforme i konfiguracija koja je u vrijeme izgradnje prevedena u konstante, zajedno s ugrađenim CA certifikatom, poslužiteljskim certifikatom i ključem. Hipervizor s virtio uređajima jedino je što je izvan slike.

Nit po jezgri, bez dijeljenog stanja

Svaka podatkovna jezgra vrti vlastitu petlju s vlastitim TCP stogom, TLS stanjima, dijelom brokera (sjednice i stablo tema), predmemorijom heapa i particijom telemetrije. Jezgre ne dijele nikakvo promjenjivo stanje, samo ograničene prstenove bez brava, po jedan za svaki uređeni par jezgri. Najviša jezgra pokreće SQLite i ništa drugo.

Mrežna kartica danas ima jedan par redova koji drži jezgra 0. Ona svaki MQTT tok prema Toeplitz hashu njegove četvorke usmjerava na jednu od radnih jezgri i šalje ono što radne jezgre vrate. Sjednica živi na svojoj domaćoj jezgri, određenoj hashom identifikatora klijenta, pa preuzimanje, oporuke i trajnost nikad ne prelaze jezgre. Veza koja sleti na drugu jezgru zadržava tamo svoj TCP i TLS, a običan MQTT prosljeđuje domaćoj jezgri uz kontrolu toka temeljenu na kreditima. Svaka usmjerena poruka razdjeljuje se i na ostale dijelove brokera, od kojih svaki drži repliku zadržanih poruka.

Tri pravila drže taj model na okupu. Obrada do kraja: primljeni paket obrađuje se u cijelosti na jednoj jezgri, od TCP-a preko dešifriranja TLS-a na mjestu, parsiranja MQTT-a i usmjeravanja do šifriranog odgovora, bez redova zadataka i bez kopiranja u aplikacijske međuspremnike. Prilagodljivo ispitivanje: pod opterećenjem se redovi za primanje aktivno ispituju, a u mirovanju se jezgra vraća na prekide i WFI; obrađivači prekida samo potvrde prekid i označe posao. Nadzorni tajmer: otkucaj od 10 ms po jezgri hvata obrađivače koji premaše svoj proračun.

Život jednog PUBLISH-a

Uređaj pošalje TLS zapis. Mrežna kartica ga preda petlji jezgre deskriptorom, bez kopiranja. Petlja provjeri TCP, dešifrira TLS na mjestu i parsira MQTT iz posuđenog međuspremnika, zatim u memoriji provjeri ACL, ograničenje brzine i put kroz stablo tema. Ako drugu jezgru zanima ta tema, dobije poruku za usmjeravanje s referencom na sadržaj i identifikatorom teme; baza dobije telemetrijski zapis ili ažuriranje zadržane poruke, u paketu. Odgovor PUBACK šifrira se izravno u odlazni međuspremnik i spoji s TCP ACK-om, pa uređaju odlazi jedan segment. Drugu jezgru poruka košta jedno šifriranje po pretplatniku u trenutku slanja.

Koliko košta jedna veza

Cilj je najviše 512 bajtova po neaktivnoj TLS vezi, s težnjom prema 256. Dok veza miruje, ništa se za nju ne drži u međuspremniku: primljeni podaci obrađuju se izravno iz mrežnog okvira, a međuspremnici za slanje, zapise i MQTT postoje samo dok je nešto nedovršeno ili nepotvrđeno. Jezgra to i sama mjeri: točni brojači heapa u traženim bajtovima i u blokovima koje zauzimaju, zapisani svakih deset sekundi kao heap iznad osnovne razine po otvorenoj vezi.

Izmjereno pod HVF-om s četiri virtualne jezgre, od toga tri radne, pri čemu svaki uređaj drži mTLS vezu i jednu pretplatu s QoS 1, uključujući zaokruživanje alokatora:

Bazen mrežnih okvira fiksnih je oko 2 MiB, što je otprilike 200 B po vezi pri deset tisuća veza i oko 2 B pri milijun. Više od toga nismo mogli izmjeriti: QEMU-ovo korisničko umrežavanje na macOS-u prestalo je prihvaćati veze na 10 197, otprilike na granici od 10 240 deskriptora QEMU procesa. Brojka pada kako se fiksni dijelovi raspodjeljuju na više veza, pa ne raste s njihovim brojem.

Sigurnosni model

Sigurnost je prvi prioritet i dobiva sve sukobe s ostalim ciljevima. Model ima nekoliko slojeva:

• Jedan port. TCP 8883, samo TLS 1.3, obavezni klijentski certifikati potpisani CA-om ugrađenim u sliku. Identifikator MQTT klijenta mora biti jednak identifikatoru uređaja iz certifikata.
• Nema ulaza. Nema ljuske, konzolnog unosa, SSH-a, administracijskog API-ja, dinamičkog koda, SQL-a dostupnog mrežom ni datotečnog sustava.
• Memorijska sigurnost. Rust, s forbid(unsafe_code) u protokolnim paketima; svaki unsafe blok ima komentar // SAFETY: koji provjerava lint, a na vanjski unos nema panike: clippy u paketima na podatkovnom putu zabranjuje unwrap, expect, indeksiranje i panic!.
• Ublažavanje iskorištavanja. W^X provodi se kodiranjem deskriptora i bitom SCTLR_EL1.WXN i revidira pri svakom podizanju. Tablice stranica nakon podizanja su samo za čitanje, bez zapisivog aliasa. Donja polovica adresnog prostora je isključena. Svaki stog ima zaštitne stranice, a iznimke rade na zasebnom stogu. PAC i BTI uključuju se kad ih procesor podržava, i to provjeravaju dimni testovi.
• Otpornost na zloporabu. SYN kolačići; prijem odbija nove veze, prije ikakve kriptografije, kad je heap nizak, kad baza zaostaje, kad je previše rukovanja u tijeku po jezgri ili po izvornoj adresi ili kad je brzina rukovanja previsoka. Ograničenja brzine po uređaju, ograničeni redovi, TCP prozor vezan uz protutlak brokera, ograničeno logiranje, nadzorni tajmer i zdravstvena provjera.
• Nepromjenjivost. Konfiguracija, CA i poslužiteljski ključ ugrađeni su u sliku. Promjena bilo čega znači novu sliku.

Model prijetnji zapisan je u docs/SECURITY.md.

Pohrana bez datotečnog sustava

Podaci žive na zasebnom disku, virtio-blk ili virtio-scsi, na kojem nema datotečnog sustava. Raspored je minimalan i vlastiti:

LBA 0      [ superblok: magija · verzija rasporeda · uuid · tablica regija · CRC-32C ]
LBA 8, 16  [ tablica veličina datoteka, utori A/B (najnoviji valjani pobjeđuje) ]
LBA 64     [ SQLite glavna baza ½ ][ SQLite WAL ⅛ ][ dnevnik 1 MiB ][ telemetrijski dnevnik: 8 particija … ]
zadnja 4 KiB [ prostor za samoprovjeru blok-uređaja pri podizanju ]

SQLite (vendorirani 3.54.1, s provjerom sažetka pri izgradnji) preveden je u jezgru clangom, bez standardne biblioteke, i koristi fiksni memsys5 heap. Njegov VFS preslikava tri fiksne datoteke na regije diska. Radi u WAL načinu s locking_mode=EXCLUSIVE, pa mu ne treba indeks u dijeljenoj memoriji, i sa synchronous=FULL; ako quick_check pri podizanju nađe grešku, sustav se sigurno zaustavlja. U bazi su registar uređaja, opozivi, zadržane poruke i trajne sjednice s redovima QoS 1 poruka za uređaje koji nisu spojeni.

Jezgra za bazu, ona s najvišim brojem, pokreće SQLite i ništa drugo. Podatkovna ravnina šalje joj promjene stanja preko SPSC prstena bez brava; ona ih skuplja u jednu transakciju svakih 5 ms ili svakih 512 operacija i potvrde vraća drugim prstenom. Prazan disk formatira se pri prvom podizanju; sve drugo se nikad ne formatira preko.

Telemetrija ide drugim putem. Svaki prihvaćeni PUBLISH na temama iz storage.telemetry_topics odlazi u particiju telemetrijskog dnevnika svoje jezgre: prsten segmenata s CRC-om po zapisu, posoljenim sekvencom segmenta, tako da se stari prolazi prstena nikad ne pojave ponovno. Jezgre predaju zapise bazi vlastitim prstenom, bez kopiranja, a ona ih ispisuje svakih 5 ms ili svakih 256 KiB. Pri podizanju oporavak zadržava svaki ispisani zapis, odsiječe nedovršeni rep i nastavlja u novom segmentu. Zadržavanje je po veličini, kroz prsten, i po starosti, kroz retention_days. Provjerili smo to s milijun zapisa i s kill -9 usred pisanja.

Brojke

Alat za opterećenje u tools/loadgen radi tri stvari: oluju TLS 1.3 rukovanja s mTLS-om i CONNECT-om, dugotrajne veze s PINGREQ-om koje svake sekunde objavljuju telemetriju, i oluje ponovnog spajanja. make bench na Apple M4 Pro pod HVF-om daje:

Brojka u gostu, gdje su klijent i poslužitelj unutar istog virtualnog stroja i svaka radna jezgra radi sama za sebe, pokazuje da podatkovna ravnina skalira linearno. Mrežna brojka ograničena je jednonitnim korisničkim umrežavanjem QEMU-a, ne gostom; i to je zapisano kao ADR-032.

Oluje ponovnog spajanja testiramo tako da se svi uređaji spoje odjednom, ponavljaju odbijene pokušaje s odgodom i onda svi padnu bez DISCONNECT-a. Parametar heap_limit_mb= u razvojnom načinu natjera prijem da heap smatra manjim nego što jest, pa se oluja veća od heapa može isprobati s malo socketa. U jednom takvom krugu od 3 000 uređaja spojilo se 1 368 u 36 sekundi, a 5 619 pokušaja bilo je uredno odbijeno, uz ograničenje od 8 MiB; memorija se nakon oluje vratila.

Kako radimo

Projekt vodi pisana specifikacija, PROMPT.md, s planom prekretnica, i svaka prekretnica završava istim ritualom: make check i make smoke zeleni, jedan commit s oznakom M<n>, zapis u docs/PROGRESS.md i ADR za svaku odluku koja nije očita. Pravila su kratka i ne pregovaramo o njima: nema panike na vanjski unos, unsafe samo u hardverskim i FFI paketima i uvijek s komentarom, nema alokacija na vrućem putu, komentar uz svaki redoslijed atomskih operacija, svako ograničenje dolazi iz konfiguracije, a namjerni privremeni dijelovi padaju glasno.

CI radi više nego što bismo ručno stigli: fmt, clippy za host i za aarch64-unknown-none, typos, actionlint i shellcheck; testove na Linuxu i macOS-u na arm64; izgradnju jezgre za razvojnu i produkcijsku konfiguraciju s veličinom ELF-a u sažetku; podizanje pod QEMU-om sa svim scenarijima dimnog testa i spremanje serijskih zapisa; cargo-deny za savjete, licence i izvore; minutu fuzzinga po svakoj od jedanaest meta, a noću deset minuta po meti s predmemoriranim korpusom. Uz to CodeQL, OpenSSF Scorecard, Dependabot i objava s SLSA porijeklom. Svaka tuđa akcija zakvačena je na puni commit SHA.

Reproducibilnost shvaćamo doslovno: make repro izgradi HEAD dvaput u svježim radnim stablima i usporedi ELF, ISO i sirovu sliku bajt po bajt. Objave su potpisane minisignom, a artefakti se mogu provjeriti s gh attestation verify. Produkcijska slika sadrži privatni ključ poslužitelja, pa je sam ISO tajna; slike uz objave na GitHubu razvojne su, s privremenim ključevima, i služe samo za isprobavanje.

Što smo naučili

Nekoliko lekcija koje su promijenile plan:

• Vlastiti TCP ipak se isplatio. Prototip je radio na smoltcp-u i dobro nam je poslužio do M13. Ali poslužitelj koji drži stotine tisuća veza ne treba klijentski TCP, treba SYN kolačiće, kotač tajmera i stanje od 96 bajtova. U M14 smo smoltcp zamijenili vlastitim stogom samo za poslužiteljsku stranu, s testovima simuliranog gubitka i fuzzingom segmenata.
• Mjerite memoriju iznutra. Procjene po vezi bile su beskorisne dok jezgra nije sama počela brojati heap u blokovima alokatora, a ne u traženim bajtovima. Tek tada smo vidjeli gdje 512 bajtova stvarno odlazi i spustili se na 494.
• Alat za testiranje je dio proizvoda. Najveće ograničenje nije bila jezgra, nego QEMU-ovo korisničko umrežavanje i broj efemernih portova na razvojnom računalu. Za sto tisuća i više veza treba vmnet-shared na macOS-u ili Linux s KVM-om, tap sučeljem i više klijentskih adresa.
• SQLite bez operacijskog sustava je moguć, ali samo uz stroge uvjete: fiksni heap, ekskluzivno zaključavanje bez dijeljene memorije, VFS koji ne zna za datoteke, i prijem koji baze ne pušta da zaostane.
• Oluje ponovnog spajanja su normalno stanje, ne iznimka. Kad padne mobilna mreža i vrati se, tisuće uređaja kucaju istodobno. Zato prijem odbija vezu prije ikakve kriptografije, a svaka odbijena veza košta gotovo ništa.

Što slijedi

Rad nakon M17 planiran je u tri smjera, a redoslijed među njima zapisan je u docs/PLAN.md. Ništa od ovoga još nije izgrađeno.

• Jedan ISO za više platformi. Ista datoteka urmqtt-<env>-<verzija>.iso i jedna sirova GPT slika koje se podižu na aarch64 UEFI-ju, x86_64 UEFI-ju i x86_64 BIOS-u, u virtualnim strojevima i na pravom hardveru, počevši od jednog Intel PC-a. I dalje uređaj sa svime unutra, reproducibilan i potpisan.
• Sirovi disk, bez datotečnog sustava. Specifikacija formata na razini bajta, host alat urmqtt-disk koji dijeli parsere s jezgrom, poravnanje regija na 1 MiB, rast diska s podacima, discard za tanko dodijeljene diskove, A/B snimke baze, provjera bitova i, po izboru, šifriranje AES-256-XTS s hardverskim AES-om.
• Dokazivo sigurno. Opoziv i lista dopuštenih uređaja za vrijeme rada preko potpisanog kontrolnog kanala, bez nove slike; diferencijalno i konformacijsko testiranje vlastitog TLS-a i TCP-a; KASLR, zaštita stoga, kCFI, MTE i ojačani alokator; SQLite izoliran na razini EL0; Secure Boot; SBOM i cargo-vet; i na kraju paket za vanjsku reviziju.

Platforme koje nude samo ne-virtio uređaje, poput AWS ENA-e ili Azure MANA-e, zasad nisu podržane. Raspberry Pi 4 i 5 kao KVM domaćin, Hetzner CAX i Oracle Ampere A1 dokumentirani su i podržani kodom, ali još nisu isprobani na pravoj usluzi.

Isprobajte

Repozitorij je na github.com/zeljan-alduk/urMQTT. Uz Rust s prikvačenim nightly lancem alata i QEMU, make certs, make run i jedan mosquitto klijent dovoljni su za prvi PUBLISH preko mTLS-a na vlastitom računalu. Upozorenje s početka vrijedi i na kraju: ovo je pred-alfa, i sve što radi piše u docs/PROGRESS.md. Prijave grešaka, pitanja o dizajnu i sigurnosne prijave po uputama u SECURITY.md su dobrodošli. O svakoj sljedećoj prekretnici javit ćemo se ovdje.

Na ovom blogu želimo zapisati ono što smo na tom putu naučili. Ne marketinške tekstove, nego konkretne bilješke: što je pošlo po zlu, kako smo to riješili i što bismo danas napravili drukčije.

O čemu ćemo pisati

• Naplata u javnom prijevozu. Beskontaktne kartice, SAM moduli, rad bez mreže i sve što terminal mora podnijeti u vozilu koje se trese dvanaest sati dnevno.
• Mobilne aplikacije na terenu. Android i Flutter na uređajima koji nisu obični telefoni: s čitačima kartica, pisačima i baterijama koje moraju izdržati cijelu smjenu.
• Backend i nadzor flote. Kako znati da uređaj u vozilu ima problem prije nego što ga prijavi vozač.
• Hardver. Od prototipa na stolu do pločice koja ide u serijsku proizvodnju, i sve pogreške između.
• Lokalni AI modeli. Gdje modeli na vlastitom hardveru imaju smisla, a gdje su oblak i API jednostavno bolji izbor.

Kako ćemo pisati

Kratko i konkretno, s kodom i brojkama gdje ih ima. Objavljivat ćemo kad imamo što reći, a ne po rasporedu. Tekstove pišemo na hrvatskom i prevodimo ih na sve jezike stranice, a novosti možete pratiti i preko RSS-a.

Ako vas zanima neka tema ili radite na sličnom problemu, javite nam se na info@aldo.tech.