ESP8266 juhtimine ilma pordiedastuseta: MQTT väljuv tee

Seade seisab koduruuteri taga ilma pordiedastuseta ja avaliku aadressita ning peab ikkagi saama konfiguratsiooni sekundite jooksul. Nipp ei ole tulemüüri auk. See on ühendus, mille seade avab väljapoole brokeri poole, kuhu ta pääseb, ja broker annab sõnumid seejärel tagasi sama väljakujunenud teed pidi. Iga omadus, mis selle disaini juures meeldib, ja iga lõks selles, tuleb sellest pööramisest.

Mis tegelikult läbi NAT-i läheb

Kui seade avab brokeriga TCP-ühenduse, loob koduruuter vastenduse ja hoiab seda voolu eluea jooksul elus. Selle voolu vastused naasevad seadmele, sest vastendus on juba olemas. Broker ei algata kunagi midagi maja poole, seega pole soovimatut sissetulevat paketti, mille ruuter saaks tagasi lükata. See on kogu võrguargument ja seetõttu see lähenemine töötab võrkudes, mida te ei kontrolli.

Seade peab ühenduse elus hoidma või selle uuesti looma, millest saab arhitektuuri paikapaneku järel töökindluse küsimus.

Broker marsruudib teemasid, see ei proxy HTTP-d

MQTT määratleb avaldamise ja tellimise vahetused: seade tellib teemafiltri, mida tal on lubatud lugeda, ja volitatud kontroller avaldab sobivasse teemasse. Broker sobitab avaldused tellimustega ja toimetab koopiad kohale. Ta ei tea, mis on brauseri päring, ega edasta HTTP GET-i seadme veebiserverile. Kui olemasolev püsivara räägib ainult HTTP-d, vajab brokeri disain rakenduse muudatust või teadlikku tõlkekomponenti.

Ka teemanimed ei ole autoriseerimine. Enamik brokereid toetab kliendipõhiseid juurdepääsukontrolli loendeid ja seadmeid tuleks piirata nende endi avaldamis- ja tellimispuudega, selle asemel et jagada ühtset globaalset nimeruumi.

Seadme ressursid määravad TLS-i kuju

ESP8266-l on piiratud RAM ja TLS-kätlus on kõige kallim asi, mida see teeb. Arduino tuum tarnib BearSSL-i just selle piirangu tõttu ning valik CA kontrollimise ja sõrmejälje kinnitamise vahel muudab nii mälumahtu kui ka seda, mida vastasele teise nime jaoks kehtiva sertifikaadiga teha saab. Brokeri CA kontrollimine on tugevam valik, kui hunnik seda lubab. Ka kasuliku koormuse suurus loeb: MQTT klient hoiab puhvrit ja sellest suuremad sõnumid kärbitakse vaikselt, kui puhvrit teadlikult ei suurendata.

Keepalive ja soketi ajalõpud on osa samast eelarvest, sest klient, kes ei märka kunagi surnud ühendust, lakkab käske saamast ilma veast teatamata.

Sõnumite semantika, mis hammustab

Säilitatud sõnumi salvestab broker ja toimetab hilisematele sobivatele tellijatele, mis on suurepärane praeguse oleku jaoks ja ohtlik ühekordsete käskude jaoks: uuesti ühenduv seade võib saada eilse käsu nii, nagu oleks see uus. QoS 1 tagab kohaletoimetamise vähemalt korra, seega duplikaadid on normaalsed ja rakendus peab olema korduskindel, ideaalis identifikaatori või ajatempliga, mille see saab tagasi lükata. Viimane tahe annab sulle olekusignaali, kui seade välja kukub, aga ainult siis, kui ühendus tõesti ebaõnnestub, mitte ei ripu.

Puhta sessiooni käitumine otsustab, kas broker hoiab sinu tellimusi, kui oled ära, ja selle vale tegemine on põhjus, miks mõned seadmed jätavad iga taasühenduse järel esimese sõnumi vahele.

TLS kaitseb lõiku brokerini. See ei ole kasuliku koormuse otsast-otsani krüpteerimine brokeri operaatori vastu, kes saab lugeda kõike, mida sa selle kaudu avaldad.

Piira elutsükkel ja testi seda kahjutu andmetega

Planeeri taasühendus tagasihoidmisega, mitte tiheda korduskatse tsükliga, telli uuesti selgesõnaliselt, kui sessioon ei ole püsiv, ja logi ühenduse tulemus, et vaikne võrguühenduseta seade jätaks tõendi. Testi taasühenduse teed näidiskasulike koormustega, mis ei tee midagi, sest käsukanali esimene tootmistest ei tohiks olla päris käsk. Seejärel kinnita, mida vananenud säilitatud sõnum taasühendusel teeb, ja otsusta, kas see käitumine on iga teema jaoks vastuvõetav.

Nii tehtud, eemaldab disain ühe sissetuleva võrgunõude ja jätab seadme tarkvara, brokeri poliitika ja sõnumite semantika nähtava tööna, mitte peidetud eeldustena.