Constrained Application Protocol (CoAP)
A CoAP protokoll hasonló a HTTP-hez, de újratervezték, hogy megfeleljen az akkumulátorral működő, korlátozott CPU és RAM erőforrásokkal rendelkező eszközök követelményeinek. A protokoll az UDP / IP-t használja szállítási rétegként. Az eredmény egy sokkal kisebb csomagokat használó, a HTTP-hez képest egyszerűbb és kisebb lábnyomú protokoll (a legkisebb CoAP üzenet 4 bájt, a legkisebb HTTP üzenet 26 bájtjához képest). Ezenkívül a CoAP-ot úgy alakították ki, hogy könnyedén lefordítsa a HTTP-t az egyszerűbb internetes integráció érdekében – a protokollok egyszerű proxykon keresztül működnek együtt. A HTTP-hez hasonlóan a CoAP is kliens / szerver modellen alapul. Az ügyfél kérést küld a szervernek, a szerver pedig visszaküldi a választ. Az ügyfelek erőforrásokat szerezhetnek, helyezhetnek el, posztolhatnak és törölhetnek. Mivel a CoAP az UDP-t használja szállítási rétegként, nincs garancia arra, hogy az ügyfél összes üzenete eléri a szervert. A protokoll kétféle üzenettel valósítja meg a QoS-t és az erőforrásokat: „confirmable” és „non-confirmable”. A „confirmable” típusú üzeneteket a szervernek nyugtázó (ACK) csomaggal kell nyugtáznia. Ha az ügyfél nem kapja meg az ACK-t, akkor ugyanazt az üzenetet küldi újra. A nem megerősíthető üzeneteket egyszerűen „fire and forget” kategóriába sorolják. Ez rugalmasságot biztosít az IoT fejlesztőinek abban, hogy eldöntsék, döntő fontosságú-e, hogy egy adott üzenet eljusson a szerverhez, vagy rendben van, ha hiányzik néhány adat, de megnő az eszköz akkumulátorának élettartama. A különféle NB-IoT hálózatokkal kapcsolatos tapasztalataink alapján az Efento hőmérséklet-érzékelő átlagosan aktív állapotban van (ekkor fogyasztja a legtöbb energiát) 8,5 másodpercig, amikor „confirmable” üzenetet küld, mindössze 2,4 másodperccel, ha a az üzenet „non-confirmable” típusú. Ugyanakkor a „nem visszaigazolható” üzenetek 99,95% -a sikeresen eljut a szerverre.
A CoAP nem használhatja az SSL/TLS-t a kommunikáció biztonságának biztosításához (ehhez a TCP szállítási rétegre van szükség). A kommunikáció biztonságát a Datagram Transport Layer Security (DTLS) szabvány biztosítja, amely UDP-n fut, és magas szintű biztonságot nyújt.
A CoAP egy nyílt protokoll, amelyet az Internet Engineering Task Force korlátozott RESTful Environments munkacsoport szabványosított, és a protokoll magját az RFC 7252 határozza meg.
A CoAP az egyik legnépszerűbb protokoll, amelyet az akkumulátoros IoT eszközök és a vezeték nélküli érzékelők használnak. Jelenleg számos CoAP protokoll-implementáció létezik, számos népszerű programnyelv könyvtárával, köztük Java, Python, C, C++, C#, Ruby, .NET vagy JavaScript.
❞A CoAP egy nyílt, könnyű protokoll, amely akkumulátorral működtetett IoT eszközökhöz készült, és hatékony módon kommunikál a szerverekkel.
Protocol Buffers (Protobuf)
A protokollpufferek (vagy Protobuf) a mikroszolgáltatások, alkalmazások között továbbítható vagy az IoT-eszközök és a szerverek közötti kommunikációban felhasználható adatok sorosítási módszerei. A protokollpufferek ugyanazzal a funkcióval rendelkeznek, mint a jól ismert és széles körben használt JSON és XML. A JSON-hoz és az XML-hez hasonlóan a Protobuf-ek nyelv- és platform-semlegesek. Az adatok sorosításának három módszere között a legfontosabb különbség az, hogy a JSON-tól és az XML-től eltérően a Protobuf-ot úgy optimalizálták, hogy gyors és a lehető legkevesebb hálózati sávszélességet használja azáltal, hogy minimalizálja az átvitt adatok méretét. A protobufok 3–10-szer kisebbek és 20–100-szor gyorsabbak, mint az XML. Így a Protobuf tökéletes választás az akkumulátorral működtetett IoT eszközök által küldött adatok sorosításához.
A Protobuf formátumot a Google hozta létre 2001-ben, azóta szinte a Google gépközi kommunikációjában, valamint mindenféle strukturált információ tárolásában és cseréjében használják. 2008 óta a Protobuf nyilvánosan elérhető.
A Protobuf bináris formátum. Ez megnöveli az adatátvitel sebességét, mert az üzenet kevesebb helyet és hálózati sávszélességet igényel. Ennek a megközelítésnek egyetlen hátránya a JSON-hoz vagy az XML-hez képest, hogy a Protobuf-nal sorosított adatok nem olvashatók emberileg.
A JSON-tól és az XML-től eltérően az adatok és a kontextus el vannak választva a Protobuf-ban. A kontextust a proto fájloknak (.proto) nevezett konfigurációs fájlokban definiálják. Ezek a fájlok mezőneveket tartalmaznak, típusaikkal és azonosítóikkal együtt (pl. String first_name = 1; string vezetéknév = 2;), a Protobuf adatok sorosítási konfigurációs mezők alapján. Tehát a Protbuf adatok a következőket tartalmazzák: mezőazonosító, mezőtípus, értékhossz és érték (124John223Doe). Ennek eredményeként a Protobuf-ban sorosított adatok sokkal kisebbek az XML-hez és a JSON-hoz képest, de mint korábban említettük, egy ember számára nehezebben olvasható. A protofájlokat úgy lehet összeállítani, hogy kódot generáljanak a felhasználó által kiválasztott programozási nyelven – olyan osztályban, amelyben beállítók és getterek vannak a protofájlban definiált összes mező számára. Jelenleg a Google egy kódgenerátort biztosít több nyelv számára, beleértve a C++, C#, Dart, Go, Java és Python nyílt forráskódú licencet.
Ha többet szeretne megtudni a Protobuf-ról, nyissa meg a dokumentációt, és tekintse meg a példákat a Google Protokoll puffer oldalán.
❞ A Protobuf az adatok sorosítására szolgáló módszer, amely kis méretű adatcsomagokat biztosít. A JSON és az XML helyettesítője.
Hogyan használja az Efento a CoAP-ot és a Protobuf-ot?
Az Efento NB-IoT és LTE-M érzékelők az adatokat Protobuf formátumban küldik el a CoAP protokoll segítségével. Ez garantálja a gyors továbbítást és az adatok kis méretét, ami akár 10 éves akkumulátor-üzemidőt is eredményez. Sőt, mivel a CoAP és a Protobuf egyaránt népszerű szabvány, könnyen integrálhatók az Efento vezeték nélküli érzékelők bármely felhőplatformba vagy egyedi alkalmazásba.
