A szoftverek és hardverek területén a technológiák fejlődése, az új kommunikációs protokollok megjelenése a dolgok internete (IoT) terjeszkedéséhez vezetett. Az eszközök száma napról napra nő, és hatalmas mennyiségű adatot generálnak. Ezért szükség van egy kényelmes rendszerarchitektúrára, amely képes ezeket az adatokat feldolgozni, tárolni és továbbítani.
Jelenleg felhőszolgáltatásokat használnak erre a célra. Az egyre népszerűbb ködszámítási paradigma (Fog) azonban kiegészítheti a felhőmegoldásokat az IoT-infrastruktúra méretezésével és optimalizálásával.
A felhők képesek lefedni a legtöbb IoT-kérést. Például a szolgáltatások monitorozására, az eszközök által generált bármilyen mennyiségű adat gyors feldolgozására, valamint azok vizualizálására. A ködszámítás hatékonyabb a valós idejű problémák megoldásában. Gyors választ adnak a kérésekre és minimális késleltetést biztosítanak az adatfeldolgozás során. Vagyis a Köd kiegészíti a „felhőket”, bővíti képességeit.
A fő kérdés azonban más: hogyan kell mindez kölcsönhatásba lépnie az IoT kontextusában? Milyen kommunikációs protokollok lesznek a leghatékonyabbak, ha kombinált IoT-Fog-Cloud rendszerben dolgozik?
A HTTP látszólagos dominanciája ellenére számos egyéb megoldást is használnak az IoT, Fog és Cloud rendszerekben. Ennek az az oka, hogy az IoT-nek egyesítenie kell a különféle eszközérzékelők funkcionalitását a felhasználók biztonsági, kompatibilitási és egyéb követelményeivel.
De egyszerűen nincs egyetlen elképzelés a referencia architektúráról és kommunikációs szabványról. Ezért egy új protokoll létrehozása vagy egy meglévő módosítása adott IoT-feladatokhoz az egyik legfontosabb feladat az informatikai közösség előtt.
Milyen protokollok vannak jelenleg használatban, és mit kínálnak? Találjuk ki. De először beszéljük meg annak az ökoszisztémának az alapelveit, amelyben a felhők, a köd és a dolgok internete kölcsönhatásba lépnek.
IoT Fog-to-Cloud (F2C) architektúra
Valószínűleg észrevette már, hogy mennyi erőfeszítést fektetnek az IoT, a felhő és a köd intelligens és összehangolt kezelésével kapcsolatos előnyök és előnyök feltárására. Ha nem, akkor itt van három szabványosítási kezdeményezés: , и .
Ha korábban csak 2 szintet vettek figyelembe, a felhőket és a végeszközöket, akkor a javasolt architektúra egy új szintet vezet be - a ködszámítást. Ebben az esetben a ködszint több alszintre osztható, az erőforrások sajátosságaitól vagy a házirendek halmazától függően, amelyek meghatározzák a különböző eszközök használatát ezeken az alszinteken.
Hogyan nézhet ki ez az absztrakció? Itt van egy tipikus IoT-Fog-Cloud ökoszisztéma. Az IoT-eszközök gyorsabb szerverekre és számítástechnikai eszközökre küldenek adatokat, hogy megoldják az alacsony késleltetést igénylő problémákat. Ugyanebben a rendszerben a felhők felelősek a nagy mennyiségű számítási erőforrást vagy adattárhelyet igénylő problémák megoldásáért.
Okostelefonok, okosórák és egyéb kütyük is részei lehetnek az IoT-nek. De az ilyen eszközök általában a nagy fejlesztők szabadalmaztatott kommunikációs protokolljait használják. A generált IoT-adatok a REST HTTP protokollon keresztül kerülnek a ködrétegbe, amely rugalmasságot és interoperabilitást biztosít a RESTful szolgáltatások létrehozásakor. Ez azért fontos, mert visszafelé kompatibilitást kell biztosítani a helyi számítógépeken, szervereken vagy szerverfürtökön futó meglévő számítási infrastruktúrával. A helyi erőforrások, az úgynevezett „ködcsomópontok”, kiszűrik a kapott adatokat, és helyileg feldolgozzák, vagy elküldik a felhőbe további számítások céljából.
A felhők különböző kommunikációs protokollokat támogatnak, a leggyakoribb az AMQP és a REST HTTP. Mivel a HTTP jól ismert és az internetre szabott, felmerülhet a kérdés: „Nem kellene használni az IoT és a köd kezelésére?” Ennek a protokollnak azonban teljesítménybeli problémái vannak. Erről később.
Általánosságban elmondható, hogy a szükséges rendszerhez 2 kommunikációs protokollmodell létezik. Ezek a kérés-válasz és a közzététel-előfizetés. Az első modell szélesebb körben ismert, különösen a szerver-kliens architektúrában. A kliens információkat kér a szervertől, a szerver pedig fogadja a kérést, feldolgozza és válaszüzenetet küld vissza. A REST HTTP és CoAP protokollok ezen a modellen működnek.
A második modell aszinkron, elosztott, laza csatolás szükségességéből adódott az adatokat generáló források és az adatok címzettjei között.
A modell három résztvevőt feltételez: egy kiadót (adatforrás), egy közvetítőt (diszpécser) és egy előfizetőt (vevő). Itt az előfizetőként működő kliensnek nem kell információt kérnie a szervertől. A kérések elküldése helyett a rendszer bizonyos eseményeire egy brókeren keresztül iratkozik fel, amely az összes bejövő üzenet szűréséért és a kiadók és előfizetők közötti továbbításáért felelős. A kiadó pedig, ha egy adott témával kapcsolatban esemény történik, közzéteszi azt a brókernek, aki a kért témában adatokat küld az előfizetőnek.
Ez az architektúra lényegében eseményalapú. Ez az interakciós modell pedig érdekes az IoT-ben, felhőben és ködben, mivel képes skálázhatóságot biztosítani és egyszerűsíteni a különböző eszközök közötti összekapcsolást, támogatja a dinamikus sok-több kommunikációt és az aszinkron kommunikációt. A közzététel-előfizetés modellt használó legismertebb szabványosított üzenetküldési protokollok közé tartozik az MQTT, az AMQP és a DDS.
Nyilvánvaló, hogy a közzététel-előfizetés modellnek számos előnye van:
- A kiadóknak és az előfizetőknek nem kell tudniuk egymás létezéséről;
- Egy előfizető sok különböző kiadványból kaphat információt, egy kiadó pedig sok különböző előfizetőnek küldhet el adatokat (sok a sokhoz elv);
- A kiadónak és az előfizetőnek nem kell egyszerre aktívnak lennie a kommunikációhoz, mert a közvetítő (sorozó rendszerként) képes lesz tárolni az üzenetet azon ügyfelek számára, akik jelenleg nem kapcsolódnak a hálózathoz.
A kérés-válasz modellnek azonban megvannak az erősségei is. Azokban az esetekben, amikor a szerveroldal több kliens kérés kezelésére való képessége nem probléma, érdemes bevált, megbízható megoldásokat használni.
Vannak olyan protokollok is, amelyek mindkét modellt támogatják. Például az XMPP és a HTTP 2.0, amelyek támogatják a „server push” opciót. Az IETF CoAP-ot is kiadott. Az üzenetkezelési probléma megoldására számos más megoldás született, például a WebSockets protokoll vagy a HTTP protokoll használata QUIC-on (Quick UDP Internet Connections) keresztül.
A WebSockets esetében, bár valós idejű adatok átvitelére szolgál a szerverről a webes kliensre, és állandó kapcsolatokat biztosít egyidejű kétirányú kommunikációval, nem a korlátozott számítási erőforrásokkal rendelkező eszközökhöz készült. A QUIC is figyelmet érdemel, hiszen az új szállítási protokoll rengeteg új lehetőséget kínál. De mivel a QUIC még nincs szabványosítva, még korai lenne megjósolni annak lehetséges alkalmazását és az IoT-megoldásokra gyakorolt hatását. A WebSockets és a QUIC tehát a jövőt szem előtt tartva tartjuk szem előtt, de egyelőre nem foglalkozunk vele részletesebben.
Ki a legaranyosabb a világon: protokollok összehasonlítása
Most beszéljünk a protokollok erősségeiről és gyengeségeiről. A jövőre nézve azonnal tegyünk egy fenntartást, hogy nincs egyértelmű vezető. Mindegyik protokollnak vannak előnyei/hátrányai.
Válaszidő
A kommunikációs protokollok egyik legfontosabb jellemzője, különösen az Internet of Things kapcsán, a válaszidő. A meglévő protokollok között azonban nincs egyértelmű győztes, amely bemutatná a minimális késleltetési szintet különböző körülmények között végzett munka során. De van egy csomó kutatás és összehasonlítás a protokollképességekkel kapcsolatban.
Például a HTTP és az MQTT hatékonyságának összehasonlítása az IoT-vel végzett munka során azt mutatta, hogy az MQTT-kérések válaszideje rövidebb, mint a HTTP-ké. És mikor Az MQTT és a CoAP oda-vissza úti ideje (RTT) azt mutatta, hogy a CoAP átlagos RTT-je 20%-kal kevesebb, mint az MQTT-é.
más RTT-vel az MQTT és a CoAP protokollok esetében két forgatókönyv szerint történt: helyi hálózat és IoT hálózat. Kiderült, hogy az átlagos RTT 2-3-szor magasabb egy IoT-hálózatban. Az MQTT a QoS0-val alacsonyabb eredményt mutatott a CoAP-hoz képest, az MQTT pedig a QoS1-vel magasabb RTT-t mutatott az alkalmazási és szállítási rétegek ACK-jei miatt. Különböző QoS szintek esetén a hálózati késleltetés torlódás nélkül ezredmásodperc volt az MQTT esetében, és több száz mikroszekundum a CoAP esetében. Nem szabad azonban elfelejteni, hogy ha kevésbé megbízható hálózatokon dolgozik, a TCP-n futó MQTT teljesen más eredményt fog mutatni.
Az AMQP és MQTT protokollok válaszideje a hasznos terhelés növelésével azt mutatta, hogy enyhe terhelés mellett a késleltetési szint közel azonos. De nagy mennyiségű adat átvitelekor az MQTT rövidebb válaszidőt mutat. még egyben A CoAP-ot a HTTP-vel hasonlították össze egy gépek közötti kommunikációs forgatókönyvben, ahol az eszközöket gázérzékelőkkel, időjárás-érzékelőkkel, helyérzékelőkkel (GPS) és mobil hálózati interfésszel (GPRS) felszerelt járművek tetején helyezték el. A CoAP-üzenet mobilhálózaton keresztüli továbbításához szükséges idő csaknem háromszor rövidebb volt, mint a HTTP-üzenetek használatához szükséges idő.
Olyan tanulmányokat végeztek, amelyek nem két, hanem három protokollt hasonlítottak össze. Például, Az MQTT, DDS és CoAP IoT-protokollok teljesítménye egészségügyi alkalmazási forgatókönyvben hálózati emulátor használatával. A DDS a tesztelt telemetriai késleltetést tekintve felülmúlta az MQTT-t különféle rossz hálózati körülmények között. Az UDP-alapú CoAP jól működött a gyors válaszidőt igénylő alkalmazásoknál, azonban UDP-alapúsága miatt jelentős, előre nem látható csomagvesztés következett be.
kapacitás
Az üzenetenként továbbított teljes adatmennyiség számításaként az MQTT-t és a CoAP-ot a sávszélesség-hatékonyság szempontjából végeztük. A CoAP kisebb átviteli sebességet mutatott, mint az MQTT kis üzenetek továbbításakor. De amikor összehasonlítjuk a protokollok hatékonyságát a hasznos információ bájtok számának és az összes átvitt bájtok számának arányában, a CoAP hatékonyabbnak bizonyult.
-On Az MQTT, a DDS (a szállítási protokollként TCP-vel) és a CoAP sávszélességet használva azt találták, hogy a CoAP általában viszonylag alacsonyabb sávszélesség-fogyasztást mutatott, ami nem nőtt a megnövekedett hálózati csomagvesztés vagy a hálózati késleltetés növekedésével, ellentétben az MQTT-vel és a DDS-sel, ahol volt a sávszélesség-kihasználás növekedése az említett forgatókönyvekben. Egy másik forgatókönyv az IoT-környezetekre jellemző módon nagyszámú eszközt tartalmazott egyidejűleg adatokat továbbító. Az eredmények azt mutatták, hogy a magasabb kihasználtság érdekében jobb a CoAP használata.
Kis terhelés mellett a CoAP használta a legkisebb sávszélességet, ezt követte az MQTT és a REST HTTP. Amikor azonban a hasznos terhek mérete nőtt, a REST HTTP érte el a legjobb eredményeket.
Teljesítményfelvétel
Az energiafogyasztás kérdése mindig nagy jelentőséggel bír, különösen az IoT rendszerében. Ha Míg az MQTT és a HTTP áramot fogyaszt, a HTTP sokkal többet fogyaszt. A CoAP pedig több az MQTT-hez képest, lehetővé téve az energiagazdálkodást. Egyszerű forgatókönyvek esetén azonban az MQTT alkalmasabb információcserére a Dolgok Internete hálózatokban, különösen, ha nincsenek teljesítménykorlátozások.
Egy kísérlet, amely összehasonlította az AMQP és az MQTT képességeit mobil vagy instabil vezeték nélküli hálózaton, azt találta, hogy az AMQP több biztonsági lehetőséget kínál, míg az MQTT energiahatékonyabb.
biztonság
A biztonság egy másik kritikus kérdés, amely a tárgyak internete és a köd-/felhőalapú számítástechnika tanulmányozása során felmerül. A biztonsági mechanizmus általában a HTTP-ben, az MQTT-ben, az AMQP-ben és az XMPP-ben a TLS-en, a CoAP-ban pedig a DTLS-en alapul, és mindkét DDS-változatot támogatja.
A TLS és a DTLS a kliens és a kiszolgáló közötti kommunikáció létrehozásával kezdődik a támogatott rejtjelkészletek és kulcsok cseréje érdekében. Mindkét fél megtárgyalja a készleteket annak érdekében, hogy a további kommunikáció biztonságos csatornán történjen. A kettő közötti különbség a kis módosításokban rejlik, amelyek lehetővé teszik, hogy az UDP-alapú DTLS megbízhatatlan kapcsolaton keresztül működjön.
-On A TLS és a DTLS számos különböző megvalósítása azt találta, hogy a TLS jobb munkát végzett. A DTLS elleni támadások sikeresebbek voltak a hibatűrő képessége miatt.
A legnagyobb probléma azonban ezekkel a protokollokkal az, hogy eredetileg nem az IoT-ben való használatra készültek, és nem ködben vagy felhőben való működésre szánták őket. A kézfogás révén további forgalmat adnak hozzá minden egyes kapcsolat létrehozásához, ami lemeríti a számítási erőforrásokat. Átlagosan 6,5%-os növekedés tapasztalható a TLS és 11%-os a DTLS esetében a biztonsági réteg nélküli kommunikációhoz képest. Erőforrásokban gazdag környezetekben, amelyek jellemzően a szinten ez nem lesz probléma, de az IoT és a ködszint kapcsolatában ez fontos korláttá válik.
Mit válasszunk? Nincs egyértelmű válasz. Az MQTT és a HTTP tűnnek a legígéretesebb protokolloknak, mivel más protokollokhoz képest viszonylag kiforrottabb és stabilabb IoT-megoldásoknak tekinthetők.
Egységes kommunikációs protokollon alapuló megoldások
Az egyprotokollos megoldás gyakorlatának számos hátránya van. Előfordulhat például, hogy egy korlátozott környezetnek megfelelő protokoll nem működik szigorú biztonsági követelményekkel rendelkező tartományban. Ezt szem előtt tartva, az MQTT és a REST HTTP kivételével el kell vetnünk az IoT Fog-to-Cloud ökoszisztémájának szinte minden lehetséges egyprotokollos megoldását.
A REST HTTP egy protokollos megoldásként
Van egy jó példa arra, hogy a REST HTTP kérések és válaszok hogyan hatnak egymásra az IoT-to-Fog térben: . Az állatok hordható szenzorokkal (IoT-kliens, C) vannak felszerelve, és felhőalapú számítástechnikával vezérlik őket egy intelligens tenyésztési rendszer (Fog server, S).
A POST metódus fejléce határozza meg a módosítani kívánt erőforrást (/farm/animals), valamint a HTTP verziót és a tartalom típusát, amely ebben az esetben egy JSON-objektum, amely azt az állatfarmot képviseli, amelyet a rendszer kezel (Dulcinea/cow) . A kiszolgáló válasza azt jelzi, hogy a kérés sikeres volt a 201-es HTTPS-állapotkód elküldésével (erőforrás létrehozva). A GET metódusnak csak a kért erőforrást kell megadnia az URI-ban (például /farm/animals/1), amely az adott azonosítóval rendelkező állat JSON-ábrázolását adja vissza a szervertől.
A PUT metódus akkor használatos, ha egy adott erőforrásrekordot frissíteni kell. Ebben az esetben az erőforrás megadja a módosítandó paraméter URI-jét és az aktuális értéket (például jelzi, hogy a tehén éppen sétál, /farm/állatok/1? állapot=járás). Végül a DELETE metódus ugyanúgy használatos, mint a GET, de egyszerűen törli az erőforrást a művelet eredményeként.
Az MQTT egy protokollos megoldásként
Vegyük ugyanazt az intelligens farmot, de a REST HTTP helyett az MQTT protokollt használjuk. A Mosquitto könyvtárral rendelkező helyi szerver közvetítőként működik. Ebben a példában egy egyszerű számítógép (a továbbiakban farmszerverként) Raspberry Pi szolgál MQTT-kliensként, amelyet a Mosquitto brókerrel teljes mértékben kompatibilis Paho MQTT könyvtár telepítésével valósítanak meg.
Ez a kliens egy IoT absztrakciós rétegnek felel meg, amely érzékelési és számítási képességekkel rendelkező eszközt képvisel. A közvetítő ezzel szemben magasabb absztrakciós szintnek felel meg, ami egy nagyobb feldolgozási és tárolási kapacitással jellemezhető ködszámítási csomópontot jelent.
A javasolt intelligens farm forgatókönyv szerint a Raspberry Pi csatlakozik a gyorsulásmérőhöz, a GPS-hez és a hőmérséklet-érzékelőhöz, és közzéteszi az érzékelők adatait egy ködcsomóponthoz. Mint bizonyára tudja, az MQTT a témákat hierarchiaként kezeli. Egyetlen MQTT-megjelenítő üzeneteket tehet közzé egy adott témakörhöz. A mi esetünkben három van belőlük. Az állati istálló hőmérsékletét mérő érzékelőhöz az ügyfél kiválaszt egy témát (állatfarm/istálló/hőmérséklet). Azon érzékelők esetében, amelyek a gyorsulásmérőn keresztül mérik a GPS-helyzetet és az állatok mozgását, a kliens frissítéseket tesz közzé az (állatfarm/állat/GPS) és (állatfarm/állat/mozgás) értékekre.
Ezt az információt a bróker kapja meg, aki ideiglenesen el tudja tárolni egy helyi adatbázisban, ha később újabb érdeklődő előfizető érkezik.
A ködben MQTT brókerként működő helyi szerveren kívül, amelyhez az MQTT kliensként működő Raspberry Pis küldi a szenzoradatokat, egy másik MQTT bróker is lehet felhő szinten. Ebben az esetben a helyi brókernek továbbított információ ideiglenesen tárolható egy helyi adatbázisban és/vagy elküldhető a felhőbe. A köd MQTT bróker ebben a helyzetben az összes adatot a felhő MQTT brókerrel társítja. Ezzel az architektúrával a mobilalkalmazás-felhasználók mindkét brókerre előfizethetők.
Ha a kapcsolat az egyik brókerrel (például felhő) meghiúsul, a végfelhasználó információt kap a másiktól (köd). Ez a kombinált köd- és felhőalapú számítástechnikai rendszerek jellemző tulajdonsága. Alapértelmezés szerint a mobilalkalmazás úgy konfigurálható, hogy először csatlakozzon a köd MQTT brókerhez, és ha ez nem sikerül, csatlakozzon a felhő MQTT brókerhez. Ez a megoldás csak egy a sok közül az IoT-F2C rendszerekben.
Több protokollos megoldások
Az egyprotokollos megoldások egyszerűbb megvalósításuk miatt népszerűek. Nyilvánvaló azonban, hogy az IoT-F2C rendszerekben ésszerű kombinálni a különböző protokollokat. Az ötlet az, hogy a különböző protokollok különböző szinteken működhetnek. Vegyünk például három absztrakciót: az IoT rétegeit, a ködöt és a felhőalapú számítástechnikát. Az IoT-szintű eszközöket általában korlátozottnak tekintik. Ehhez az áttekintéshez tekintsük az IoT-szinteket a legkorlátozottabbnak, a felhőt a legkevésbé korlátozónak, a köd-számítástechnikát pedig a „valahol a közepén”. Ekkor kiderül, hogy az IoT és a köd absztrakciók között a jelenlegi protokollmegoldások közé tartozik az MQTT, a CoAP és az XMPP. A köd és a felhő között viszont az AMQP az egyik fő használt protokoll, a REST HTTP mellett, amely rugalmassága miatt az IoT és a köd rétegek között is használatos.
A fő probléma itt a protokollok interoperabilitása és az üzenetek egyszerű átvitele egyik protokollról a másikra. Ideális esetben a jövőben a felhő- és köd-erőforrásokkal rendelkező Dolgok Internete rendszer architektúrája független lesz az alkalmazott kommunikációs protokolltól, és jó interoperabilitást biztosít a különböző protokollok között.
Mivel ez jelenleg nem így van, célszerű olyan protokollokat kombinálni, amelyekben nincs jelentős különbség. Ennek érdekében az egyik lehetséges megoldás két protokoll kombinációján alapul, amelyek ugyanazt az építészeti stílust követik, a REST HTTP és a CoAP. Egy másik javasolt megoldás két közzétételi-előfizetési kommunikációt kínáló protokoll, az MQTT és az AMQP kombinációján alapul. A hasonló koncepciók használata (mind az MQTT, mind az AMQP brókereket használ, a CoAP és a HTTP a REST-et használja) megkönnyíti ezeknek a kombinációknak a megvalósítását, és kevesebb integrációs erőfeszítést igényel.
Az (a) ábra két kérés-válasz alapú modellt, a HTTP-t és a CoAP-t mutatja be, valamint ezek lehetséges elhelyezését egy IoT-F2C megoldásban. Mivel a HTTP az egyik legismertebb és legelfogadottabb protokoll a modern hálózatokon, nem valószínű, hogy teljesen felváltják más üzenetküldési protokollok. A felhő és a köd között elhelyezkedő, nagy teljesítményű eszközöket képviselő csomópontok közül a REST HTTP egy intelligens megoldás.
Másrészt a Fog és az IoT rétegek között kommunikáló, korlátozott számítási erőforrásokkal rendelkező eszközök esetében hatékonyabb a CoAP használata. A CoAP egyik nagy előnye tulajdonképpen a HTTP-vel való kompatibilitása, mivel mindkét protokoll REST elven alapul.
A (b) ábra két közzététel-előfizetés kommunikációs modellt mutat be ugyanabban a forgatókönyvben, beleértve az MQTT-t és az AMQP-t. Bár elméletileg mindkét protokoll használható a csomópontok közötti kommunikációra az egyes absztrakciós rétegeken, helyzetüket a teljesítmény alapján kell meghatározni. Az MQTT-t könnyű protokollnak tervezték korlátozott számítási erőforrásokkal rendelkező eszközökhöz, így IoT-Fog kommunikációra is használható. Az AMQP jobban megfelel az erősebb eszközökhöz, amelyek ideálisan a köd és a felhő csomópontok közé helyezik el. Az MQTT helyett az XMPP protokoll használható az IoT-ben, mivel könnyűnek tekinthető. De nem olyan széles körben használják ilyen forgatókönyvekben.
Álláspontja
Nem valószínű, hogy a tárgyalt protokollok egyike elegendő lesz a rendszer összes kommunikációjának lefedésére, a korlátozott számítási erőforrásokkal rendelkező eszközöktől a felhőszerverekig. A tanulmány megállapította, hogy a fejlesztők által leginkább használt két legígéretesebb lehetőség az MQTT és a RESTful HTTP. Ez a két protokoll nemcsak a legérettebb és legstabilabb, hanem számos jól dokumentált és sikeres megvalósítást és online forrást is tartalmaz.
Stabilitása és egyszerű konfigurációja miatt az MQTT egy olyan protokoll, amely idővel bizonyította kiváló teljesítményét IoT-szinten korlátozott eszközökkel. A rendszer azon részein, ahol a korlátozott kommunikáció és az akkumulátorfogyasztás nem jelent problémát, például egyes ködtartományok és a legtöbb felhőalapú számítástechnika, a RESTful HTTP egyszerű választás. A CoAP-ot is figyelembe kell venni, mivel az IoT üzenetküldési szabványként is gyorsan fejlődik, és valószínű, hogy a közeljövőben eléri az MQTT-hez és a HTTP-hez hasonló stabilitási és érettségi szintet. A szabvány azonban jelenleg fejlesztés alatt áll, ami rövid távú kompatibilitási problémákkal jár.
Mit olvashatsz még a blogon?
→
→
→
→
→
Iratkozzon fel a -csatorna, hogy ne maradj le a következő cikkről! Hetente legfeljebb kétszer írunk, és csak üzleti ügyben.
Forrás: will.com