Softwarearen eta hardwarearen alorreko teknologien garapenak, komunikazio-protokolo berrien sorrerak Gauzen Internet (IoT) hedatzea ekarri du. Gailu kopurua hazten ari da egunetik egunera eta datu kopuru handia sortzen ari dira. Horregatik, datu horiek prozesatu, gorde eta transmititzeko gai den sistema-arkitektura eroso baten beharra dago.
Orain hodeiko zerbitzuak erabiltzen dira helburu horietarako. Hala ere, gero eta ezagunagoa den fog computing paradigma (Fog) hodeiko irtenbideak osa ditzake IoT azpiegitura eskalatu eta optimizatuz.
Hodeiak IoT eskaera gehienak estaltzeko gai dira. Esaterako, zerbitzuen jarraipena eskaintzeko, gailuek sortutako edozein datu-kopuru azkar prozesatzeko, baita haien bistaratzea ere. Lainoaren konputazioa eraginkorragoa da denbora errealeko arazoak konpontzeko. Eskaerei erantzun azkarra ematen diete eta datuen tratamenduan latentzia minimoa ematen dute. Hau da, Lainoak "hodeiak" osatzen ditu eta bere gaitasunak zabaltzen ditu.
Hala ere, galdera nagusia bestelakoa da: nola eragin beharko luke horrek guztiak IoT-ren testuinguruan? Zein komunikazio-protokolo izango dira eraginkorrenak IoT-Fog-Cloud sistema konbinatu batean lan egitean?
HTTPren itxurazko nagusitasuna izan arren, IoT, Fog eta Cloud sistemetan erabiltzen diren beste irtenbide ugari daude. Hau da, IoT-ek hainbat gailu sentsoreren funtzionaltasuna konbinatu behar duelako erabiltzaileen segurtasun, bateragarritasun eta bestelako eskakizunekin.
Baina ez dago erreferentziako arkitektura eta komunikazio estandarrari buruzko ideia bakarra. Hori dela eta, IoT zeregin zehatzetarako protokolo berri bat sortzea edo lehendik dagoen bat aldatzea IT komunitateak duen zeregin garrantzitsuenetako bat da.
Zein protokolo erabiltzen ari dira gaur egun eta zer eskaini dezakete? Asma dezagun. Baina lehenik eta behin, eztabaida ditzagun hodeiak, lainoak eta gauzen Internetek elkarreragiten duten ekosistemaren printzipioak.
IoT Fog-to-Cloud (F2C) arkitektura
Ziurrenik ohartu zara zenbat ahalegin egiten den IoT, hodeia eta lainoaren kudeaketa adimendun eta koordinatuarekin lotutako abantailak eta onurak aztertzeko. Hala ez bada, hona hemen hiru estandarizazio ekimen: , ΠΈ .
Aurretik 2 maila bakarrik kontuan hartzen baziren, hodeiak eta amaierako gailuak, orduan proposatutako arkitekturak maila berri bat sartzen du: lainoaren konputazioa. Kasu honetan, laino-maila hainbat azpimailatan bana daiteke, baliabideen berezitasunen edo azpimaila horietan gailu ezberdinen erabilera zehazten duten politika multzo baten arabera.
Nolakoa izan daiteke abstrakzio hau? Hona hemen IoT-Fog-Cloud ekosistema tipiko bat. IoT gailuek datuak zerbitzari eta gailu informatiko azkarragoetara bidaltzen dituzte, latentzia txikia behar duten arazoak konpontzeko. Sistema berean, hodeiak arduratzen dira informatika-baliabide edo datuak gordetzeko espazio handia behar duten arazoak konpontzeko.
Smartphones, erloju adimendunak eta bestelako tramankuluak ere izan daitezke IoT-aren parte. Baina horrelako gailuek, oro har, garatzaile handien jabedun komunikazio-protokoloak erabiltzen dituzte. Sortutako IoT datuak laino geruzara transferitzen dira REST HTTP protokoloaren bidez, eta horrek malgutasuna eta elkarreragingarritasuna eskaintzen ditu RESTful zerbitzuak sortzerakoan. Hau garrantzitsua da tokiko ordenagailuetan, zerbitzarietan edo zerbitzari-kluster batean exekutatzen den lehendik dagoen konputazio-azpiegiturekin atzerako bateragarritasuna bermatu beharra dagoelako. Tokiko baliabideek, "laino nodoak" izenekoak, jasotako datuak iragazten dituzte eta lokalean prozesatzen dituzte edo hodeira bidaltzen dituzte kalkulu gehiago egiteko.
Hodeiek komunikazio-protokolo desberdinak onartzen dituzte, ohikoenak AMQP eta REST HTTP dira. HTTP ezaguna eta Interneterako egokituta dagoenez, galdera sor daiteke: "Ez al dugu erabili behar IoT eta lainoarekin lan egiteko?" Hala ere, protokolo honek errendimendu arazoak ditu. Honi buruz gehiago.
Oro har, behar dugun sistemarako egokiak diren komunikazio-protokoloen 2 eredu daude. Hauek eskaera-erantzuna eta argitaratu-harpidetza dira. Lehen eredua ezagunagoa da, batez ere zerbitzari-bezero arkitekturan. Bezeroak zerbitzariari informazioa eskatzen dio, eta zerbitzariak eskaera jaso, prozesatu eta erantzun mezu bat itzultzen du. REST HTTP eta CoAP protokoloek eredu honetan funtzionatzen dute.
Bigarren eredua datuak sortzen dituzten iturrien eta datu horien hartzaileen arteko akoplamendu asinkrono, banatu eta soltearen beharratik sortu zen.
Ereduak hiru parte-hartzaile hartzen ditu: argitaratzailea (datuen iturria), bitartekari bat (bidaltzailea) eta harpideduna (hartzailea). Hemen, harpidedun gisa jarduten duen bezeroak ez du zerbitzariari informaziorik eskatu behar. Eskaerak bidali beharrean, sistemako gertaera jakin batzuetara harpidetzen da bitartekari baten bidez, hau da, sarrerako mezu guztiak iragazteaz eta argitaratzaileen eta harpidedunen artean bideratzeaz arduratzen dena. Eta argitaletxeak, gai jakin bati buruzko gertaera bat gertatzen denean, bitartekariari argitaratzen dio, harpidedunari eskatutako gaiari buruzko datuak bidaltzen dizkio.
Funtsean, arkitektura hau gertaeretan oinarritzen da. Eta interakzio-eredu hau interesgarria da IoT, hodeian, lainoko aplikazioetarako, eskalagarritasuna eskaintzeko eta gailu ezberdinen arteko interkonexioa errazteko, askoren arteko komunikazio dinamikoa eta komunikazio asinkronoa onartzen duelako. Argitalpen-harpidetza eredua erabiltzen duten mezularitza-protokolo estandarizatu ezagunenetako batzuk MQTT, AMQP eta DDS dira.
Jakina, argitaratze-harpidetza ereduak abantaila asko ditu:
- Argitaletxeek eta harpidedunek ez dute elkarren existentziaz jakin behar;
- Harpidedun batek argitalpen ezberdin askotatik informazioa jaso dezake, eta argitaletxe batek harpidedun ezberdin askori datuak bidal diezazkieke (askoren printzipioa);
- Argitaletxeak eta harpidedunak ez dira aldi berean aktibo egon behar komunikatzeko, broker-ak (ilara-sistema gisa lan egiten du) mezua gordetzeko aukera izango baitu une honetan sarera konektatuta ez dauden bezeroentzat.
Hala ere, eskaera-erantzun ereduak ere baditu bere indarguneak. Zerbitzariaren aldean hainbat bezero-eskaera kudeatzeko gaitasuna arazo bat ez den kasuetan, zentzuzkoa da irtenbide frogatuak eta fidagarriak erabiltzea.
Bi ereduak onartzen dituzten protokoloak ere badaude. Adibidez, XMPP eta HTTP 2.0, "zerbitzariaren push" aukera onartzen dutenak. IETFk CoAP bat ere kaleratu du. Mezularitzaren arazoa konpondu nahian, beste hainbat irtenbide sortu dira, hala nola, WebSockets protokoloa edo HTTP protokoloa QUIC bidez (Quick UDP Internet Connections) erabiltzea.
WebSockets-en kasuan, nahiz eta zerbitzari batetik web-bezero batera datuak denbora errealean transferitzeko erabiltzen den eta aldibereko noranzko biko komunikazioarekin konexio iraunkorrak eskaintzen dituen arren, ez dago baliabide informatiko mugatuak dituzten gailuetarako pentsatuta. QUIC-ek ere arreta merezi du, garraio-protokolo berriak aukera berri asko ematen baititu. Baina QUIC oraindik estandarizatuta ez dagoenez, goiztiarra da IoT soluzioetan izan dezakeen aplikazioa eta eragina aurreikustea. Beraz, WebSockets eta QUIC kontuan izaten ditugu etorkizunari begira, baina oraingoz ez dugu zehatzago aztertuko.
Zein da munduko politena: protokoloak alderatuz
Orain hitz egin dezagun protokoloen indargune eta ahuleziaz. Aurrera begira, berehala egin dezagun erreserba bat ez dagoela buruzagi argirik. Protokolo bakoitzak abantaila/desabantaila batzuk ditu.
Erantzun denbora
Komunikazio-protokoloen ezaugarri garrantzitsuenetako bat, batez ere Gauzen Internetari dagokionez, erantzun denbora da. Baina dauden protokoloen artean, ez dago baldintza ezberdinetan lan egitean gutxieneko latentzia-maila erakusten duen irabazle argirik. Baina protokoloen gaitasunen ikerketa eta konparaketa mordoa dago.
Esate baterako, HTTP eta MQTT-ren eraginkortasunaren konparaketak IoT-ekin lan egitean erakutsi zuen MQTT-ren eskaeren erantzun-denbora HTTP-rena baino txikiagoa dela. Eta noiz MQTT eta CoAPen joan-etorriko denborak (RTT) CoAPen batez besteko RTT MQTTarena baino %20 txikiagoa dela agerian utzi zuen.
beste RTTrekin MQTT eta CoAP protokoloetarako bi eszenatokitan gauzatu zen: sare lokala eta IoT sarea. Kontuan izan da batez besteko RTT 2-3 aldiz handiagoa dela IoT sare batean. QoS0-rekin MQTT-k emaitza txikiagoa erakutsi zuen CoAParekin alderatuta, eta QoS1-ekin MQTT-k RTT handiagoa erakutsi zuen aplikazio eta garraio geruzetako ACKen ondorioz. QoS maila desberdinetarako, sareko latentzia pilaketarik gabeko milisegundokoa izan zen MQTTrentzat, eta ehunka mikrosegundokoa CoAPrentzat. Hala ere, merezi du gogoratzea fidagarritasun gutxiagoko sareetan lan egiten denean, MQTT TCPren gainean exekutatzen den emaitza guztiz desberdina erakutsiko duela.
AMQP eta MQTT protokoloen erantzun denborak karga handituz erakutsi zuen karga arin batekin latentzia maila ia berdina dela. Baina datu kopuru handiak transferitzean, MQTT-k erantzun denbora laburragoak erakusten ditu. batean gehiago CoAP HTTPrekin alderatu zen makina-makina komunikazio eszenatoki batean gas-sentsoreekin, eguraldi-sentsoreekin, kokapen-sentsoreekin (GPS) eta sare mugikorreko interfazearekin (GPRS) hornitutako ibilgailuen gainean zabaldutako gailuekin. CoAP mezu bat sare mugikorrean transmititzeko behar den denbora HTTP mezuak erabiltzeko behar den denbora baino ia hiru aldiz laburragoa izan zen.
Ez bi, baina hiru protokolo alderatu dituzten ikerketak egin dira. Adibidez, MQTT, DDS eta CoAP IoT protokoloen errendimendua aplikazio medikoen eszenatoki batean sare emuladore bat erabiliz. DDSk MQTT gainditu zuen probatutako telemetriaren latentziari dagokionez, sareko baldintza txarretan. UDP-n oinarritutako CoAP-ek ondo funtzionatu zuen erantzun-denbora azkarrak behar zituzten aplikazioetarako, hala ere, UDP-n oinarrituta zegoenez, ezusteko pakete-galera handia izan zen.
throughput
MQTT eta CoAP banda-zabaleraren eraginkortasunari dagokionez, mezu bakoitzeko transmititutako datu-kopuru osoaren kalkulu gisa egin zen. CoAPek MQTT-k baino errendimendu txikiagoa erakutsi du mezu txikiak igortzean. Baina protokoloen eraginkortasuna alderatuz gero, informazio erabilgarriaren byte kopuruaren eta transferitutako byte kopuru osoaren arteko erlazioari dagokionez, CoAP eraginkorragoa izan zen.
Egun MQTT, DDS (TCP garraio-protokolo gisa) eta CoAP banda-zabalera erabiliz, CoAP-ek, oro har, banda-zabalera-kontsumo konparatibo baxuagoa erakusten zuela ikusi zen, eta hori ez zen handitu sare-paketeen galerarekin edo sareko latentzia handituarekin, MQTT eta DDS ez bezala, non zeuden. banda-zabaleraren erabilera areagotzea aipatutako eszenatokietan. Beste agertoki batek datuak aldi berean transmititzen zituzten gailu ugarik parte hartzen zuen, hori ohikoa da IoT inguruneetan. Emaitzek erakutsi zuten erabilera handiagoa izateko hobe dela CoAP erabiltzea.
Karga arinean, CoAPek banda-zabalera txikiena erabili zuen, MQTT eta REST HTTP ondoren. Hala ere, kargaren tamaina handitu zenean, REST HTTP-k emaitza onenak izan zituen.
Energia kontsumoa
Energia-kontsumoaren gaiak garrantzi handia du beti, eta batez ere IoT sistema batean. Bada MQTT eta HTTP-k elektrizitatea kontsumitzen duten bitartean, HTTP-k askoz gehiago kontsumitzen du. Eta CoAP gehiago da MQTT-rekin alderatuta, potentzia kudeatzea ahalbidetuz. Hala ere, eszenatoki sinpleetan, MQTT egokiagoa da gauzen Interneteko sareetan informazioa trukatzeko, batez ere potentzia-murrizketarik ez badago.
Haririk gabeko sare mugikor edo ezegonkor batean AMQP eta MQTT-en gaitasunak alderatu zituen esperimentu batek aurkitu zuen AMQP-k segurtasun-gaitasun gehiago eskaintzen dituela MQTT energia eraginkorragoa den bitartean.
ΠΠ΅Π·ΠΎΠΏΠ°ΡΠ½ΠΎΡΡΡ
Segurtasuna da Gauzen Internet eta laino/hodei informatika gaia aztertzean planteatutako beste gai kritiko bat. Segurtasun-mekanismoa normalean HTTP, MQTT, AMQP eta XMPP edo DTLS CoAP-en TLSn oinarritzen da, eta bi DDS aldaerak onartzen ditu.
TLS eta DTLS bezeroaren eta zerbitzariaren arteko komunikazioa ezartzeko prozesuarekin hasten dira onartzen zifra-multzo eta gakoak trukatzeko. Bi aldeek multzoak negoziatzen dituzte komunikazio gehiago kanal seguru batean gertatzen dela ziurtatzeko. Bien arteko aldea UDPn oinarritutako DTLS fidagarritasunik gabeko konexio batean funtzionatzea ahalbidetzen duten aldaketa txikietan datza.
Egun TLS eta DTLSren hainbat inplementazio ezberdinek TLS-k lan hobea egin zuela aurkitu zuten. DTLS-ren aurkako erasoek arrakasta handiagoa izan zuten akatsen tolerantziagatik.
Hala ere, protokolo horien arazo handiena da jatorriz ez zirela IoT-n erabiltzeko diseinatuta eta ez zirela laino edo hodeian lan egiteko. Esku-harremanaren bidez, konexio-establezimendu bakoitzarekin trafiko gehigarria gehitzen dute, eta horrek baliabide informatikoak hustu egiten ditu. Batez beste, % 6,5 hazi da TLSn eta % 11 DTLSn segurtasun-geruzarik gabeko komunikazioekin alderatuta. Baliabide ugariko inguruneetan, normalean bertan kokatzen direnak maila, hau ez da arazo bat izango, baina IoT eta laino mailaren arteko konexioan, muga garrantzitsu bat bihurtzen da.
Zer aukeratu? Ez dago erantzun argirik. MQTT eta HTTP protokolorik itxaropentsuenak dirudite, IoT irtenbide konparatiboki helduagoak eta egonkorragoak direlako beste protokolo batzuekin alderatuta.
Komunikazio protokolo bateratu batean oinarritutako irtenbideak
Protokolo bakarreko irtenbidea praktikatzeak desabantaila asko ditu. Adibidez, ingurune mugatu bati egokitzen zaion protokoloak baliteke segurtasun-baldintza zorrotzak dituen domeinu batean ez funtzionatzea. Hori kontuan hartuta, IoT-ko Fog-to-Cloud ekosisteman protokolo bakarreko soluzio posible guztiak baztertu behar ditugu, MQTT eta REST HTTP izan ezik.
REST HTTP protokolo bakarreko irtenbide gisa
REST HTTP eskaerak eta erantzunak IoT-to-Fog espazioan nola elkarreragiten duen adibide on bat dago: . Animaliak sentsore eramangarriez hornituta daude (IoT bezeroa, C) eta hodeiko informatika bidez kontrolatzen dira nekazaritza sistema adimendun batek (Fog zerbitzaria, S).
POST metodoaren goiburuak (/farm/animals) aldatzeko baliabidea zehazten du, baita HTTP bertsioa eta eduki mota ere, kasu honetan sistemak kudeatu behar duen animalia-ustiategia adierazten duen JSON objektu bat da (Dulcinea/behia). . Zerbitzariaren erantzunak eskaera arrakastatsua izan dela adierazten du HTTPS egoera-kodea 201 (sortutako baliabidea) bidaliz. GET metodoak URIan eskatutako baliabidea soilik zehaztu behar du (adibidez, /farm/animals/1), eta ID hori duen animaliaren JSON irudikapena itzultzen du zerbitzaritik.
PUT metodoa baliabide-erregistro zehatz batzuk eguneratu behar direnean erabiltzen da. Kasu honetan, baliabideak aldatu beharreko parametroaren URIa eta uneko balioa zehazten ditu (adibidez, behia une honetan oinez doala adieraziz, /farm/animals/1? state=walking). Azkenik, DELETE metodoa GET metodoaren berdin erabiltzen da, baina baliabidea ezabatzen du eragiketaren ondorioz.
MQTT protokolo bakarreko soluzio gisa
Har dezagun baserri adimendun bera, baina REST HTTPren ordez MQTT protokoloa erabiltzen dugu. Mosquitto liburutegia instalatuta duen tokiko zerbitzari batek bitartekari gisa jarduten du. Adibide honetan, Raspberry Pi ordenagailu soil batek (baserriko zerbitzaria deitzen zaio) MQTT bezero gisa balio du, Paho MQTT liburutegiaren instalazio baten bidez inplementatuta, Mosquitto brokerrekin guztiz bateragarria dena.
Bezero hau sentsibilizazio eta konputazio gaitasunak dituen gailu bat adierazten duen IoT abstrakzio geruza bati dagokio. Bitartekariari, berriz, abstrakzio maila altuago bati dagokio, prozesatzeko eta biltegiratze ahalmen handiagoak dituen laino-konputazio-nodo bat irudikatzen duena.
Proposatutako baserri adimendunaren eszenatokian, Raspberry Pi azelerometrora, GPSra eta tenperatura sentsoreetara konektatzen da eta sentsore horien datuak laino-nodo batera argitaratzen ditu. Seguruenik dakizuenez, MQTT-k gaiak hierarkia gisa tratatzen ditu. MQTT argitaletxe bakar batek gai multzo zehatz bati buruzko mezuak argitara ditzake. Gure kasuan hiru dira. Animalien ukuilu bateko tenperatura neurtzen duen sentsore baterako, bezeroak gai bat hautatzen du (animalien haztegia/estalpea/tenperatura). Azelerometroaren bidez GPS kokapena eta animalien mugimendua neurtzen dituzten sentsoreetarako, bezeroak eguneraketak argitaratuko ditu (animalia/animalia/GPS) eta (animalia/animalia/mugimendua).
Informazio hori artekariari helaraziko zaio, eta honek aldi baterako tokiko datu-base batean gorde ahal izango du, gerora interesa duen beste harpidedun bat etorriz gero.
Lainoan MQTT broker gisa jarduten duen eta Raspberry Pisek, MQTT bezero gisa, sentsoreen datuak bidaltzen dizkion tokiko zerbitzariaz gain, hodei mailan beste MQTT broker bat egon daiteke. Kasu honetan, tokiko brokerari helarazitako informazioa aldi baterako tokiko datu-base batean gorde daiteke eta/edo hodeira bidali. Egoera honetan fog MQTT brokera datu guztiak hodeiko MQTT brokerarekin lotzeko erabiltzen da. Arkitektura honekin, mugikorreko aplikazioen erabiltzaile bat bi artekarietara harpidetu daiteke.
Agenteetako batekin (adibidez, hodeia) konexioak huts egiten badu, azken erabiltzaileak bestearen informazioa jasoko du (lainoa). Hau laino eta hodeiko konputazio sistemen ezaugarri bat da. Lehenespenez, mugikorretarako aplikazioa lainoaren MQTT brokerra konektatzeko konfigura daiteke lehenik, eta horrek huts egiten badu, hodeiko MQTT brokerra konektatzeko. Irtenbide hau IoT-F2C sistemetako askotako bat besterik ez da.
Protokolo anitzeko soluzioak
Protokolo bakarreko soluzioak ezagunak dira inplementazio errazagoa dutelako. Baina argi dago IoT-F2C sistemetan zentzuzkoa dela protokolo desberdinak konbinatzea. Ideia da protokolo ezberdinek maila ezberdinetan funtziona dezaketela. Hartu, adibidez, hiru abstrakzio: IoT, fog eta cloud computing geruzak. IoT mailan dauden gailuak, oro har, mugatuak dira. Ikuspegi orokor honetarako, har ditzagun IoT mailak mugatuenak, hodeiak murrizten direnak eta lainoaren konputazioa "erdiko nonbait" gisa. Orduan, IoT eta lainoaren abstrakzioen artean, egungo protokolo-soluzioek MQTT, CoAP eta XMPP daude. Lainoaren eta hodeiaren artean, berriz, AMQP da erabiltzen den protokolo nagusietako bat, REST HTTPrekin batera, malgutasunagatik IoT eta laino geruzen artean ere erabiltzen dena.
Hemen arazo nagusia protokoloen elkarreragingarritasuna eta mezuak protokolo batetik bestera transferitzeko erraztasuna da. Egokiena, etorkizunean, hodei eta laino baliabideak dituen Gauzen Internet sistema baten arkitektura erabilitako komunikazio-protokolotik independentea izango da eta protokolo ezberdinen arteko elkarreragingarritasun ona bermatuko du.
Gaur egun horrela ez denez, zentzuzkoa da desberdintasun nabarmenik ez duten protokoloak uztartzea. Horretarako, balizko irtenbide bat arkitektura estilo bera jarraitzen duten bi protokoloren konbinazioan oinarritzen da, REST HTTP eta CoAP. Proposatutako beste irtenbide bat argitaratze-harpidetza komunikazioa eskaintzen duten bi protokoloen konbinazioan oinarritzen da, MQTT eta AMQP. Antzeko kontzeptuak erabiltzeak (bai MQTT bai AMQPek artekariak erabiltzen dituzte, CoAPek eta HTTPk REST erabiltzen dute) konbinazio hauek errazago inplementatzen dira eta integrazio-esfortzu txikiagoa eskatzen du.
(a) Irudiak eskaera-erantzunetan oinarritutako bi eredu erakusten ditu, HTTP eta CoAP, eta IoT-F2C soluzio batean kokatzea posiblea. HTTP sare modernoetako protokolorik ezagun eta onartuenetako bat denez, nekez ordezkatuko dute guztiz beste mezularitza-protokolo batzuek. Hodeiaren eta lainoaren artean kokatzen diren gailu indartsuak adierazten dituzten nodoen artean, REST HTTP irtenbide adimenduna da.
Bestalde, Fog eta IoT geruzen artean komunikatzen diren baliabide informatiko mugatuak dituzten gailuetarako, eraginkorragoa da CoAP erabiltzea. CoAP-en abantaila handietako bat HTTP-rekin duen bateragarritasuna da, bi protokoloak REST printzipioetan oinarritzen baitira.
(b) irudiak bi argitaratze-harpidetza komunikazio eredu erakusten ditu eszenatoki berean, MQTT eta AMQP barne. Bi protokoloak hipotetikoki abstrakzio-geruza bakoitzeko nodoen arteko komunikaziorako erabil daitezkeen arren, haien posizioa errendimenduaren arabera zehaztu behar da. MQTT baliabide informatiko mugatuak dituzten gailuetarako protokolo arin gisa diseinatu zen, beraz, IoT-Fog komunikaziorako erabil daiteke. AMQP gailu indartsuagoetarako egokia da, lainoaren eta hodeiaren nodoen artean kokatuko lukeena. MQTT-en ordez, XMPP protokoloa IoT-n erabil daiteke, arintzat jotzen baita. Baina ez da hain erabilia horrelako eszenatokietan.
Findings
Nekez izango da eztabaidatutako protokoloetako bat sistema bateko komunikazio guztiak estaltzeko, baliabide informatiko mugatuak dituzten gailuetatik hasi eta hodeiko zerbitzarietaraino. Azterketak aurkitu du garatzaileek gehien erabiltzen dituzten bi aukerarik itxaropentsuenak MQTT eta RESTful HTTP direla. Bi protokolo hauek helduenak eta egonkorrenak ez ezik, ongi dokumentatutako eta arrakastatsuen inplementazio eta sareko baliabide asko ere biltzen dituzte.
Bere egonkortasuna eta konfigurazio sinplea direla eta, MQTT denboran zehar bere errendimendu handiagoa frogatu duen protokoloa da IoT mailan gailu mugatuekin erabiltzen denean. Komunikazio mugatua eta bateria-kontsumoa arazoa ez den sistemaren zatietan, hala nola laino-domeinu batzuetan eta hodeiko informatika gehienetan, RESTful HTTP aukera erraza da. CoAP ere kontuan hartu behar da, IoT mezularitza estandar gisa ere azkar eboluzionatzen ari baita eta litekeena da etorkizun hurbilean MQTT eta HTTPren antzeko egonkortasun eta heldutasun maila batera iristea. Baina estandarra gaur egun eboluzionatzen ari da, eta horrek epe laburreko bateragarritasun arazoak ditu.
Zer gehiago irakur dezakezu blogean?
β
β
β
β
β
Harpidetu gure -kanala, hurrengo artikulua ez galtzeko! Astean bitan baino gehiago ez dugu idazten eta negozioetan bakarrik.
Iturria: www.habr.com