Zhvillimi i teknologjive në fushën e softuerit dhe harduerit, shfaqja e protokolleve të reja të komunikimit kanë çuar në zgjerimin e Internetit të Gjërave (IoT). Numri i pajisjeve po rritet dita ditës dhe ato po gjenerojnë një sasi të madhe të dhënash. Prandaj, ekziston nevoja për një arkitekturë të përshtatshme të sistemit të aftë për të përpunuar, ruajtur dhe transmetuar këto të dhëna.
Tani shërbimet cloud përdoren për këto qëllime. Sidoqoftë, paradigma gjithnjë e më e popullarizuar e llogaritjes së mjegullës (Fog) mund të plotësojë zgjidhjet e cloud duke shkallëzuar dhe optimizuar infrastrukturën IoT.
Retë janë të afta të mbulojnë shumicën e kërkesave për IoT. Për shembull, për të ofruar monitorim të shërbimeve, përpunim të shpejtë të çdo sasie të dhënash të gjeneruar nga pajisjet, si dhe vizualizimin e tyre. Llogaritja e mjegullës është më efektive kur zgjidh problemet në kohë reale. Ato ofrojnë përgjigje të shpejtë ndaj kërkesave dhe vonesë minimale në përpunimin e të dhënave. Kjo do të thotë, Mjegulla plotëson "retë" dhe zgjeron aftësitë e saj.
Megjithatë, pyetja kryesore është e ndryshme: si duhet të ndërveprojnë e gjithë kjo në kontekstin e IoT? Cilat protokolle komunikimi do të jenë më efektive kur punoni në një sistem të kombinuar IoT-Fog-Cloud?
Pavarësisht dominimit të dukshëm të HTTP, ka një numër të madh zgjidhjesh të tjera të përdorura në sistemet IoT, Fog dhe Cloud. Kjo është për shkak se IoT duhet të kombinojë funksionalitetin e një sërë sensorësh të pajisjes me sigurinë, pajtueshmërinë dhe kërkesat e tjera të përdoruesve.
Por thjesht nuk ka asnjë ide të vetme për arkitekturën e referencës dhe standardin e komunikimit. Prandaj, krijimi i një protokolli të ri ose modifikimi i një protokolli ekzistues për detyra specifike IoT është një nga detyrat më të rëndësishme me të cilat përballet komuniteti i IT.
Cilat protokolle janë aktualisht në përdorim dhe çfarë mund të ofrojnë ato? Le ta kuptojmë. Por së pari, le të diskutojmë parimet e ekosistemit në të cilin ndërveprojnë retë, mjegulla dhe Interneti i gjërave.
Arkitekturë IoT Fog-to-Cloud (F2C).
Ju ndoshta keni vënë re se sa përpjekje po bëhet për të eksploruar avantazhet dhe përfitimet që lidhen me menaxhimin inteligjent dhe të koordinuar të IoT, cloud dhe mjegullës. Nëse jo, atëherë këtu janë tre iniciativa standardizimi: , и .
Nëse më parë konsideroheshin vetëm 2 nivele, retë dhe pajisjet fundore, atëherë arkitektura e propozuar prezanton një nivel të ri - llogaritjen e mjegullës. Në këtë rast, niveli i mjegullës mund të ndahet në disa nënnivele, në varësi të specifikave të burimeve ose një sërë politikash që përcaktojnë përdorimin e pajisjeve të ndryshme në këto nënnivele.
Si mund të duket ky abstraksion? Këtu është një ekosistem tipik IoT-Fog-Cloud. Pajisjet IoT dërgojnë të dhëna në serverë dhe pajisje kompjuterike më të shpejtë për të zgjidhur problemet që kërkojnë vonesë të ulët. Në të njëjtin sistem, retë janë përgjegjëse për zgjidhjen e problemeve që kërkojnë një sasi të madhe burimesh kompjuterike ose hapësirë për ruajtjen e të dhënave.
Telefonat inteligjentë, orët inteligjente dhe pajisjet e tjera mund të jenë gjithashtu pjesë e IoT. Por pajisje të tilla, si rregull, përdorin protokolle komunikimi të pronarit nga zhvilluesit e mëdhenj. Të dhënat e gjeneruara të IoT transferohen në shtresën e mjegullës përmes protokollit REST HTTP, i cili siguron fleksibilitet dhe ndërveprim kur krijohen shërbimet RESTful. Kjo është e rëndësishme në dritën e nevojës për të siguruar përputhshmëri të prapambetur me infrastrukturën ekzistuese kompjuterike që funksionon në kompjuterë lokalë, serverë ose një grup serverësh. Burimet lokale, të quajtura "nyjet e mjegullës", filtrojnë të dhënat e marra dhe i përpunojnë ato në nivel lokal ose i dërgojnë në cloud për llogaritje të mëtejshme.
Retë mbështesin protokolle të ndryshme komunikimi, më të zakonshmet janë AMQP dhe REST HTTP. Meqenëse HTTP është i njohur dhe i përshtatur për internetin, mund të lindë pyetja: "a nuk duhet ta përdorim atë për të punuar me IoT dhe mjegull?" Megjithatë, ky protokoll ka probleme me performancën. Më shumë për këtë më vonë.
Në përgjithësi, ekzistojnë 2 modele të protokolleve të komunikimit të përshtatshëm për sistemin që na duhen. Këto janë kërkesa-përgjigje dhe publiko-subscribe. Modeli i parë është më i njohur, veçanërisht në arkitekturën server-klient. Klienti kërkon informacion nga serveri, dhe serveri merr kërkesën, e përpunon atë dhe kthen një mesazh përgjigjeje. Protokollet REST HTTP dhe CoAP funksionojnë në këtë model.
Modeli i dytë lindi nga nevoja për të siguruar një bashkim asinkron, të shpërndarë, të lirë midis burimeve që gjenerojnë të dhëna dhe marrësve të këtyre të dhënave.
Modeli supozon tre pjesëmarrës: një botues (burimi i të dhënave), një ndërmjetës (dispeçer) dhe një pajtimtar (marrës). Këtu, klienti që vepron si pajtimtar nuk duhet të kërkojë informacion nga serveri. Në vend që të dërgojë kërkesa, ai abonohet në disa ngjarje në sistem përmes një ndërmjetësi, i cili është përgjegjës për filtrimin e të gjitha mesazheve hyrëse dhe për t'i kursyer ato midis botuesve dhe abonentëve. Dhe botuesi, kur ndodh një ngjarje në lidhje me një temë të caktuar, ia publikon atë ndërmjetësit, i cili i dërgon të dhënat mbi temën e kërkuar abonentit.
Në thelb, kjo arkitekturë bazohet në ngjarje. Dhe ky model ndërveprimi është interesant për aplikacionet në IoT, cloud, mjegull për shkak të aftësisë së tij për të ofruar shkallëzim dhe për të thjeshtuar ndërlidhjen midis pajisjeve të ndryshme, për të mbështetur komunikimin dinamik shumë-për-shumë dhe komunikimin asinkron. Disa nga protokollet më të njohura të standardizuara të mesazheve që përdorin një model publikimi-subscribe përfshijnë MQTT, AMQP dhe DDS.
Natyrisht, modeli publiko-subscribe ka shumë përparësi:
- Botuesit dhe abonentët nuk kanë nevojë të dinë për ekzistencën e njëri-tjetrit;
- Një pajtimtar mund të marrë informacion nga shumë botime të ndryshme dhe një botues mund të dërgojë të dhëna te shumë abonentë të ndryshëm (parimi shumë-për-shumë);
- Botuesi dhe pajtimtari nuk duhet të jenë aktiv në të njëjtën kohë për të komunikuar, sepse ndërmjetësi (duke punuar si sistem në radhë) do të jetë në gjendje të ruajë mesazhin për klientët që aktualisht nuk janë të lidhur në rrjet.
Megjithatë, modeli kërkesë-përgjigje ka gjithashtu pikat e veta të forta. Në rastet kur aftësia e serverit për të trajtuar kërkesat e shumëfishta të klientëve nuk është problem, ka kuptim të përdoren zgjidhje të provuara dhe të besueshme.
Ekzistojnë gjithashtu protokolle që mbështesin të dy modelet. Për shembull, XMPP dhe HTTP 2.0, të cilat mbështesin opsionin "shtytje të serverit". IETF ka lëshuar gjithashtu një CoAP. Në përpjekje për të zgjidhur problemin e mesazheve, janë krijuar disa zgjidhje të tjera, si protokolli WebSockets ose përdorimi i protokollit HTTP mbi QUIC (Quick UDP Internet Connections).
Në rastin e WebSockets, megjithëse përdoret për të transferuar të dhëna në kohë reale nga një server në një klient web dhe siguron lidhje të vazhdueshme me komunikim të njëkohshëm dydrejtimësh, ai nuk është i destinuar për pajisjet me burime të kufizuara kompjuterike. QUIC gjithashtu meriton vëmendje, pasi protokolli i ri i transportit ofron shumë mundësi të reja. Por meqenëse QUIC nuk është ende i standardizuar, është e parakohshme të parashikohet zbatimi i mundshëm dhe ndikimi i tij në zgjidhjet e IoT. Pra, ne mbajmë në mendje WebSockets dhe QUIC me një sy nga e ardhmja, por nuk do t'i studiojmë më në detaje për momentin.
Kush është më i lezetshmi në botë: krahasimi i protokolleve
Tani le të flasim për pikat e forta dhe të dobëta të protokolleve. Duke parë përpara, le të bëjmë menjëherë një rezervë se nuk ka një udhëheqës të qartë. Çdo protokoll ka disa avantazhe/disvantazhe.
Koha e reagimit
Një nga karakteristikat më të rëndësishme të protokolleve të komunikimit, veçanërisht në lidhje me Internetin e Gjërave, është koha e përgjigjes. Por midis protokolleve ekzistuese, nuk ka asnjë fitues të qartë që demonstron nivelin minimal të vonesës kur punoni në kushte të ndryshme. Por ka një grup të tërë kërkimesh dhe krahasimesh të aftësive të protokollit.
Për shembull, Krahasimet e efektivitetit të HTTP dhe MQTT gjatë punës me IoT treguan se koha e përgjigjes për kërkesat për MQTT është më e vogël se për HTTP. Dhe kur Koha e udhëtimit vajtje-ardhje (RTT) e MQTT dhe CoAP zbuloi se mesatarja e RTT e CoAP është 20% më pak se ajo e MQTT.
tjetër me RTT për protokollet MQTT dhe CoAP u krye në dy skenarë: rrjeti lokal dhe rrjeti IoT. Doli se mesatarja e RTT është 2-3 herë më e lartë në një rrjet IoT. MQTT me QoS0 tregoi një rezultat më të ulët në krahasim me CoAP, dhe MQTT me QoS1 tregoi një RTT më të lartë për shkak të ACK-ve në shtresat e aplikimit dhe transportit. Për nivele të ndryshme QoS, vonesa e rrjetit pa mbingarkesë ishte milisekonda për MQTT dhe qindra mikrosekonda për CoAP. Sidoqoftë, ia vlen të kujtojmë se kur punoni në rrjete më pak të besueshme, MQTT që funksionon në krye të TCP do të tregojë një rezultat krejtësisht të ndryshëm.
koha e përgjigjes për protokollet AMQP dhe MQTT duke rritur ngarkesën tregoi se me një ngarkesë të lehtë niveli i vonesës është pothuajse i njëjtë. Por kur transferoni sasi të mëdha të dhënash, MQTT demonstron kohë më të shkurtra përgjigjeje. në një më shumë CoAP u krahasua me HTTP në një skenar komunikimi makinë-me-makinë me pajisje të vendosura në krye të automjeteve të pajisura me sensorë gazi, sensorë moti, sensorë vendndodhjeje (GPS) dhe një ndërfaqe rrjeti celular (GPRS). Koha e nevojshme për të transmetuar një mesazh CoAP përmes rrjetit celular ishte pothuajse tre herë më e shkurtër se koha e nevojshme për të përdorur mesazhet HTTP.
Janë kryer studime që krahasuan jo dy, por tre protokolle. Për shembull, performanca e protokolleve IoT MQTT, DDS dhe CoAP në një skenar aplikimi mjekësor duke përdorur një emulator rrjeti. DDS e tejkaloi MQTT-në për sa i përket vonesës së testuar të telemetrisë në një sërë kushtesh të këqija të rrjetit. CoAP i bazuar në UDP funksionoi mirë për aplikacionet që kërkonin kohë të shpejtë përgjigjeje, megjithatë, për shkak se ishte i bazuar në UDP, pati humbje të konsiderueshme të paparashikueshme të paketave.
kapacitet
MQTT dhe CoAP për sa i përket efikasitetit të gjerësisë së brezit u kryen si një llogaritje e sasisë totale të të dhënave të transmetuara për mesazh. CoAP ka treguar xhiro më të ulët se MQTT kur transmeton mesazhe të vogla. Por kur krahasojmë efikasitetin e protokolleve për sa i përket raportit të numrit të bajteve të informacionit të dobishëm me numrin total të bajteve të transferuara, CoAP doli të ishte më efektiv.
në duke përdorur MQTT, DDS (me TCP si protokoll transporti) dhe gjerësinë e brezit CoAP, u zbulua se CoAP në përgjithësi tregoi konsum relativisht më të ulët të gjerësisë së brezit, i cili nuk u rrit me rritjen e humbjes së paketave të rrjetit ose rritjen e vonesës së rrjetit, ndryshe nga MQTT dhe DDS, ku kishte një rritje në përdorimin e gjerësisë së brezit në skenarët e përmendur. Një tjetër skenar përfshinte një numër të madh pajisjesh që transmetonin të dhëna njëkohësisht, gjë që është tipike në mjediset IoT. Rezultatet treguan se për përdorim më të lartë është më mirë të përdoret CoAP.
Nën ngarkesë të lehtë, CoAP përdori gjerësinë më të vogël të brezit, e ndjekur nga MQTT dhe REST HTTP. Sidoqoftë, kur u rrit madhësia e ngarkesave, REST HTTP pati rezultatet më të mira.
Konsumi i energjisë
Çështja e konsumit të energjisë ka gjithmonë një rëndësi të madhe, dhe veçanërisht në një sistem IoT. Nëse Ndërsa MQTT dhe HTTP konsumojnë energji elektrike, HTTP konsumon shumë më tepër. Dhe CoAP është më shumë krahasuar me MQTT, duke lejuar menaxhimin e energjisë. Megjithatë, në skenarë të thjeshtë, MQTT është më i përshtatshëm për shkëmbimin e informacionit në rrjetet e Internetit të Gjërave, veçanërisht nëse nuk ka kufizime të energjisë.
Një eksperiment që krahasoi aftësitë e AMQP dhe MQTT në një shtrat testimi të rrjetit celular ose të paqëndrueshëm, zbuloi se AMQP ofron më shumë aftësi sigurie ndërsa MQTT është më efikas në energji.
siguri
Siguria është një tjetër çështje kritike e ngritur gjatë studimit të temës së Internetit të Gjërave dhe informatikës së mjegullës/cloud. Mekanizmi i sigurisë zakonisht bazohet në TLS në HTTP, MQTT, AMQP dhe XMPP, ose DTLS në CoAP dhe mbështet të dy variantet DDS.
TLS dhe DTLS fillojnë me procesin e vendosjes së komunikimit midis klientit dhe anëve të serverit për të shkëmbyer paketat dhe çelësat e mbështetur të shifrave. Të dyja palët negociojnë grupe për të siguruar që komunikimi i mëtejshëm të ndodhë në një kanal të sigurt. Dallimi midis të dyve qëndron në modifikimet e vogla që lejojnë DTLS të bazuar në UDP të funksionojë mbi një lidhje jo të besueshme.
në Disa zbatime të ndryshme të TLS dhe DTLS zbuluan se TLS bëri një punë më të mirë. Sulmet ndaj DTLS ishin më të suksesshme për shkak të tolerancës së tij ndaj gabimeve.
Sidoqoftë, problemi më i madh me këto protokolle është se ato nuk ishin krijuar fillimisht për t'u përdorur në IoT dhe nuk kishin për qëllim të punonin në mjegull ose re. Nëpërmjet shtrëngimit të duarve, ata shtojnë trafik shtesë me çdo vendosje lidhjeje, gjë që shteron burimet kompjuterike. Mesatarisht, ka një rritje prej 6,5% për TLS dhe 11% për DTLS në shpenzimet e përgjithshme në krahasim me komunikimet pa një shtresë sigurie. Në mjedise të pasura me burime, të cilat zakonisht ndodhen në niveli, ky nuk do të jetë problem, por në lidhjen midis IoT dhe nivelit të mjegullës, ky bëhet një kufizim i rëndësishëm.
Çfarë të zgjidhni? Nuk ka përgjigje të qartë. MQTT dhe HTTP duket se janë protokollet më premtues pasi konsiderohen relativisht zgjidhje më të pjekura dhe më të qëndrueshme IoT krahasuar me protokollet e tjera.
Zgjidhje të bazuara në një protokoll të unifikuar komunikimi
Praktika e një zgjidhjeje me një protokoll ka shumë disavantazhe. Për shembull, një protokoll që i përshtatet një mjedisi të kufizuar mund të mos funksionojë në një domen që ka kërkesa strikte sigurie. Duke pasur parasysh këtë, na mbetet të hedhim poshtë pothuajse të gjitha zgjidhjet e mundshme me një protokoll në ekosistemin Fog-to-Cloud në IoT, përveç MQTT dhe REST HTTP.
RESTO HTTP si një zgjidhje me një protokoll
Ekziston një shembull i mirë se si kërkesat dhe përgjigjet REST HTTP ndërveprojnë në hapësirën IoT-to-Fog: . Kafshët janë të pajisura me sensorë të veshjes (klient IoT, C) dhe kontrollohen nëpërmjet kompjuterit cloud nga një sistem bujqësor inteligjent (Fog server, S).
Kreu i metodës POST specifikon burimin për të modifikuar (/fermë/kafshë) si dhe versionin HTTP dhe llojin e përmbajtjes, i cili në këtë rast është një objekt JSON që përfaqëson fermën e kafshëve që sistemi do të menaxhojë (Dulcinea/lopë) . Përgjigja nga serveri tregon se kërkesa ishte e suksesshme duke dërguar kodin e statusit HTTPS 201 (burimi i krijuar). Metoda GET duhet të specifikojë vetëm burimin e kërkuar në URI (për shembull, /farm/animals/1), i cili kthen një paraqitje JSON të kafshës me atë ID nga serveri.
Metoda PUT përdoret kur duhet të përditësohet një regjistër specifik i burimeve. Në këtë rast, burimi specifikon URI-në për parametrin që do të ndryshohet dhe vlerën aktuale (për shembull, duke treguar që lopa është aktualisht duke ecur, /farm/animals/1? gjendje=ec). Së fundi, metoda DELETE përdoret në mënyrë të barabartë me metodën GET, por thjesht fshin burimin si rezultat i operacionit.
MQTT si një zgjidhje me një protokoll
Le të marrim të njëjtën fermë inteligjente, por në vend të REST HTTP ne përdorim protokollin MQTT. Një server lokal me bibliotekën Mosquitto të instaluar vepron si ndërmjetës. Në këtë shembull, një kompjuter i thjeshtë (i referuar si serveri i fermës) Raspberry Pi shërben si një klient MQTT, i implementuar përmes një instalimi të bibliotekës Paho MQTT, e cila është plotësisht e pajtueshme me ndërmjetësin Mosquitto.
Ky klient korrespondon me një shtresë abstraksioni IoT që përfaqëson një pajisje me aftësi ndijuese dhe llogaritëse. Ndërmjetësi, nga ana tjetër, korrespondon me një nivel më të lartë abstraksioni, duke përfaqësuar një nyje llogaritëse të mjegullës e karakterizuar nga kapacitet më të madh përpunimi dhe ruajtjeje.
Në skenarin e propozuar të fermës inteligjente, Raspberry Pi lidhet me përshpejtuesin, GPS dhe sensorët e temperaturës dhe publikon të dhëna nga këta sensorë në një nyje mjegull. Siç e dini ndoshta, MQTT i trajton temat si një hierarki. Një botues i vetëm MQTT mund të publikojë mesazhe për një grup specifik temash. Në rastin tonë janë tre prej tyre. Për një sensor që mat temperaturën në një hambar të kafshëve, klienti zgjedh një temë (ferma e kafshëve/kafshët/temperatura). Për sensorët që matin vendndodhjen GPS dhe lëvizjen e kafshëve përmes përshpejtuesit, klienti do të publikojë përditësime për (fermë e kafshëve/kafshë/GPS) dhe (fermë e kafshëve/kafshë/lëvizje).
Ky informacion do t'i kalohet ndërmjetësit, i cili mund ta ruajë përkohësisht në një bazë të dhënash lokale në rast se një abonent tjetër i interesuar vjen më vonë.
Përveç serverit lokal, i cili vepron si ndërmjetës MQTT në mjegull dhe të cilit Raspberry Pis, duke vepruar si klientë MQTT, dërgon të dhëna sensori, mund të ketë një ndërmjetës tjetër MQTT në nivelin e resë kompjuterike. Në këtë rast, informacioni i transmetuar te ndërmjetësi lokal mund të ruhet përkohësisht në një bazë të dhënash lokale dhe/ose të dërgohet në cloud. Ndërmjetësi MQTT i mjegullës në këtë situatë përdoret për të lidhur të gjitha të dhënat me ndërmjetësin MQTT të cloud. Me këtë arkitekturë, një përdorues i aplikacionit celular mund të abonohet në të dy ndërmjetësit.
Nëse lidhja me një nga ndërmjetësit (për shembull, cloud) dështon, përdoruesi përfundimtar do të marrë informacion nga tjetri (mjegull). Ky është një tipar karakteristik i sistemeve të kombinuara të mjegullës dhe kompjuterit cloud. Si parazgjedhje, aplikacioni celular mund të konfigurohet që së pari të lidhet me ndërmjetësin MQTT të mjegullës dhe nëse kjo dështon, të lidhet me ndërmjetësin MQTT të cloud. Kjo zgjidhje është vetëm një nga shumë në sistemet IoT-F2C.
Zgjidhje me shumë protokolle
Zgjidhjet me një protokoll janë të njohura për shkak të zbatimit të tyre më të lehtë. Por është e qartë se në sistemet IoT-F2C ka kuptim të kombinohen protokolle të ndryshme. Ideja është që protokolle të ndryshme mund të funksionojnë në nivele të ndryshme. Merrni, për shembull, tre abstraksione: shtresat e IoT, mjegull dhe informatikë cloud. Pajisjet në nivelin IoT përgjithësisht konsiderohen të kufizuara. Për këtë përmbledhje, le t'i konsiderojmë nivelet e IoT si më të kufizuara, retë më pak të kufizuara dhe llogaritjen e mjegullës si "diku në mes". Rezulton se midis abstraksioneve të IoT dhe mjegullës, zgjidhjet aktuale të protokollit përfshijnë MQTT, CoAP dhe XMPP. Ndërmjet mjegullës dhe resë, nga ana tjetër, AMQP është një nga protokollet kryesore të përdorura, së bashku me REST HTTP, i cili për shkak të fleksibilitetit të tij përdoret edhe midis shtresave IoT dhe mjegullës.
Problemi kryesor këtu është ndërveprueshmëria e protokolleve dhe lehtësia e transferimit të mesazheve nga një protokoll në tjetrin. Idealisht, në të ardhmen, arkitektura e një sistemi Internet of Things me burime cloud dhe mjegull do të jetë e pavarur nga protokolli i komunikimit të përdorur dhe do të sigurojë ndërveprim të mirë midis protokolleve të ndryshme.
Meqenëse aktualisht nuk është kështu, ka kuptim të kombinohen protokollet që nuk kanë dallime të rëndësishme. Për këtë qëllim, një zgjidhje e mundshme bazohet në një kombinim të dy protokolleve që ndjekin të njëjtin stil arkitektonik, REST HTTP dhe CoAP. Një zgjidhje tjetër e propozuar bazohet në një kombinim të dy protokolleve që ofrojnë komunikim publiko-subscribe, MQTT dhe AMQP. Përdorimi i koncepteve të ngjashme (si ndërmjetësit përdorin MQTT ashtu edhe AMQP, CoAP dhe HTTP përdorin REST) i bën këto kombinime më të lehta për t'u zbatuar dhe kërkon më pak përpjekje integruese.
Figura (a) tregon dy modele të bazuara në përgjigje të kërkesës, HTTP dhe CoAP, dhe vendosjen e tyre të mundshme në një zgjidhje IoT-F2C. Meqenëse HTTP është një nga protokollet më të njohur dhe më të miratuar në rrjetet moderne, nuk ka gjasa që ai të zëvendësohet plotësisht nga protokollet e tjera të mesazheve. Ndër nyjet që përfaqësojnë pajisje të fuqishme që qëndrojnë midis resë dhe mjegullës, REST HTTP është një zgjidhje e zgjuar.
Nga ana tjetër, për pajisjet me burime të kufizuara llogaritëse që komunikojnë midis shtresave të Mjegullit dhe IoT, është më efikas të përdoret CoAP. Një nga avantazhet e mëdha të CoAP është në fakt përputhshmëria e tij me HTTP, pasi të dy protokollet bazohen në parimet REST.
Figura (b) tregon dy modele komunikimi publiko-subscribe në të njëjtin skenar, duke përfshirë MQTT dhe AMQP. Megjithëse të dy protokollet mund të përdoren hipotetikisht për komunikimin midis nyjeve në secilën shtresë abstraksioni, pozicioni i tyre duhet të përcaktohet bazuar në performancën. MQTT u krijua si një protokoll i lehtë për pajisjet me burime të kufizuara kompjuterike, kështu që mund të përdoret për komunikimin IoT-Fog. AMQP është më i përshtatshëm për pajisje më të fuqishme, të cilat në mënyrë ideale do ta poziciononin atë midis mjegullës dhe nyjeve të resë. Në vend të MQTT, protokolli XMPP mund të përdoret në IoT pasi konsiderohet i lehtë. Por nuk përdoret aq gjerësisht në skenarë të tillë.
Gjetjet
Nuk ka gjasa që një nga protokollet e diskutuar të jetë i mjaftueshëm për të mbuluar të gjitha komunikimet në një sistem, nga pajisjet me burime të kufizuara kompjuterike deri te serverët cloud. Studimi zbuloi se dy opsionet më premtuese që zhvilluesit përdorin më shumë janë MQTT dhe RESTful HTTP. Këto dy protokolle jo vetëm që janë më të pjekurit dhe më të qëndrueshëm, por gjithashtu përfshijnë shumë zbatime të mirë-dokumentuara dhe të suksesshme dhe burime online.
Për shkak të stabilitetit dhe konfigurimit të thjeshtë, MQTT është një protokoll që ka dëshmuar performancën e tij superiore me kalimin e kohës kur përdoret në nivelin IoT me pajisje të kufizuara. Në pjesë të sistemit ku komunikimi i kufizuar dhe konsumi i baterisë nuk janë problem, si p.sh. disa fusha të mjegullës dhe shumica e kompjuterëve në renë kompjuterike, HTTP RESTful është një zgjedhje e lehtë. CoAP gjithashtu duhet të merret parasysh pasi po zhvillohet me shpejtësi si një standard i mesazheve IoT dhe ka të ngjarë që të arrijë një nivel stabiliteti dhe pjekurie të ngjashme me MQTT dhe HTTP në të ardhmen e afërt. Por standardi aktualisht po evoluon, i cili vjen me çështje të përputhshmërisë afatshkurtra.
Çfarë tjetër mund të lexoni në blog?
→
→
→
→
→
Regjistrohu në tonë -kanal që të mos humbisni artikullin tjetër! Ne shkruajmë jo më shumë se dy herë në javë dhe vetëm për punë.
Burimi: www.habr.com