Tækið stendur bak við heimilisrouter án port forwarding og án opinbers vistfangs, og verður samt að fá stillingar innan nokkurra sekúndna. Bragðið er ekki gat á eldveggnum. Það er tenging sem tækið opnar út á við til broker sem það nær í, og sá sendir skilaboðin til baka eftir sama uppbyggða slóð. Sérhver eiginleiki sem fólki líkar við í þessari hönnun, og hver gildra í henni, kemur frá þessari öfugu snúningi.

Hvað fer í raun í gegnum NAT

Þegar tækið opnar TCP-tengingu til brokersins býr heimilisrouterinn til varp og heldur því lifandi meðan flæðið varir. Svör á því flæði koma aftur til tækisins því varpið er þegar til. Brokerinn hefur aldrei frumkvæði að neinu í átt að húsinu, svo það er ekkert óumbeðið innkomandi pakki sem routerinn þarf að hafna. Þetta er öll netrökfræðin, og þess vegna virkar aðferðin á netum sem þú stjórnar ekki.

Tækið verður að halda tengingunni lifandi eða endurreisa hana, sem verður áreiðanleikaspurningin þegar arkitektúrinn er fastur.

Brokerinn beinir þemum, hann milliþjónar ekki HTTP

MQTT skilgreinir skipti á birtingu og áskrift: tækið áskriftar sig að þemasíu sem það má lesa, og heimilað stýritæki birtir á samsvarandi þema. Brokerinn passar birtingar við áskriftir og afhendir eintök. Hann veit ekki hvað beiðni vafra er, og hann mun ekki senda HTTP GET á vefþjón tækisins. Ef núverandi fastbúnaður talar aðeins HTTP þarf brokerhönnunin breytingu á forritinu eða viljandi þýðingarhluta.

Þemanöfn eru heldur ekki heimild. Flestir brokerar styðja aðgangsstýrilista fyrir hvern biðlara, og tæki ættu að vera takmörkuð við eigin birtinga- og áskriftartré í stað þess að deila einu alheimsnagnrými.

Tilföng tækisins ráða lögun TLS

ESP8266 hefur takmarkað RAM, og TLS-handaband er það dýrasta sem það gerir. Arduino-kjarninn sendir BearSSL einmitt vegna þessarar takmörkunar, og valið milli þess að sannreyna CA og festa fingrafar breytir bæði minnisfótspori og því hvað árásarmaður með gilt skírteini fyrir annað nafn getur gert. Að sannreyna CA brokersins er sterkari kosturinn þegar hlaðinn leyfir. Stærð gagnahleðslunnar skiptir líka máli: MQTT-biðlarinn heldur biðminni, og skilaboð sem eru stærri en hann eru klippt hljóðlaust nema biðminnið sé hækkað viljandi.

Keepalive og tímamörk sokkans eru hluti af sama fjárhagsáætlun, því biðlari sem tekur aldrei eftir dauðri tengingu hættir að fá skipanir án þess að tilkynna villu.

Skilaboðamerkingin sem bítur

Varðveitt skilaboð eru geymd af brokerinum og afhent síðari samsvarandi áskrifendum, sem er frábært fyrir núverandi ástand og hættulegt fyrir einnota skipanir: tæki sem tengist aftur getur fengið skipun gærdagsins eins og hún sé ný. QoS 1 tryggir afhendingu að minnsta kosti einu sinni, svo tvítekningar eru eðlilegar og forritið verður að vera öruggt gegn endurtekningu, helst með auðkenni eða tímastimpli sem það getur hafnað. Síðasti vilji gefur þér stöðumerki þegar tækið dettur út, en aðeins ef tengingin mistekst í raun í stað þess að hanga.

Hegðun hreinnar lotu ræður því hvort brokerinn heldur áskriftunum þínum meðan þú ert fjarverandi, og að gera það rangt er ástæðan fyrir því að sum tæki missa fyrstu skilaboðin eftir hverja endurtengingu.

TLS verndar kaflann að brokerinum. Þetta er ekki enda-í-enda dulkóðun gagnahleðslunnar gegn rekstraraðila brokersins, sem getur lesið allt sem þú birtir í gegnum hann.

Afmarkaðu lífsferilinn og prófaðu hann með skaðlausum gögnum

Skipuleggðu endurtengingu með afturhvarfi í stað þéttrar endurtilraunalykkju, áskriftuðu þig skýrt aftur ef lotan er ekki varanleg, og skráðu niðurstöðu tengingarinnar svo hljótt ótengt tæki skilji eftir sig sönnun. Prófaðu endurtengingarslóðina með sýnishornsgagnahleðslum sem gera ekkert, því fyrsta framleiðslupróf skipanarásar ætti ekki að vera raunveruleg skipun. Staðfestu síðan hvað úrelt varðveitt skilaboð gera við endurtengingu, og ákveddu hvort sú hegðun sé ásættanleg fyrir hvert þema.

Svona gert fjarlægir hönnunin eina innkomandi netkröfu og skilur hugbúnað tækisins, stefnu brokersins og skilaboðamerkinguna eftir sem sýnilega vinnu í stað falinna forsendna.

Tengdir greinar