Az urMQTT a VPS után: SQLite felhasználói módban, összevetés a Mosquittóval, konfiguráció mint adat és böngészős építő

A második írás, az urMQTT egy valódi VPS-en, a „Mi következik" listával zárult: H6 (SQLite a magon kívül), H7 (az idő biztonsága), X11 (összevetés a Mosquittóval ugyanazon a VPS-en) és az első kiadás. Ez az írás ugyanabban a sorrendben követi ezt a listát, majd hozzáad két dolgot, amely nem szerepelt rajta, mert menet közben bukkantak fel: a konfigurációt mint adatot, webes ISO-építővel, és az opcionális sima MQTT-t TLS nélkül. Mint korábban: mit terveztünk, mit építettünk, mi lepett meg bennünket, és mi maradt nyitva. Ebben az írásban van néhány eredmény, amely nem az urMQTT javára szól; benne hagytuk őket, mert az igazság részei.

Az előzetes megjegyzés ugyanaz marad: a projekt pre-alfa, az első kiadás csak KVM-et használó VPS-ekre szól, a számok pedig a kódot, a teszteket és bizonyos kísérleteket mérik, nem az éles üzemi érettséget.

Hogyan nézett ki ez az időben

Az előző írás (10.31., 23:00) óta máig (11.1., 20:41) 59 új commit került a repóba, összesen 178. Mind egyetlen naptári napon készült, ezért ugyanaz a figyelmeztetés érvényes, mint korábban: a projekt Claude Code segítségével épül (a commitok Co-Authored-By: Claude záróelemet viselnek), a terv, a kód, a tesztek és az ADR-ek rövid, zárt ciklusokban készülnek, az alábbi számok pedig a kód és az ellenőrzések mennyiségéről szólnak, nem arról, mennyi emberi munka van bennük.

A számokat ugyanazzal a módszerrel számoltuk, mint az előző írásban: minden .rs fájl a vendor/ és a fuzz/ kívül, a #[test] függvények, a ## ADR- címek a docs/DECISIONS.md fájlban.

Pillanat	Commit	Idő	Rust-sorok	Tesztek	ADR-ek
előző írás	794f607	10.31. 23:00	89 790	739	104
H6 kész	a0423cc	11.1. 03:59	95 078	754	107
X11	a29f49b	11.1. 07:56	95 579	754	108
webes építő és a kiadási tükör	582783f	11.1. 16:49	105 645	848	122
sima MQTT, dokumentáció	8f959f1	11.1. 19:05	112 408	926	125
ma	d21e3ec	11.1. 20:41	112 408	926	126

Több ágon párhuzamosan dolgoztunk, ezért a commitok sorrendje nem szigorúan a munka sorrendje. Az ADR-ek számozása 232-ig megy, de a számozásban vannak hézagok (egy részüket átnevezték az ágak egyesítésekor); a címeket számoljuk, nem a legnagyobb számot. Kiadások: v0.2.0 (11.1., 18:45 UTC) és v0.2.1 (11.1., 20:22 UTC), mindkettő pre-release-ként megjelölve.

H6: SQLite felhasználói módban

Mit terveztünk. Az SQLite 254 268 sornyi C-kód, amely az adatbázist, a WAL-t és a naplót parseolja a lemezről, a lemezt pedig elő lehet állítani vagy módosítani. Addig a magban futott, a mag jogaival. Mit építettünk (ADR-210–ADR-212): az SQLite, a hozzá tartozó libc-részek és a heap egy külön programba kerültek, a dbworker-be, amely EL0-n (aarch64), illetve ring 3-ban (x86_64) fut, saját címtérben. A mag már nem linkeli az SQLite-ot. A worker egy közös memóriaablakon és tizenkét rendszerhíváson át beszél a maggal, és minden visszaadott hosszt és eltolást használat előtt ellenőrzünk. A workerben fellépő hiba (tiltott hozzáférés, nem definiált utasítás, a 30 s-os időkeret túllépése) lezárja a hívást, a worker újraindul, az adatbázis pedig a WAL-ból nyílik meg, mint induláskor; percenként 5 újraindítás után a tároló hibásnak minősül, és nem indul újra a végtelenségig.

