urMQTT po VPS-ie: SQLite w trybie użytkownika, porównanie z Mosquitto, konfiguracja jako dane i konstruktor w przeglądarce

Drugi tekst, urMQTT na prawdziwym VPS-ie, zakończył się listą „Co dalej": H6 (SQLite poza jądrem), H7 (bezpieczeństwo czasu), X11 (porównanie z Mosquitto na tym samym VPS-ie) i pierwsze wydanie. Ten tekst idzie za tą listą w tej samej kolejności, a potem dodaje dwie rzeczy, których na liście nie było, bo pojawiły się po drodze: konfigurację jako dane, z webowym konstruktorem ISO, oraz opcjonalny zwykły MQTT bez TLS. Tak jak wcześniej: co planowaliśmy, co zbudowaliśmy, co nas zaskoczyło i co pozostaje otwarte. W tym tekście jest też kilka wyników, które nie przemawiają na korzyść urMQTT; zostawiliśmy je, bo są częścią prawdy.

Zastrzeżenie na wstępie pozostaje to samo: projekt jest w fazie pre-alfa, pierwsze wydanie jest tylko dla VPS-ów z KVM, a liczby mierzą kod, testy i określone eksperymenty, a nie dojrzałość produkcyjną.

Jak to wyglądało w czasie

Od poprzedniego tekstu (31.10. o 23:00) do dziś (1.11. o 20:41) w repozytorium przybyło 59 commitów, łącznie jest ich 178. Wszystkie powstały w jednym dniu kalendarzowym, więc obowiązuje to samo ostrzeżenie co wcześniej: projekt powstaje z Claude Code (commity mają Co-Authored-By: Claude), plan, kod, testy i ADR-y powstają w krótkich, zamkniętych pętlach, a liczby poniżej mówią o ilości kodu i weryfikacji, a nie o tym, ile w nich pracy człowieka.

Liczby wyliczono tą samą metodą co w poprzednim tekście: wszystkie pliki .rs poza vendor/ i fuzz/, funkcje #[test], nagłówki ## ADR- w docs/DECISIONS.md.

Moment	Commit	Czas	Linii Rusta	Testów	ADR-ów
poprzedni tekst	794f607	31.10. 23:00	89 790	739	104
H6 gotowe	a0423cc	1.11. 03:59	95 078	754	107
X11	a29f49b	1.11. 07:56	95 579	754	108
webowy konstruktor i lustro wydań	582783f	1.11. 16:49	105 645	848	122
zwykły MQTT, dokumentacja	8f959f1	1.11. 19:05	112 408	926	125
dziś	d21e3ec	1.11. 20:41	112 408	926	126

Pracowano równolegle na wielu gałęziach, więc kolejność commitów nie jest ściśle kolejnością pracy. ADR-y są numerowane do 232, ale numeracja ma luki (część została przemianowana przy scalaniu gałęzi); liczymy nagłówki, a nie największy numer. Wydania: v0.2.0 (1.11., 18:45 UTC) i v0.2.1 (1.11., 20:22 UTC), oba oznaczone jako pre-release.

H6: SQLite w trybie użytkownika

Co planowaliśmy. SQLite to 254 268 linii C, które parsują bazę, WAL i dziennik z dysku, a dysk może być spreparowany lub zmieniony. Dotąd działał w jądrze, z uprawnieniami jądra. Co zbudowaliśmy (ADR-210 do ADR-212): SQLite, jego części libc i sterta zostały przeniesione do osobnego programu, dbworker, który działa na EL0 (aarch64), czyli ring 3 (x86_64), we własnej przestrzeni adresowej. Jądro już nie linkuje SQLite. Worker rozmawia z jądrem przez wspólne okno pamięci i dwanaście wywołań systemowych, a każda zwrócona długość i każde przesunięcie jest sprawdzane przed użyciem. Błąd w workerze (niedozwolony dostęp, niezdefiniowana instrukcja, przekroczony budżet czasu 30 s) kończy wywołanie, worker jest uruchamiany ponownie, a baza otwiera się z WAL tak jak przy starcie; po 5 restartach w ciągu minuty magazyn jest uznawany za uszkodzony, a nie restartowany w nieskończoność.

Koszt, zmierzony na aarch64 pod HVF, ta sama VM, jądro z wbudowanym SQLite wobec jądra z workerem, po sześć naprzemiennych uruchomień każdego:

