Zhvillimi i teknologjive në fushën e softuerëve dhe harduerëve, shfaqja e protokolleve të reja të komunikimit ka çuar në zgjerimin e internetit të gjërave (IoT). Numri i pajisjeve po rritet çdo ditë, dhe ato gjenerojnë një volum të madh të dhënash. Prandaj, ekziston nevoja për një arkitekturë të përshtatshme të sistemit, e cila është në gjendje të përpunojë, ruajë dhe transmetojë këto të dhëna.
Aktualisht, për këto qëllime përdoren shërbimet cloud. Megjithatë, paradigma gjithnjë e më e njohur e llogaritjes në re të mjegullës (Fog) është në gjendje të plotësojë zgjidhjet cloud, duke zgjeruar dhe optimizuar infrastrukturën e IoT.
«Re» janë në gjendje të mbulojnë shumicën e kërkesave të IoT. Për shembull, ato ofrojnë monitorimin e shërbimeve, përpunimin e shpejtë të çdo volumi të dhënash të gjeneruara nga pajisjet, si dhe vizualizimin e tyre. Llogaritë e mjegullës, nga ana tjetër, janë më efikase në zgjidhjen e detyrave në kohë reale. Ato sigurojnë një përgjigje të shpejtë ndaj kërkesave dhe një vonesë minimale gjatë përpunimit të të dhënave. Kështu, Fog plotëson «re» duke zgjeruar mundësitë e saj.
Megjithatë, pyetja kryesore është se si duhet të ndërveprojnë të gjitha këto në kontekstin e IoT? Cilët protokoll komunikimi do të ishin më të efektshëm për të punuar në një sistem të integruar IoT-Fog-Cloud?
Pavarësisht dukshmërisë së dominimit të HTTP, në sistemet IoT, Fog dhe Cloud përdoren shumë zgjidhje të tjera. Kjo shpjegohet me faktin se IoT duhet të kombinojë funksionalitetin e sensorëve të ndryshëm të pajisjeve me sigurinë, përputhshmërinë dhe kërkesa të tjera që përdoruesit kanë.
Megjithatë, nuk ka një përkufizim të vetme për një arkitekturë standarde dhe protokoll komunikimi. Prandaj, krijimi i një protokolli të ri ose përmirësimi i një ekzistenti për detyrat specifike të IoT është një nga sfidat më të rëndësishme që përballet komuniteti IT.
Cilat protokolle përdoren tani dhe çfarë mund të ofrojnë? Le të shqyrtojmë. Por fillimisht, le të diskutojmë parimet e ekosistemit, në të cilin ndërveprojnë re, mjegulla dhe interneti i gjërave.
Arkitektura IoT Fog-to-Cloud (F2C)
Për sigur që e keni vënë re sa përpjekje të mëdha bëhen për të studiuar avantazhet dhe përfitimet që lidhen me menaxhimin racional dhe të koordinuar të IoT, reve dhe mjegullës. Nëse jo, këtu janë tre nisma për standardizim: , dhe .
Nëse më parë mirreshin parasysh vetëm 2 nivele, re dhe pajisjet fundore, arkitektura e propozuar sjell një nivel të ri - llogaritë në mjegull. Kjo është në gjendje të ndahet në disa nënnivel, në varësi të specifikave të resurseve ose grupeve të politikave që përcaktojnë përdorimin e pajisjeve të ndryshme në këto nënnivela.
Si mund të duket kjo abstraksion? Këtu është një ekosistem tipik IoT-Fog-Cloud. Pajisjet IoT dërgojnë të dhënat në servera dhe pajisje llogaritëse më të fuqishme, për të zgjidhur probleme që kërkojnë një nivel të ulët vonese. Në këtë sistem, re janë përgjegjëse për zgjidhjen e problemeve që kërkojnë një volum të madh burimesh llogaritet apo hapësire për ruajtjen e të dhënave.
Smartfonët, orët inteligjente dhe pajisje të tjera gjithashtu mund të jenë pjesë e IoT. Por këto pajisje, zakonisht, përdorin protokolle komunikimi private nga zhvillues të mëdhenj. Të dhënat e gjeneruara nga interneti i gjërave dërgohen në nivelin e mjegullës përmes protokollit REST HTTP, i cili siguron fleksibilitet dhe përputhshmëri funksionale gjatë krijimit të shërbimeve RESTful. Kjo është e rëndësishme në dritën e nevojës për të siguruar përputhshmërinë me infrastrukturën ekzistuese të llogaritjes, e cila punon në kompjuterë lokalë, serverë ose klasterë serverësh. Burimet lokale, që quhen «në mjegull», filtrojnë të dhënat e marra dhe i përpunojnë ato lokal ose i dërgojnë në re për llogaritje të mëtejshme.
Re përkrahim protokolle të ndryshme komunikimi, ndërmjet të cilave më të zakonshmet janë AMQP dhe REST HTTP. Duke qenë 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ën?». Megjithatë, ky protokoll ka probleme me performancën. Këtë do ta shqyrtojmë më vonë.
Në përgjithësi, ekzistojnë 2 modele protokollesh të komunikimit, të përshtatshme për sistemin tonë. Këto janë modeli kërkesë-përgjigje dhe modeli publikim-pajtim. Modeli i parë është më i njohur, veçanërisht në arkitekturën server-klient. Klienti kërkon informacion nga serveri, i cili merr kërkesën, e përpunon dhe kthen një përgjigje. Këto modele funksionojnë me protokollet REST HTTP dhe CoAP.
Modeli i dytë ka lindur për të siguruar një lidhje asimetrike, të shpërndarë, të dobësuar midis burimeve që gjenerojnë të dhëna dhe marrësve të këtyre të dhënave.
Modeli përfshin tre pjesëmarrës: botuesi (burimi i të dhënave), brokeri (dispeçer) dhe abonenti (pranuesi). Këtu klienti, i cili vepron si abonent, nuk duhet të kërkojë informacion nga serveri. Në vend që të dërgojë kërkesa, ai abonohet për ngjarje të caktuara në sistem përmes brokerit, i cili është përgjegjës për filtrimin e të gjitha mesazheve hyrëse dhe ritransmetimin e tyre mes botuesve dhe abonentëve. Kur ndodh një ngjarje që lidhet me një temë të caktuar, botuesi e publikçon atë te brokeri, i cili dërgon të dhënat te abonenti për temën e kërkuar.
Në thelb, kjo arkitekturë bazohet në ngjarje. Dhe një model i tillë ndërveprimi është interesant për aplikacionet në IoT, në cloud, dhe në fog për shkak të aftësisë së saj për të siguruar shkallëzueshmëri dhe për të thjeshtuar marrëdhëniet midis pajisjeve të ndryshme, duke mbështetur komunikimin dinamik "mijëra me mijëra" dhe komunikimin asinkron. Disa nga protokollet më të njohura të standardizuara për shkëmbimin e mesazheve që përdorin modelin "publikim-abonim" janë MQTT, AMQP dhe DDS.
Është e qartë se modeli "publikim-abonim" ka shumë përfitime:
- Botuesit dhe abonentët nuk kanë nevojë të dinë për ekzistencën e njëri-tjetrit;
- Një abonent mund të marrë informacion nga shumë botues të ndryshëm, ndërsa një botues mund të dërgojë të dhëna shumë abonentëve të ndryshëm (principi "mijëra me mijëra");
- Botuesi dhe abonenti nuk janë të detyruar të jenë aktivë njëkohësisht për shkëmbejnë të dhëna, sepse brokeri (që funksionon si një sistem radhë) mund të ruajë mesazhet për klientët që në atë moment nuk janë të lidhur.
Megjithatë, modeli "kërkesë-përgjigje" ka gjithashtu pikat e tij të forta. Në rastet kur kapacitetet e anës së serverit për të përpunuar kërkesat e shumë klientëve nuk janë një problem, ka kuptim të përdoren zgjidhje të besueshme që janë provuar paraprakisht.
Ka gjithashtu protokolle që mbështesin të dy modelet. Për shembull, XMPP dhe HTTP 2.0, të cilat mbështesin opsionin "server push". IETF gjithashtu ka lëshuar CoAP. Në përpjekje për të zgjidhur problemin e shkëmbimit të mesazheve, janë krijuar disa zgjidhje të tjera, si protokolli WebSockets ose përdorimi i protokollit HTTP përmes QUIC (Quick UDP Internet Connections).
Në rastin e WebSockets, megjithëse përdoret për të transmetuar të dhëna në kohë reale nga serveri në klientin web dhe siguron lidhje të qëndrueshme me komunikim të dyanshëm, nuk është i përshtatshëm për pajisjet me burime të kufizuara kompjuterike. QUIC gjithashtu meriton vëmendje, pasi protokolli i ri tërheq shumë mundësi të reja. Por pasi që QUIC ende nuk është standardizuar, është herët të parashikojmë aplikimin dhe ndikimin e tij në zgjidhjet në fushën e IoT. Prandaj, WebSockets dhe QUIC i mbajmë në mendje për të ardhmen, por nuk do t'i shqyrtojmë më tej tani.
Kush është më i dashur në botë: krahasojmë protokollet
Tani le të flasim për pikat e forta dhe të dobëta të protokolleve. Përpara se të fillojmë, le të theksojmë se nuk ka një lider të evidentuar. Çdo protokoll ka disa avantazhe dhe disavantazhe.
Koha e përgjigjes
Një nga karakteristikat më të rëndësishme të protokolleve të komunikimit, veçanërisht në kontekstin e internetit të objekteve, është koha e përgjigjes. Por mes protokolleve ekzistues, nuk ka një fitues absolut, që tregon nivelin më të ulët të vonesës në kushte të ndryshme. Por ka shumë kërkime dhe krahasime të mundësive të protokolleve.
Për shembull, Krahasimi i eficiencës së HTTP dhe MQTT në punën me IoT ka treguar se koha e përgjigjes për kërkesat në MQTT është më e ulët se në HTTP. Ndërsa, e kohës së marrjes-dergimit (RTT) MQTT dhe CoAP rezultoi se mesatarja e RTT për CoAP është 20% më e ulët se ajo për MQTT.
E tjera me RTT të protokolleve MQTT dhe CoAP është realizuar në dy skenarë: në një rrjet lokal dhe në një rrjet IoT. Të dhënat treguan se mesatarja e RTT në rrjetin IoT ishte 2-3 herë më e lartë. MQTT me QoS0 tregoi rezultate më të ulëta në krahasim me CoAP, ndërsa MQTT me QoS1 demonstroi RTT më të lartë për shkak të ACK në nivelin aplikativ dhe transportues. Për nivelet e ndryshme QoS, vonesat në rrjetin pa mbingarkesë për MQTT ishin disa milisekonda, ndërsa për CoAP ishin qindra mikrosekonda. Megjithatë, duhet të mbani mend se në rrjete më pak të besueshme MQTT, që funksionon mbi TCP, do të tregojë rezultate krejtësisht ndryshe.
sa i përket kohës së përgjigjes të protokolleve AMQP dhe MQTT, duke rritur ngarkesën e të dhënave tregoi se në ngarkesë të vogël niveli i vonesës ishte pothuajse i njëjtë. Por gjatë transmetimit të sasisë së madhe të të dhënave, MQTT tregon një kohë përgjigjeje më të ulët. Një tjetër CoAP u krahasuar me HTTP në skenarin e komunikimit ndërmjet makinave me pajisje të vendosura në mjete dhe të pajisura me Sensore gazi, Sensore moti, pozicion (GPS) dhe ndërfaqe të rrjetit celular (GPRS). Koha e nevojshme për të dërguar një mesazh CoAP nëpërmjet rrjetit mobil ishte pothuajse tre herë më e shkurtër se koha e nevojshme për të përdorur mesazhe HTTP.
U kryen studime ku u krahasuan jo dy, por tre protokolle. Për shembull, performancën e protokolleve IoT MQTT, DDS dhe CoAP në një skenar mjekësor duke përdorur një emulator rrjeti. DDS tejkaloi MQTT në aspektin e vonesës së provuar të telemetrisë në kushte të ndryshme të këqija të rrjetit. CoAP në bazë të UDP punoi mirë për aplikacione që kërkonin një përgjigje të shpejtë, megjithatë, për shkak se bazohet në UDP, ndodhi humbje e konsiderueshme e paparashikueshme të paketave.
Kapaciteti i Kalimit
MQTT dhe CoAP në aspektin e efikasitetit të përdorimit të bandës janë bërë duke numëruar sasinë totale të të dhënave të dërguara për një mesazh. CoAP tregoi një kapacitet më të ulët se MQTT gjatë dërgimit të mesazheve të vogla. Por kur u krahasua efikasiteti i protokolleve në aspektin e raportit të sasisë së bajtëve të dobishëm ndaj sasisë totale të bajtëve të dërguar, CoAP rezultoi më efikas.
Në përdorimit të bandës nga MQTT, DDS (me TCP si protokoll transporti) dhe CoAP u zbulua se CoAP, në përgjithësi, tregonte një konsum më të ulët të bandës që nuk rritej me rritjen e humbjeve të paketave të rrjetit ose me vonesën në rrjet, në dallim nga MQTT dhe DDS, ku në skenarët e përmendur u vu re rritje e përdorimit të kapacitetit të kanalit. Në një skenar tjetër u angazhuan një numër i madh pajisjesh që dërgonin të dhëna njëkohësisht, e cila është një rast tipik në ambientet IoT. Rezultatet treguan se për ngarkesë më të lartë, CoAP ishte më i përshtatshëm.
Me ngarkesë të vogël, CoAP përdori kapacitetin më të ulët, pasuar nga MQTT dhe REST HTTP. Megjithatë, kur madhësia e ngarkesave u rrit, rezultatet më të mira ishin nga REST HTTP.
Konsum i energjisë
Çështja e konsumit të energjisë gjithmonë ka rëndësi të madhe, e sidomos në sistemet IoT. Nëse konsumimin e energjisë të MQTT dhe HTTP, HTTP "humb shumë më tepër. Ndërsa CoAP është më në krahasim me MQTT, duke lejuar menaxhimin e energjisë. Megjithatë, në skenarët e 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 për fuqinë.
Eksperimenti, në të cilin u krahasuan aftësitë e AMQP dhe MQTT në një stendë provimi të një rrjeti mobil ose të paqëndrueshëm, tregoi se AMQP ofron më shumë mundësi në aspektin e sigurisë, ndërsa MQTT është më efikas në energji.
Siguria
Siguria është një tjetër çështje shumë e rëndësishme që ngrithet gjatë studimit të temës së internetit të gjërave dhe llogaritjeve të mjeteve/cloud. Mekanizmi i sigurisë zakonisht mbështetet në TLS në HTTP, MQTT, AMQP dhe XMPP, ose DTLS në CoAP, si dhe mbështetës i të dy varianteve është DDS.
TLS dhe DTLS fillojnë me një proces negociate ndërmjet palës klient dhe palës server për të ndarë grupeve të kodimit dhe çelësat. Të dy palët bien dakord për grupet për të garantuar që komunikimi tjetër zhvillohet në një kanal të sigurt. Diferenca midis tyre përbëhet nga modifikime të vogla që lejojnë DTLS-në e bazuar në UDP të punojë në lidhje të pasigurta.
Në në disa realizime të ndryshme të TLS dhe DTLS u zbulua se TLS e kaloi më mirë këtë detyrë. Sulmet ndaj DTLS ishin më të suksesshme për shkak të tolerancës së tij ndaj gabimeve.
Megjithatë, problemi më i madh me këto protokolle është se ato fillimisht nuk ishin projektuar për përdorim në IoT dhe nuk parashikonin punën në mjete ose në cloud. Përmes shkëmbimit të rregullt (handshaking) ata shtojnë një trafik të shtuar me çdo krijim të lidhjes, çka e shteron burimet kompjuterike. Në mesatarisht, vërehet një rritje prej 6,5% për TLS dhe 11% për DTLS në ngarkesën shërbyese krahasuar me komunikimin pa nivel sigurie. Në ambientet e pasura me burime, të cilat zakonisht gjenden në këto nuk do të jenë një problem, por në lidhjen midis IoT dhe nivelit të mjeteve, kjo bëhet një kufizim i rëndësishëm.
Çfarë duhet të zgjedhim? Nuk ka një përgjigje të qartë. MQTT dhe HTTP duken si protokollet më të perspektivë, pasi konsiderohen si zgjidhje relativisht më të pjekura dhe më stabile për IoT në krahasim me protokolle të tjera.
Zgjidhjet e bazuara në një protokoll komunikimi të vetëm
Praktika e një zgjidhjeje me një protokoll ka shumë disavantazhe. Për shembull, një protokoll që është i përshtatshëm për një mjedis të kufizuar mund të mos funksionojë në një domene që ka kërkesa të rrepta për siguri. Duke marrë parasysh këtë, na mbetet të heqim dorë nga pothuajse të gjitha zgjidhjet e mundshme të bazuara në një protokoll në ekosistemin Fog-to-Cloud në IoT, përveç MQTT dhe REST HTTP.
REST HTTP si një zgjidhje me një protokoll
Ka një shembull të mirë të ndërveprimit të kërkesave dhe përgjigjeve REST HTTP në fushën e IoT-to-Fog: . Kafshët furnizohen me sensorë të veshur (klienti IoT, C) dhe menaxhohen përmes llogaritjes në cloud nga sistemi fermier inteligjent (serveri Fog, S).
Në titullin e metodës POST specifikohet burimi që do të ndryshohet (/farm/animals), si dhe versioni i HTTP dhe tipi i përmbajtjes, i cili në këtë rast është një objekt JSON që përfaqëson fermën e bagëtive që duhet të menaxhohet nga sistemi (Dulcinéa/nostalgjia). Përgjigja nga serveri tregon se kërkesa ishte e suksesshme, duke dërguar kodin e statusit HTTPS 201 (burimi është krijuar). Metoda GET duhet të specifikojë vetëm burimin e kërkuar në URI (për shembull, /farm/animals/1), që kthen një përfaqësim JSON të kafshës me këtë identifikues nga serveri.
Metoda PUT përdoret kur është e nevojshme të përditësohet një rekord specifik të burimit. Në këtë rast, në burim specifikohet URI për parametrin që do të ndryshohet dhe vlera aktuale (për shembull, që do të tregonte se loçka për momentin është duke ecur, /farm/animals/1?status=ecje). Në fund, metoda DELETE përdoret në mënyrë të ngjashme me metodën GET, por thjesht fshin burimin si rezultat i operacionit.
MQTT si një zgjidhje me një protokoll
Le të marrim po atë fermë inteligjente, por në vend të REST HTTP të përdorim protokollin MQTT. Një server lokal me bibliotekën Mosquitto të instaluar vepron si broker. Në këtë shembull, një kompjuter i thjeshtë (i quajtur si serveri i fermës) Raspberry Pi shërben si klient MQTT, i implementuar përmes instalimit të bibliotekës MQTT Paho, plotësisht të përshtatshme me brokerin Mosquitto.
Ky klient i përgjigjet nivelit të abstraksionit IoT që përfaqëson një pajisje me aftësi zbuluese dhe llogaritëse. Ndërmjetësi, nga ana tjetër, i përgjigjet një niveli më të lartë abstraksioni, duke përfaqësuar një nyje llogaritëse të mjegullës, e karakterizuar nga kapacitete më të mëdha në procesim dhe ruajtje të të dhënave.
Në skenarin e propozuar të 'fermë inteligjente', Raspberry Pi lidhet me një akselerometër, GPS dhe sensorë temperature dhe publikojnë të dhënat nga këta sensorë në nyjën e mjegullës. Siç e dini, MQTT e sheh temat si një hierarki. Një botues MQTT mund të publikojë mesazhe në një grup të caktuar temash. Në rastin tonë, ka tre. Për sensorin që mat temperaturën në stallë për kafshët, klienti zgjedh temën (animalfarm/shed/temperature). Për sensorët që masin vendndodhjen GPS dhe lëvizjen e kafshëve përmes akselerometrit, klienti publikon përditësime (animalfarm/animal/GPS) dhe (animalfarm/animal/movement).
Këto informacione do të transmetohen te brokeri, i cili mund ta ruajë atë përkohësisht në një bazë të dhënash lokale për rast se një abonues tjetër shfaqet më vonë.
Përveç serverit lokal që vepron si broker MQTT në mjegullë dhe të cilit Raspberry Pi, që vepron si klientë MQTT, dërgon të dhënat nga sensorët, në nivelin e cloud-it mund të ketë edhe një broker tjetër MQTT. Në këtë rast, informacioni që dërgohet te brokeri lokal mund të ruhet përkohësisht në një bazë të dhënash lokale dhe/ose të dërgohet në cloud. Brokeri MQTT mjegullor në këtë situatë përdoret për të lidhur të gjitha të dhënat me brokerin MQTT në cloud. Në një arkitekturë të tillë, përdoruesi i aplikacionit mobil mund të abonohet te të dy brokerët.
Në rast se ka një dështim të lidhjes me një nga brokerët (për shembull, atë në cloud), përdoruesi përfundimtar do të marrë informacion nga tjetri (mjegullor). Kjo është një veçori karakteristike e sistemeve të kombinuara të mjegullës dhe llogaritjeve në cloud. Pas skemës, aplikacioni mobil mund të konfigurohet të lidhët fillimisht me brokerin MQTT mjegullor, dhe në rast dështimi, të lidhet me brokerin MQTT në cloud. Kjo zgjidhje është vetëm një nga shumë në sistemet IoT-F2C.
Zgjidhje me shumë protokolle
Zgjidhjet me një protokoll janë popullore për shkak të lehtësisë së implementimit të tyre. Por është e qartë se në sistemet IoT-F2C ka kuptim të kombinohen protokolle të ndryshme. Ideja është se në nivele të ndryshme mund të operojnë protokolle të ndryshme. Merrni për shembull tre abstraksione: nivelet IoT, mjegull dhe computing në re. Pajisjet në nivelin IoT zakonisht konsiderohen si të kufizuara. Për këtë përmbledhje, le të shqyrtojmë nivelet IoT si më të kufizuara, mjegullat si më pak të kufizuara dhe computing në re si "diku në mes". Kështu, midis IoT dhe abstraksioneve të mjegullës, zgjidhjet aktuale të protokollit përfshijnë MQTT, CoAP dhe XMPP. Nga ana tjetër, midis mjegullës dhe re, AMQP është një nga protokollet kryesore që përdoren së bashku me REST HTTP, i cili për shkak të fleksibilitetit të tij gjithashtu përdoret midis IoT dhe shtresave të mjegullës.
Problemi kryesor këtu është përputhshmëria funksionale e protokolleve dhe lehtësia e transferimit të mesazheve nga një protokoll në tjetrin. Në mënyrë ideale, në të ardhmen, arkitektura e sistemit të internetit të gjërave me burime në re dhe mjegull do të jetë e pavarur nga protokolli i komunikimit që përdoret dhe do të sigurojë bashkëpunim të mirë mes protokolleve të ndryshme.
Tani për tani, kjo nuk është kështu, ka kuptim të kombinohen protokolle pa dallime të rëndësishme. Me këtë qëllim, një zgjidhje e mundshme bazohet në kombinimin e dy protokolleve që ndjekin të njëjtin stil arkitekturor, REST HTTP dhe CoAP. Një tjetër zgjidhje e propozuar është bazuar në kombinimin e dy protokolleve që ofrojnë ndërveprimin sipas modelit 'publikim-abonim', MQTT dhe AMQP. Përdorimi i koncepteve të ngjashme (të dy MQTT dhe AMQP përdorin brokerë, ndërsa CoAP dhe HTTP përdorin REST), e lehtëson implementimin e këtyre kombinimeve dhe kërkon më pak përpjekje për integrimin.
Në figurën (a) paraqiten dy modele të bazuara në kërkesat-पërgjigjet, HTTP dhe CoAP, dhe mundësia e vendosjes së tyre në zgjidhjen IoT-F2C. Duke qenë se HTTP është një nga protokollet më të njohura dhe të adaptuara në rrjetet moderne, është pak e mundur që ai të zëvendësohet krejtësisht nga protokolle të tjera të komunikimit. Ndër grupe, që përfaqësojnë pajisje të fuqishme, që janë midis re dhe mjegullës, REST HTTP është një zgjidhje e arsyeshme.
Nga ana tjetër, për pajisjet me burime të kufizuara llogaritëse, që lidhen midis niveleve të mjegullës dhe IoT, është më efikase të përdoret CoAP. Një nga përfitimet e mëdha të CoAP është në fakt përputhshmëria e tij me HTTP, pasi të dy protokollet janë të bazuara në principet e REST.
Në figurën (b) paraqiten dy modele ndërveprimi 'publikim-abonim' në një skenar, duke përfshirë MQTT dhe AMQP. Ndërsa hipotetikisht të dy protokollet mund të përdoren për komunikimin midis nyjeve në çdo nivel abstraksioni, pozita e tyre duhet të përcaktohet në bazë të performancës. MQTT është zhvilluar si një protokoll i thjeshtuar për pajisje me burime të kufizuara llogaritëse, kështu që mund të përdoret për komunikimin midis IoT dhe mjegullës. AMQP është më i përshtatshëm për pajisje më të fuqishme, që do ta vendosnin atë midis nyjeve të mjegullës dhe re. Në vend të MQTT në IoT mund të përdoret protokolli XMPP, pasi konsiderohet si i lehtë. Por ai nuk përdoret aq gjerësisht në skenarë të tillë.
Përfundimet
Është pak e mundur që një nga protokollet e shqyrtuara të jetë e mjaftueshme për të mbuluar gjithë komunikimin në sistem, duke filluar nga pajisjet me burime të kufizuara deri te serverët e re. Studiimi ka treguar se dy opsionet më premtuese, që përdoren më shpesh nga zhvilluesit, janë MQTT dhe RESTful HTTP. Këto dy protokolle janë jo vetëm më të pjekurat dhe të qëndrueshmet, por përfshijnë gjithashtu shumë implementime të dokumentuara mirë dhe burime online të suksesshme.
Për shkak të stabilitetit të tij dhe konfigurimit të lehtë, MQTT është protokolli që me kalimin e kohës ka treguar performancë të shkëlqyer në përdorimin në nivelin IoT me pajisje të kufizuara. Në pjesët e sistemit, ku lidhja e kufizuar dhe konsumimi i baterisë nuk janë problem, për shembull, në disa fusha të mjegullës dhe në shumicën e llogaritjeve në re, RESTful HTTP është një zgjedhje e thjeshtë. CoAP gjithashtu duhet të merret parasysh, pasi po zhvillohet gjithashtu me shpejtësi si një standard i shkëmbimit të mesazheve IoT, dhe është shumë e mundur që në të ardhmen e afërt të arrijë një nivel stabiliteti dhe pjekurie të ngjashëm me MQTT dhe HTTP. Por standardi tani është duke u zhvilluar, çka sjell problemet e shkallëzueshmërisë afatshkurtra.
Çfarë tjetër të dobishme mund të lexoni në blog
→
→
→
→
→
Regjistrohuni në kanalin tonë -kanali, për të mos humbur artikujt tanë të rinj! Shkruajmë jo më shpesh se dy herë në javë dhe vetëm për çështje të rëndësishme.
Burimi: habr.com