Az ár, aarch64-en, HVF alatt mérve, ugyanaz a VM, a beépített SQLite-os mag a workeres maggal szemben, mindkettőből hat váltakozó futtatás:

Mérés	Előtte (a magban)	Utána (worker)	Különbség
belépés a felhasználói módba és kilépés	-	1,1 us körönként
db-bench, 5000 beszúrás 50 tranzakcióban, legjobb / medián	61,9k / 58,4k op/s	54,7k / 53,3k op/s	-11,6% / -8,7%
egy beszúrás tranzakciónként, legjobb / medián	2 319 / 2 148 op/s	2 307 / 2 126 op/s	-0,5% / -1%
teljes biztonsági mentés egyetlen hívással (23 MiB)	514 ms	635 ms	+23%

A lemezírások (1572) és a flushek (319) azonosak, ahogyan kell. Ez nincs szigetelve: a mag továbbra is hisz annak, amit a worker visszaad, az alak ellenőrzése után. Egy kompromittált worker hazudhat (például üres visszavont tanúsítványlistát adhat vissza, és ezzel „visszavonja a visszavonást"), de nem olvashatja a mag memóriáját, a TLS-kulcsokat és a jegykulcsokat. KPTI nincs, ezért a Spectre/Meltdown-típusú szivárgások nincsenek megakadályozva, és semmit nem állítunk róluk; a PAC-kulcson az EL0 és az EL1 osztozik. x86_64-en az átváltás árát KVM-en nem mértük meg (TCG alatt a szám értelmetlen lenne), magának a workernek és a protokollnak a fuzzolása pedig nincs kész. A tárolási tesztcsoport (79 forgatókönyv, mindegyik az SQLite-ot forgatja a workerben) átmegy aarch64 HVF-en és x86_64 TCG-n, aarch64 TCG-n 76 megy át (egyet kihagy, mert a TCG-nek nincs MSI-X-e).

A H7 lezárult, de nem úgy, ahogy bejelentettük. Az időalsó korlát (ADR-050) és a konszenzusos SNTP (T1) lefedi a H7 hatókörét; az NTS (RFC 8915) a hatókörön kívül marad, és megmaradó kockázatként van feljegyezve, nem működő dologként. Nem azt gondoljuk, hogy az idő biztonsága „megoldott", hanem azt, hogy a bizonyítható része kész.

Új hálózati opció. A Contabo nem ad DHCP-t egyéni ISO-nak, ezért a VPS-hez addig más képfájl kellett, mint a laboratóriumi VM-hez. Mostantól a network.mode = "auto" (ADR-214) először a DHCP-t kérdezi, és ha a címbérlet nem érkezik meg a megadott időn belül (dhcp_timeout_s, alapértelmezés 15 s), vagy elvész, az alapértelmezett statikus címet alkalmazza. Kézzel kipróbálva QEMU-n (DHCP-vel a bérletet használja, hálózat nélkül 5 s után visszaáll a statikus címre); füstteszt-forgatókönyv ehhez még nincs.

X11: összevetés a Mosquittóval ugyanazon a VPS-en

Ugyanolyan gép, mint az előző írásban (Contabo, 4 vCPU AMD EPYC, 8 GiB), a terhelés egy Linux gazdagépről érkezik 15 ms távolságból, kölcsönös TLS 1.3 mindkét oldalon ugyanazokkal a tanúsítványokkal, Mosquitto 2.0.21 Debian 13-on, tartósság nélkül. A módszer és a döntések az ADR-213-ban vannak, a nyers adatok a docs/perf-results/ könyvtárban. Három futtatás mediánja.

	urMQTT	Mosquitto 2.0.21
kézfogás/s, 32 / 64 / 128 kliens (bench profil)	169 / 278 / 413	82 / 140 / 184
ugyanez, a szállított korlátokkal	185 / 262 / 333 (128-nál: 202–286 hiba, kézfogás-resetek)	-
memória inaktív kapcsolatonként (20 000 kapcsolat)	0,50 KB magheap (0,66 KB 5000-nél)	26,8 KB folyamatnövekedés
késleltetés p50, QoS 0 / QoS 1, 800 üzenet/s, 64 B	14,0 / 14,8 ms	21,4 / 39,5 ms
QoS 1, 4800 üzenet/s, kézbesítve/s (p50)	4209 (77 ms)	4235 (197 ms)
100 feliratkozó, 50 üzenet/s: p50	16,6 ms	99 ms
egy adatfolyam, QoS 0, 64 B, közzétéve/s	2962 (0–7733)	22 749

Mit jelent ez, és mit nem. A kézfogások mindkét szerverre alsó korlátok: a terheléskeltő egy megosztott VM volt 60–70% ellopott processzoridővel, és 128 szálnál közel volt a saját korlátjához, az urMQTT munkamagjai pedig csak 12–13%-ban voltak foglaltak. A 128 kliensnél mért arány (körülbelül 2,2-szeres) a legértelmezhetőbb; 32-nél és 64-nél többnyire a kliensek várakozását méri. A memóriaszámok nem ugyanazt számolják (magheap szemben a folyamat RSS-ével), ezért a „körülbelül 50-szer kevesebb" nagyságrend, nem pontos arány. A 14 ms-os késleltetés egyetlen hálózati kör (körülbelül 15 ms), tehát „nincs mérhető brókeridő"; a farkakat (p99 körülbelül 100–200 ms) mindkét bróker esetében a megosztott gazdagépek uralják. A körülbelül 20% alatti különbségeket nem állítjuk.

Ami nem nekünk kedvezett, és benne maradt a táblázatokban: egyetlen TCP-adatfolyam az urMQTT-n át 2–8-szor kevesebbet vitt, mint a Mosquittón át, a futtatások között nullától 7,7 ezer üzenet/másodpercig terjedő ingadozással, a kezelő 20 ms-os watchdogja pedig megszakította az élő kapcsolatokat, amikor a hipervizor leállította a vCPU-t (éles beállításban action = "drop", futtatásonként 6–8 kapcsolat QoS 0 elárasztásnál). Mindkettőt a következő szakasz írja le, mert az okaik a mi kódunkban voltak.

Miért volt lassú az egy adatfolyam: okok, nem kifogások

A legkönnyebb az lett volna, hogy „megosztott VPS". Nem ezt tettük, hanem ugyanazon a VPS-en, ugyanazzal a módszerrel okokat kerestünk. Öt okot találtunk, négyet az adatúton és egyet a watchdogban (ADR-221–ADR-224):

Tünet az X11-ben	Ok az urMQTT-ben	Változtatás
egy adatfolyam 1,9k üzenet/s, gyakran 0 kézbesítve	Elveszett ébresztés: a kimeneti ciklus a kész kapcsolatok listáját felülírta az éppen kiírttal; az a feliratkozó, akinek a kimeneti puffere egyszer megtelt, soha többé nem kapott kiszolgálást, amíg egy PINGRESP fel nem ébresztette	javítva (ADR-223)
néhány százalék veszteség 48k-t 14k üzenet/s-ra ront	minden elveszett szegmens utáni szegmens el lett dobva (csak sorrendben vétel), így a helyreállítás szegmensenként egy hálózati kör árába került	sorrenden kívüli szegmensek sora, SACK (ADR-222)
4,4 MB/s plafon 15 ms-nál	16 bites ablak, 64 KiB-os küldési sor és lassú indítás, amely az ACK-okat számolta, nem a bájtokat	ablakskálázás, időbélyegek, bájtszámlálás (ADR-222)
minden, a beleférő adatfolyam körei 0–10 ms-ot várnak	a diszpécser a következő 10 ms-os ütemig aludt (a virtio-net-nek nincs megszakítása a vételhez)	a NIC lekérdezése 200 us-onként, amíg vannak kapcsolatok (ADR-224)
futtatásonként 1–8 megszakadt kapcsolat	a watchdog a kezelőnek az eltelt időt számolta fel, a VPS pedig gyakran és sokáig leállítja a vCPU-kat	az időkeret az az idő, amelyet a mag ténylegesen futott (ADR-221)

A leállások valódiak: ezen a VPS-en a 0–2. magoknak 5 másodpercenként medián 36–80 késett ütésük volt, az ablak legrosszabb leállása pedig medián körülbelül 70 ms, legfeljebb 0,9 s (3. mag, adatbázis és napló: legfeljebb 1,55 s), miközben a gazdagép nem jelent ellopott időt (host steal 0 us). Ezért a watchdognak második órára volt szüksége, nem nagyobb időkeretre.

	X11-kód (7f9517e)	most (86a71ff)	Mosquitto
egy adatfolyam, QoS 0, 64 B, közzétéve / kézbesítve s-onként	1,9k / 0	23,7k / 12,6k	29,3k / 29,2k
egy adatfolyam, QoS 0, 1 KiB	0 / 0	3,9k / 2,3k	5,4k / 5,4k
16 pár, elárasztás, QoS 0, 64 B	24,7k / 20,0k	43,2k / 37,4k	31,4k / 30,7k
16 pár, elárasztás, QoS 0, 1 KiB	3,7k / 2,9k	5,0k / 4,5k	5,9k / 5,7k
elveszett kapcsolatok futtatásonként (16 pár, 64 B)	13 (7–16)	0 (0–0)	0

Watchdog: 148 megszakadt kapcsolat 30 terhelt futtatásban előtte, 0 a 24 futtatásban utána; egy helyi eszközön, amely késlelteti és veszíti a kereteket, 0,1% veszteségnél egy 64 B-os adatfolyam, amely 14,3k üzenet/s-ot adott (az X11 magja), most 41,0k-t ad, 0,5%-nál pedig 5,0k helyett 17,7k-t.

Amit ez nem mond. Az urMQTT továbbra sem gyorsabb a Mosquittónál egy adatfolyamon: 64 B-nál a sebességének körülbelül 80%-át közli, és körülbelül 40%-át kézbesíti, mert eldobja a QoS 0-t, ha a feliratkozó adatfolyama lassabb a kiadóénál (a Mosquitto korlát nélkül sorba állítja). 1 KiB-nál a 16 páros elárasztásban a Mosquitto körülbelül 15%-kal előrébb van, ami a zajon belül van. A terheléskeltő ismét megosztott VM volt 58–77% ellopott idővel. A második kör (a heap zárolása az adatúton kívülre, SACK a küldési oldalon és más) a be nem épített perf-single-flow-wip ágon van; a számai még nem állítások, és itt nem közöljük őket.

Ígéret, amelyet nem tettünk, de teljesítettünk: a konfiguráció adat

Eddig minden konfiguráció új build volt: a kulcsok és a korlátok bele voltak építve a képfájlba. A C1 ezt megfordítja (ADR-215–ADR-219): a magot egyszer építjük, a konfiguráció pedig adat.

• Az urmqtt-cfg blob (C1a): verziózott, kanonikus írásmód (a mezők növekvő címkék szerint, SHA-256 ujjlenyomat, opcionális különálló Ed25519 aláírás), 70 mező alapértékekkel és korlátokkal, és egy dekóder, amely minden hibásat visszautasít.
• A mag Limine-modulként olvassa (C1b), bármi más előtt, aarch64-en és x86_64-en. Minden ENV-hez, a dev kivételével, egyetlen kiadott mag van (a release, prod és bench aarch64 ELF-jeinek azonos a SHA-256-ja; csak aarch64-en ellenőrizve). A kiadott mag visszautasítja a fejlesztői konfigurációt, konfiguráció nélkül pedig „refusing to serve" üzenetet ír, és semmit nem szolgál ki.
• A telepített lemez hordozza a konfigurációt, és a frissítés megtartja (C1c).
• Az urmqtt-config és az ISO-sablon (C1d): pack, show, verify, a pack --iso pedig a konfigurációs hely mindkét példányát és a 24 modulösszegzést cseréli a kész ISO-ban. Az eredmény bájtról bájtra azonos azzal az ISO-val, amelyet a mkiso.sh --config épít. A v0.2.0 kiadás sablonja 63 111 168 bájt.
• Bizalmi nyilatkozat (ADR-219): a konfigurált képfájl induláskor kiírja a konfiguráció ujjlenyomatát (config: fingerprint ...), az aláírás pedig opcionális és alapértelmezés szerint ki van kapcsolva. A módosított ISO-nak nincs hivatalos összegzése; az ujjlenyomat az eszköz arra, hogy lássuk, mi van benne.

Az építő az aldo.tech-en

Ugyanazt, amit az urmqtt-config pack --iso csinál, a weboldal is csinálja, ugyanazzal a kóddal: az eszközkönyvtár WebAssemblyre fordítva (1,06 MB, importok nélkül és unsafe blokk nélkül). Az oldal a aldo.tech/hu/termekek/urmqtt-builder/ címen érhető el, és az oldal mind a 15 nyelvén létezik (például hr).

• Semmi nem hagyja el a böngészőt. A tanúsítványok, a privát kulcsok és a kész ISO a számítógépen maradnak; az oldal csak a kiadási fájlokat tölti le erről a helyről, nincs követés, és nincs harmadik fél szkriptje. Az élő tesztben egyetlen kérés sem vitt kulcsanyagot.
• Kiadási tükör (ADR-227): óránként (systemd timer, alacsony prioritású) átmásolja a kiadásokat a GitHubról, mindegyiket közzététel előtt ellenőrzi, az oldal pedig a böngészőben az oldalba beépített kulccsal ellenőrzi a SHA256SUMS aláírását, és csak azután írja a konfigurációt a sablonba. A sikertelen ellenőrzés blokkolja a letöltést.
• Alapértelmezésben egyszerű, szükség esetén haladó (ADR-232): az első képernyő három lépés (hol fut, az Ön tanúsítványai, a képfájl neve). Egyetlen húzásos mező a tartalma alapján szétválogatja a tanúsítványt, a kulcsot és a CA-t. A haladó nézet megnyitja mind a 70 mezőt, keresést, valamint a TOML importját és exportját; mindkét nézet ugyanazt az állapotot szerkeszti. A sablon (63 MB) letöltődik, amíg a felhasználó tölti az űrlapot. Az élő próbában, próbatükörrel és próbakulccsal az ISO böngészőbeli felépítése 5–18 s-ig tartott.

Az emulátor, opcionálisan. A „ISO letöltése" mellett ott áll az „Kipróbálás emulátorban": a WebAssemblyre fordított QEMU a frissen épített képfájlt futtatja egy böngészőlapon. A kattintás előtt semmi nem töltődik le belőle (először körülbelül 3 MB). Az emulátor csak BIOS-os, hálózat nélküli (hogy a felhasználó forgalma ne haladjon át valamilyen közvetítőn, és ne sértse a „semmi nem hagyja el a böngészőt" elvet), körülbelül 1,5 GB memóriát kér, és asztali böngészőt igényel (Chrome-mal tesztelve; Firefoxszal és Safarival nem). Benne az urMQTT körülbelül 8 s alatt eljut a URMQTT READY üzenetig (a visszaszámlálás átugrásával), és ugyanazt a konfigurációs ujjlenyomatot írja ki, mint az oldal, ami bizonyíték arra, hogy éppen ez a konfiguráció indult el. Az indulás körülbelül 2-szer lassabb, mint az eredeti QEMU ugyanazon a Macen (0,82 s szemben 1,9 s-mal), a kriptográfia pedig körülbelül 58-szor lassabb, mert a hardveres utasítások emuláltak. Ezért az emulátorból semmilyen sebességre vonatkozó állítást nem vonunk le, az oldal pedig ezt a futtatás előtt kimondja. A build során négy bájtot kellett foltozni a .wasm-ban az eredeti emulátorban a POPCNT utasítás fordításában lévő hiba miatt (még nem jelentettük be); maga az emulátor GPL alatt áll, a forráskód felkínálásával.

Sima MQTT, csak olyan hálózatokra, amelyekben megbízunk

A sima MQTT (TCP 1883, TLS nélkül) nagyon gyakori az IoT-ban: alapértelmezett a Mosquittóban, az Arduino és ESP legtöbb firmware-ében, a Tasmotában, a Zigbee2MQTT-ben és a Home Assistantben, használják szegmentált ipari hálózatokban, VPN mögött és privát LAN-okon, sőt olyan eszközökön is, amelyeknek nincs órájuk (a tanúsítványokhoz dátum kell), vagy nincs elég flashük vagy processzoruk a TLS-hez. Megbízhatatlan hálózaton nem elfogadható: aki az úton van, olvassa és módosítja a forgalmat. Ezért a P1 (ADR-229–ADR-231) kifejezett, korlátozott választás, alapértelmezés szerint kikapcsolva, a TLS port pedig megmarad; ezzel a TLS nem kapcsol ki, a sima port mellette érkezik.

• A megengedett hálózatok listája kötelező (allow_from, CIDR-ek), és SYN-nél ellenőrzik: a listán kívül nincs SYN-ACK és nincs állapot. A teljes internethez (0.0.0.0/0) külön, kifejezett opció kell.
• Három bejelentkezési mód: jelszó (alapértelmezett, ha be van kapcsolva; PBKDF2-HMAC-SHA-256, só, 10 000 iteráció, állandó idejű összehasonlítás, zárolás cím szerint), anonim (egy beállított identitás saját ACL-lel) és cím szerint (ip). Az építő a jelszót a böngészőben hasheli, és a memóriában csak az összegzést tartja.
• Kevesebb jog, mint az mTLS-nél: a sima kliensnek soha nincs szolgáltatási, üzemeltetői és vezérlési joga, nincs $SYS-e és konzolja, saját munkamenetei vannak ($plain/<identitás>/<kliens azonosítója>, csak tiszták), és a saját korlátok és az engedélyezettek jegyzéke továbbra is kötelezi.
• Amit elveszítünk, a SECURITY.md-ben áll: a bizalmasság, az integritás, a bróker hitelessége és a rögzített bejelentkezés újrajátszása. Ezt konfigurációval nem lehet kijavítani; ilyen, ha nincs TLS.

Laptopon mérve (Apple silicon, HVF, QEMU felhasználói hálózat), 16 pár, 64 B, három 10 s-os futtatás: 8000 üzenet/s mellett a TLS-es és a sima út minden üzenetet azonos késleltetéssel kézbesít (p50 0,17 ms szemben 0,13–0,18 ms-mal), új kapcsolatok másodpercenként: TLS körülbelül 2600–2750, anonim sima körülbelül 4900–7800, a jelszavas bejelentkezés pedig a drága rész: egy PBKDF2 körülbelül 2,5 ms-ba kerül, ezért az új bejelentkezések száma körülbelül 200-ra korlátozódik adatmagonként másodpercenként (két magon 308–342-t mértünk). Az elárasztás azon a gépen nem stabil műszer (20k–440k kézbesített másodpercenként a futtatások között), és belőle nem vonunk le következtetést. A sima út összevetése a Mosquittóval VPS-en még nem készült el. Tesztek: a plaintext füstteszt-csoport 7 a 7-ből aarch64 HVF-en és x86_64 TCG-n, új fuzz-cél a plain_input (2,3 millió futtatás lelet nélkül).

Hibák, amelyeket az élő üzem talált

Két dolgot nem a tesztek fogtak meg, hanem az első bekapcsolás a valódi helyen:

• Az oldal a kiadási fájlokat egy könyvtárral feljebb kereste, ezért minden aláírás-ellenőrzés 404-et adott (javítás: 13af301). A teszt egy másik útvonalon lévő próbatükröt használt.
• Az emulátor billentyűzete soha nem jutott el a vendégig: az ok nem a billentyűk rossz fordítása volt, hanem az, hogy a párbeszédablak egyáltalán nem figyelte a billentyűket (javítás az ADR-232-ben, billentyűk nélküli indítási bejegyzéssel).

Tanulságok

• Az okot keressük, ne a környezetet hibáztassuk. Az egy adatfolyam gyengeségeinek többsége és az összes megszakadt kapcsolat a miénk volt; a hipervizor valódi, de mérni kellett, nem feltételezni.
• Egy másik termékkel való összevetésnek a veszteségeket is tartalmaznia kell. Egy táblázat, amelyben csak a mi győzelmeink szerepelnek, nem lenne összevetés.
• A mérőműszernek vannak határai. Egy megosztott terheléskeltő 60–70% ellopott idővel megváltoztatja, mit jelentenek a számok; ezért írunk „alsó korlátot", és nem állítunk 20% alatti különbségeket.
• A szigetelés nem bizonyíték. Az SQLite EL0-n azt csökkenti, mit tehet egy hiba benne, nem azt, miről hazudhat.
• A valódi telepítés megtalálja azt, amit a tesztek nem kérdeznek: a rosszul összerakott útvonalat és a billentyűket, amelyeket senki nem figyel.

Ami még nincs bizonyítva

• A kiadás aláírókulcsa egyelőre próbakulcs; a v0.2.0 és a v0.2.1 pre-release, a hozzájuk tartozó képfájlok pedig fejlesztői képfájlok próbatanúsítványokkal (a sablon kivételével, amely konfiguráció nélküli).
• Az építőoldal 13 fordítását (és ezét az írásét) AI írta, és tesztek meg mintavételek ellenőrizték, nem anyanyelvi beszélők.
• A Mosquittóval való összevetés egy ülés, egy út és egy megosztott terheléskeltő, megosztott VPS-en; a 20% alatti különbségek nem állítások.
• A sima utat nem mértük VPS-en, és nem a Mosquitto ellen.
• A Lighthouse az új egyszerű nézeten nincs megerősítve (a régi nézet: akadálymentesség 95 vagy több).
• Bare metal, a worker x86_64-es ára KVM-en, Firefox és Safari az emulátorhoz: nincs mérve.

Mi következik

• D1: nyilvános demo bróker. A böngészős emulátort nem tehetjük nyilvánossá: egyetlen látogató lapján él, 20–100-szor lassabb a KVM-nél, nincs bejövő hálózata, és a lap bezárásával eltűnik; az internet átirányítása valaki más böngészőjébe ráadásul visszaélés lenne. Lehetséges egy valódi demo bróker: az urMQTT egy VPS-en, az aldo.tech egyik neve mögött, közzétett próba-CA-val, szigorú ACL-lel és kis korlátokkal. Ez egyelőre csak ötlet, nem építés, és kifejezett hozzájárulás kell a nyilvános kitételhez.
• A második kör az egy adatfolyamhoz (perf-single-flow-wip ág): csak akkor, ha VPS-en megmértük és beépítettük.
• A sima út a Mosquitto ellen VPS-en, a sima MQTT-hez a fiókok bejelentkezése és visszavonása aláírt vezérlőcsatornán át.
• A kiadás után: bare metal (X12–X16), IOMMU és Secure Boot, lemeztitkosítás.

A kód a github.com/zeljan-alduk/urMQTT címen van, a docs/PROGRESS.md pedig továbbra is az egyetlen igazságforrás arról, mi működik valóban, a docs/PERFORMANCE.md arról, mit mértünk. Pre-alfa, mint korábban; a hibabejelentéseket és a biztonsági bejelentéseket a SECURITY.md útmutatása szerint szívesen fogadjuk.