Pomiar	Przed (w jądrze)	Po (worker)	Różnica
wejście do trybu użytkownika i wyjście z niego	-	1,1 us na obieg
db-bench, 5 000 wstawień w 50 transakcjach, najlepszy / mediana	61,9k / 58,4k op/s	54,7k / 53,3k op/s	-11,6 % / -8,7 %
jedno wstawienie na transakcję, najlepszy / mediana	2 319 / 2 148 op/s	2 307 / 2 126 op/s	-0,5 % / -1 %
cała kopia zapasowa jednym wywołaniem (23 MiB)	514 ms	635 ms	+23 %

Zapisy na dysk (1 572) i flushe (319) są identyczne, jak być powinno. To nie jest odizolowane: jądro nadal ufa temu, co zwróci worker, po sprawdzeniu kształtu. Skompromitowany worker może kłamać (na przykład zwrócić pustą listę unieważnionych certyfikatów, a tym samym je „odwołać z unieważnienia"), ale nie może czytać pamięci jądra, kluczy TLS ani kluczy ticketów. Nie ma KPTI, więc wycieki typu Spectre/Meltdown nie są zablokowane i niczego o nich nie twierdzimy; klucz PAC dzielą EL0 i EL1. Na x86_64 kosztu przełączania nie zmierzyliśmy na KVM (pod TCG liczba byłaby bez sensu), a samo fuzzowanie workera i protokołu nie jest skończone. Zestaw testów magazynu (79 scenariuszy, każdy obraca SQLite w workerze) przechodzi na aarch64 HVF i x86_64 TCG, a na aarch64 TCG 76 (jeden jest pomijany, bo TCG nie ma MSI-X).

H7 jest zamknięty, ale nie tak, jak zapowiadaliśmy. Dolna granica czasu (ADR-050) i SNTP z konsensusem (T1) pokrywają zakres H7; NTS (RFC 8915) pozostaje poza zakresem i jest zapisany jako ryzyko szczątkowe, a nie jako coś, co działa. Nie uważamy, że bezpieczeństwo czasu jest „rozwiązane", tylko że jego dowodliwa część jest gotowa.

Nowa opcja sieciowa. Contabo nie daje DHCP dla własnego ISO, więc VPS dotąd wymagał innego obrazu niż laboratoryjna VM. Teraz network.mode = "auto" (ADR-214) najpierw pyta DHCP, a jeśli dzierżawy nie ma w zadanym czasie (dhcp_timeout_s, domyślnie 15 s) lub ją straci, stosuje podany adres statyczny. Wypróbowane ręcznie na QEMU (z DHCP używa dzierżawy, bez sieci po 5 s wraca do adresu statycznego); smoke scenariusza na to jeszcze nie ma.

X11: porównanie z Mosquitto na tym samym VPS-ie

Ten sam rodzaj maszyny co w poprzednim tekście (Contabo, 4 vCPU AMD EPYC, 8 GiB), obciążenie z hosta Linux oddalonego o 15 ms, wzajemny TLS 1.3 z tymi samymi certyfikatami po obu stronach, Mosquitto 2.0.21 na Debianie 13 bez trwałości. Metoda i decyzje są w ADR-213, surowe dane w docs/perf-results/. Mediana z trzech uruchomień.

	urMQTT	Mosquitto 2.0.21
uzgodnienia/s, 32 / 64 / 128 klientów (profil bench)	169 / 278 / 413	82 / 140 / 184
to samo, z limitami takimi, jakie są wydawane	185 / 262 / 333 (przy 128: 202 do 286 błędów, resety uzgodnień)	-
pamięć na bezczynne połączenie (20 000 połączeń)	0,50 KB sterty jądra (0,66 KB przy 5 000)	26,8 KB wzrostu procesu
opóźnienie p50, QoS 0 / QoS 1, 800 wiadomości/s, 64 B	14,0 / 14,8 ms	21,4 / 39,5 ms
QoS 1, 4 800 wiadomości/s, dostarczone/s (p50)	4 209 (77 ms)	4 235 (197 ms)
100 subskrybentów, 50 wiadomości/s: p50	16,6 ms	99 ms
pojedynczy strumień, QoS 0, 64 B, opublikowane/s	2 962 (0 do 7 733)	22 749

Co to znaczy, a czego nie. Uzgodnienia są dolnymi granicami dla obu serwerów: generator obciążenia to współdzielona VM z 60 do 70 % skradzionego czasu procesora, a przy 128 wątkach był blisko własnego limitu, podczas gdy rdzenie robocze urMQTT były zajęte tylko w 12 do 13 %. Stosunek przy 128 klientach (około 2,2 razy) jest najbardziej sensowny; przy 32 i 64 w większości mierzy oczekiwanie klientów. Liczby pamięci nie liczą tego samego (sterta jądra wobec RSS procesu), więc „około 50 razy mniej" to rząd wielkości, a nie dokładny stosunek. Opóźnienie 14 ms to jeden obieg sieci (około 15 ms), a więc „brak mierzalnego czasu brokera"; ogony (p99 około 100 do 200 ms) są u obu brokerów zdominowane przez współdzielone hosty. Różnic poniżej około 20 % nie twierdzimy.

Co nie wypadło na naszą korzyść i zostało w tabelach: pojedynczy strumień TCP przez urMQTT niósł 2 do 8 razy mniej niż przez Mosquitto, ze zmianami od zera do 7,7 tysiąca wiadomości na sekundę między uruchomieniami, a 20-milisekundowy watchdog handlera przerywał żywe połączenia, gdy hipernadzorca zatrzymał vCPU (w konfiguracji produkcyjnej action = "drop", 6 do 8 połączeń na uruchomienie przy zalewaniu QoS 0). Obie sprawy są opisane w następnej sekcji, bo miały przyczyny w naszym kodzie.

Dlaczego pojedynczy strumień był wolny: przyczyny, a nie wymówki

Najłatwiej byłoby powiedzieć „współdzielony VPS". Nie powiedzieliśmy tego, tylko na tym samym VPS-ie i tą samą metodą szukaliśmy przyczyn. Znaleziono pięć, cztery w ścieżce danych i jedną w watchdogu (ADR-221 do ADR-224):

Objaw w X11	Przyczyna w urMQTT	Zmiana
pojedynczy strumień 1,9k wiadomości/s, często 0 dostarczonych	Zgubione wybudzenie: pętla wyjścia zwracała listę gotowych połączeń na wierzch właśnie wypisanej; subskrybent, którego bufor wyjściowy raz się zapełnił, nigdy więcej nie był obsługiwany, dopóki nie obudził go PINGRESP	naprawione (ADR-223)
kilka procent strat zamienia 48k w 14k wiadomości/s	każdy segment po zgubionym był odrzucany (odbiór tylko po kolei), więc odzyskanie kosztowało obieg sieci na segment	kolejka segmentów poza kolejnością, SACK (ADR-222)
sufit 4,4 MB/s przy 15 ms	16-bitowe okno, kolejka wysyłania 64 KiB i wolny start liczący ACK-i, a nie bajty	skalowanie okna, znaczniki czasu, liczenie bajtów (ADR-222)
każdy obieg strumienia, który się mieści, czeka 0 do 10 ms	dyspozytor spał do następnego taktu 10 ms (virtio-net nie ma przerwania odbioru)	odpytywanie NIC co 200 us, dopóki istnieją połączenia (ADR-224)
1 do 8 przerwanych połączeń na uruchomienie	watchdog naliczał handlerowi upłynięty czas, a VPS zatrzymuje vCPU często i na długo	budżetem jest czas, który jądro faktycznie pracowało (ADR-221)

Zatrzymania są prawdziwe: na tym VPS-ie rdzenie 0 do 2 miały medianę 36 do 80 spóźnionych taktów na 5 sekund, a najgorsze zatrzymanie w oknie miało medianę około 70 ms i do 0,9 s (rdzeń 3, baza i dziennik: do 1,55 s), podczas gdy host nie zgłasza skradzionego czasu (host steal 0 us). Dlatego watchdog potrzebował drugiego zegara, a nie większego budżetu.

	kod z X11 (7f9517e)	teraz (86a71ff)	Mosquitto
pojedynczy strumień, QoS 0, 64 B, opublikowane / dostarczone na s	1,9k / 0	23,7k / 12,6k	29,3k / 29,2k
pojedynczy strumień, QoS 0, 1 KiB	0 / 0	3,9k / 2,3k	5,4k / 5,4k
16 par, zalewanie, QoS 0, 64 B	24,7k / 20,0k	43,2k / 37,4k	31,4k / 30,7k
16 par, zalewanie, QoS 0, 1 KiB	3,7k / 2,9k	5,0k / 4,5k	5,9k / 5,7k
zgubione połączenia na uruchomienie (16 par, 64 B)	13 (7 do 16)	0 (0 do 0)	0

Watchdog: 148 przerwanych połączeń w 30 obciążonych uruchomieniach przed, 0 w 24 uruchomieniach po; na lokalnym urządzeniu, które opóźnia i gubi ramki, przy stracie 0,1 % pojedynczy strumień 64 B z 14,3k wiadomości/s (jądro z X11) ma teraz 41,0k, a przy 0,5 % z 5,0k na 17,7k.

Czego to nie mówi. urMQTT nadal nie jest szybszy od Mosquitto na pojedynczym strumieniu: przy 64 B publikuje około 80 % jego szybkości, a dostarcza około 40 %, bo odrzuca QoS 0, gdy strumień subskrybenta jest wolniejszy od strumienia wydawcy (Mosquitto bez limitu kolejkuje). Przy 1 KiB w 16-parowym zalewaniu Mosquitto jest z przodu o około 15 %, co mieści się w szumie. Generator znów był współdzieloną VM z 58 do 77 % skradzionego czasu. Druga runda (blokowanie sterty poza ścieżką danych, SACK po stronie wysyłania i inne) jest na niezintegrowanej gałęzi perf-single-flow-wip; jej liczby nie są jeszcze twierdzeniami i tu ich nie podajemy.

Obietnica, której nie składaliśmy, a którą spełniliśmy: konfiguracja jest danymi

Dotąd każda konfiguracja była nowym buildem: klucze i limity były wbudowane w obraz. C1 to odwraca (ADR-215 do ADR-219): jądro buduje się raz, a konfiguracja jest danymi.

• Blob urmqtt-cfg (C1a): wersjonowany, kanoniczny zapis (pola w rosnącej kolejności znaczników, odcisk SHA-256, opcjonalny oddzielny podpis Ed25519), 70 pól z wartościami domyślnymi i granicami, dekoder odrzucający wszystko, co niepoprawne.
• Jądro czyta go jako moduł Limine (C1b), przed czymkolwiek innym, na aarch64 i x86_64. Istnieje jedno wydawane jądro dla każdego ENV oprócz dev (ELF-y aarch64 dla release, prod i bench mają ten sam SHA-256; sprawdzone tylko na aarch64). Wydawane jądro odrzuca konfigurację deweloperską, a bez konfiguracji pisze „refusing to serve" i niczego nie obsługuje.
• Zainstalowany dysk niesie konfigurację i aktualizacja ją zachowuje (C1c).
• urmqtt-config i szablon ISO (C1d): pack, show, verify, a pack --iso zastępuje obie kopie miejsca na konfigurację i 24 skróty modułów w gotowym ISO. Wynik jest bajt w bajt taki sam jak ISO budowane przez mkiso.sh --config. Szablon wydania v0.2.0 ma 63 111 168 bajtów.
• Oświadczenie o zaufaniu (ADR-219): skonfigurowany obraz przy starcie wypisuje odcisk konfiguracji (config: fingerprint ...), a podpis jest opcjonalny i domyślnie wyłączony. Zmienione ISO nie ma oficjalnego skrótu; odcisk to sposób, by zobaczyć, co jest w środku.

Konstruktor na aldo.tech

To samo, co robi urmqtt-config pack --iso, robi strona internetowa, tym samym kodem: biblioteka narzędzi skompilowana do WebAssembly (1,06 MB, bez importów i bez bloku unsafe). Strona jest pod adresem aldo.tech/pl/produkty/urmqtt-builder/ i istnieje we wszystkich 15 językach serwisu (na przykład hr).

• Nic nie opuszcza przeglądarki. Certyfikaty, klucze prywatne i gotowe ISO zostają na komputerze; strona pobiera tylko pliki wydań z tego serwisu, nie ma śledzenia ani skryptów osób trzecich. W teście na żywo żadne żądanie nie niosło materiału kluczowego.
• Lustro wydań (ADR-227): co godzinę (timer systemd, niski priorytet) kopiuje wydania z GitHuba, każde sprawdza przed publikacją, a strona w przeglądarce weryfikuje podpis SHA256SUMS kluczem wbudowanym w stronę, i dopiero potem wpisuje konfigurację do szablonu. Nieudana weryfikacja blokuje pobranie.
• Prosto domyślnie, zaawansowanie w razie potrzeby (ADR-232): pierwszy ekran to trzy kroki (gdzie działa, twoje certyfikaty, nazwa obrazu). Jedno pole do przeciągania plików sortuje certyfikat, klucz i CA według zawartości. Widok zaawansowany otwiera każde z 70 pól, wyszukiwanie, import i eksport TOML; oba widoki edytują ten sam stan. Szablon (63 MB) pobiera się, gdy użytkownik wypełnia formularz. W próbie na żywo, z próbnym lustrem i próbnym kluczem, zbudowanie ISO w przeglądarce trwało 5 do 18 s.

Emulator, opcjonalnie. Obok „Pobierz ISO" stoi „Wypróbuj w emulatorze": QEMU skompilowane do WebAssembly uruchamia właśnie zbudowany obraz w karcie przeglądarki. Nic z niego nie jest pobierane przed kliknięciem (około 3 MB za pierwszym razem). Emulator jest tylko BIOS, bez sieci (żeby ruch użytkownika nie przechodził przez jakiegoś pośrednika i nie naruszał „nic nie opuszcza przeglądarki"), wymaga około 1,5 GB pamięci i przeglądarki na komputerze (testowany Chrome; Firefox i Safari nie). urMQTT dochodzi w nim do URMQTT READY w około 8 s (z pominiętym odliczaniem) i wypisuje ten sam odcisk konfiguracji co strona, co jest dowodem, że uruchomiono właśnie tę konfigurację. Start jest około 2 razy wolniejszy niż w natywnym QEMU na tym samym Macu (0,82 s wobec 1,9 s), a kryptografia około 58 razy wolniejsza, bo instrukcje sprzętowe są emulowane. Dlatego z emulatora nie wyciągamy żadnych twierdzeń o szybkości, a strona mówi to przed uruchomieniem. Przy budowaniu trzeba było załatać cztery bajty w .wasm z powodu błędu w tłumaczeniu instrukcji POPCNT w źródłowym emulatorze (jeszcze go nie zgłosiliśmy); sam emulator jest na GPL, z ofertą kodu źródłowego.

Zwykły MQTT, tylko dla sieci, którym ufasz

Zwykły MQTT (TCP 1883, bez TLS) jest w IoT bardzo częsty: jest domyślny w Mosquitto, w większości firmware'u dla Arduino i ESP, w Tasmocie, Zigbee2MQTT i Home Assistant, a używa się go też wewnątrz segmentowanych sieci przemysłowych, za VPN-em i w prywatnych sieciach LAN, a także na urządzeniach bez zegara (certyfikaty wymagają daty), bez dość flasha lub procesora na TLS. Przez niezaufaną sieć jest niedopuszczalny: kto jest po drodze, czyta i zmienia ruch. Dlatego P1 (ADR-229 do ADR-231) to wyraźny, ograniczony wybór, domyślnie wyłączony, a port TLS zostaje; TLS nie jest tym wyłączany, zwykły port pojawia się obok niego.

• Lista dozwolonych sieci jest obowiązkowa (allow_from, CIDR-y) i sprawdzana przy SYN: poza listą nie ma SYN-ACK ani stanu. Cały internet (0.0.0.0/0) wymaga osobnej, wyraźnej opcji.
• Trzy tryby logowania: hasło (domyślne, gdy włączone; PBKDF2-HMAC-SHA-256, sól, 10 000 iteracji, porównanie w stałym czasie, blokada według adresu), anonimowo (jedna skonfigurowana tożsamość z własnym ACL) i według adresu (ip). Konstruktor haszuje hasło w przeglądarce i w pamięci trzyma tylko skrót.
• Mniej uprawnień niż mTLS: zwykły klient nigdy nie ma uprawnień serwisowych, operatorskich ani zarządzania, nie ma $SYS ani konsoli, ma własne sesje ($plain/<tożsamość>/<id klienta>, tylko czyste), a własne limity i rejestr dozwolonych nadal go obowiązują.
• Co się traci, jest w SECURITY.md: poufność, integralność, uwierzytelnienie brokera i powtórzenie nagranego logowania. Konfiguracją nie da się tego naprawić; tak jest, gdy nie ma TLS.

Zmierzone na laptopie (Apple silicon, HVF, sieć użytkownika QEMU), 16 par, 64 B, trzy uruchomienia po 10 s: przy 8 000 wiadomości na sekundę ścieżka TLS i zwykła dostarczają wszystkie wiadomości z tym samym opóźnieniem (p50 0,17 ms wobec 0,13 do 0,18 ms), nowe połączenia na sekundę: TLS około 2 600 do 2 750, anonimowy zwykły około 4 900 do 7 800, a logowanie hasłem jest drogą częścią: jeden PBKDF2 kosztuje około 2,5 ms, więc liczba nowych logowań jest ograniczona do około 200 na rdzeń danych na sekundę (zmierzono 308 do 342 na dwóch rdzeniach). Zalewanie na tej maszynie nie jest stabilnym instrumentem (20k do 440k dostarczonych na sekundę między uruchomieniami) i nie wyciągamy z niego wniosku. Porównania zwykłej ścieżki z Mosquitto na VPS-ie jeszcze nie zrobiono. Testy: grupa smoke plaintext 7 z 7 na aarch64 HVF i na x86_64 TCG, nowy cel fuzz plain_input (2,3 miliona uruchomień bez znalezisk).

Błędy znalezione przez pracę na żywo

Dwóch rzeczy nie wyłapały testy, ale pierwsze włączenie na prawdziwej stronie:

• Strona szukała plików wydań o jeden katalog za wysoko, więc każda weryfikacja podpisu odpowiadała 404 (poprawka 13af301). Test używał próbnego lustra pod inną ścieżką.
• Klawiatura emulatora nigdy nie dotarła do gościa: przyczyną nie było złe tłumaczenie klawiszy, tylko to, że okno dialogowe w ogóle nie nasłuchiwało klawiszy (poprawka w ADR-232, wraz z wpisem startowym bez klawiszy).

Lekcje

• Szukaj przyczyny, nie obwiniaj otoczenia. Większość słabości pojedynczego strumienia i wszystkie przerwane połączenia były nasze; hipernadzorca jest prawdziwy, ale trzeba go było mierzyć, a nie zakładać.
• Porównanie z innym produktem musi obejmować także straty. Tabela, w której są tylko nasze wygrane, nie byłaby porównaniem.
• Instrument pomiarowy ma granice. Współdzielony generator ze 60 do 70 % skradzionego czasu zmienia to, co liczby znaczą; dlatego piszemy „dolna granica" i nie twierdzimy różnic poniżej 20 %.
• Izolacja nie jest dowodem. SQLite w EL0 zmniejsza to, co może zrobić błąd w nim, a nie to, co może skłamać.
• Prawdziwa instalacja znajduje to, o co testy nie pytają: źle złożoną ścieżkę i klawisze, których nikt nie nasłuchuje.

Co nadal nie jest udowodnione

• Klucz podpisu wydań jest na razie kluczem próbnym; v0.2.0 i v0.2.1 to pre-release, a obrazy przy nich są deweloperskie z próbnymi certyfikatami (poza szablonem, który jest bez konfiguracji).
• 13 tłumaczeń strony konstruktora (i tego tekstu) napisała AI i sprawdziły je testy i próbki, a nie rodzimi użytkownicy języka.
• Porównanie z Mosquitto to jedna sesja, jedna ścieżka i jeden współdzielony generator, na współdzielonym VPS-ie; różnice poniżej 20 % nie są twierdzeniami.
• Zwykła ścieżka nie była mierzona na VPS-ie ani wobec Mosquitto.
• Lighthouse na nowym prostym widoku nie jest potwierdzony (stary widok: dostępność 95 lub więcej).
• Bare metal, koszt workera na x86_64 na KVM, Firefox i Safari dla emulatora: nie mierzono.

Co dalej

• D1: publiczny broker demo. Emulatora z przeglądarki nie możemy uczynić publicznym: żyje w karcie jednego odwiedzającego, jest 20 do 100 razy wolniejszy od KVM, nie ma sieci przychodzącej i znika po zamknięciu karty; przekierowanie internetu do cudzej przeglądarki byłoby też nadużyciem. Możliwy jest prawdziwy broker demo: urMQTT na VPS-ie pod nazwą na aldo.tech, z opublikowanym próbnym CA, ścisłym ACL i małymi limitami. To na razie tylko pomysł, a nie budowa, i wymaga wyraźnej zgody na publiczne wystawienie.
• Druga runda dla pojedynczego strumienia (gałąź perf-single-flow-wip): dopiero gdy zostanie zmierzona na VPS-ie i scalona.
• Zwykła ścieżka wobec Mosquitto na VPS-ie, logowanie i unieważnianie kont dla zwykłego MQTT przez podpisany kanał zarządzania.
• Po wydaniu: bare metal (X12 do X16), IOMMU i Secure Boot, szyfrowanie dysku.

Kod jest na github.com/zeljan-alduk/urMQTT, a docs/PROGRESS.md nadal jest jedynym źródłem prawdy o tym, co naprawdę działa, docs/PERFORMANCE.md o tym, co zmierzono. Pre-alfa, tak jak wcześniej; zgłoszenia błędów i zgłoszenia dotyczące bezpieczeństwa według wskazówek w SECURITY.md są mile widziane.