Maendeleo ya teknolojia katika uwanja wa programu na vifaa, kuibuka kwa itifaki mpya za mawasiliano kumesababisha upanuzi wa Mtandao wa Mambo (IoT). Idadi ya vifaa inaongezeka siku baada ya siku na vinazalisha kiasi kikubwa cha data. Kwa hiyo, kuna haja ya usanifu wa mfumo rahisi wenye uwezo wa usindikaji, kuhifadhi na kusambaza data hii.
Sasa huduma za wingu hutumiwa kwa madhumuni haya. Walakini, dhana ya kompyuta ya ukungu inayozidi kuwa maarufu (Ukungu) inaweza kukamilisha suluhisho la wingu kwa kuongeza na kuboresha miundombinu ya IoT.
Clouds ina uwezo wa kushughulikia maombi mengi ya IoT. Kwa mfano, kutoa ufuatiliaji wa huduma, usindikaji wa haraka wa kiasi chochote cha data inayozalishwa na vifaa, pamoja na taswira yao. Kompyuta ya ukungu inafaa zaidi wakati wa kutatua shida za wakati halisi. Hutoa majibu ya haraka kwa maombi na ucheleweshaji mdogo katika usindikaji wa data. Hiyo ni, ukungu hukamilisha "mawingu" na kupanua uwezo wake.
Walakini, swali kuu ni tofauti: haya yote yanapaswa kuingiliana vipi katika muktadha wa IoT? Ni itifaki gani za mawasiliano zitakuwa na ufanisi zaidi wakati wa kufanya kazi katika mfumo wa pamoja wa IoT-Fog-Cloud?
Licha ya kutawala kwa HTTP, kuna idadi kubwa ya suluhisho zingine zinazotumiwa katika mifumo ya IoT, Fog na Cloud. Hii ni kwa sababu IoT lazima ichanganye utendakazi wa aina mbalimbali za vitambuzi vya kifaa na usalama, uoanifu na mahitaji mengine ya watumiaji.
Lakini hakuna wazo moja tu juu ya usanifu wa kumbukumbu na kiwango cha mawasiliano. Kwa hiyo, kuunda itifaki mpya au kurekebisha iliyopo kwa ajili ya kazi maalum za IoT ni mojawapo ya kazi muhimu zaidi zinazokabili jumuiya ya IT.
Ni itifaki gani zinazotumika kwa sasa na zinaweza kutoa nini? Hebu tufikirie. Lakini kwanza, hebu tujadili kanuni za mfumo wa ikolojia ambamo mawingu, ukungu na mtandao wa mambo huingiliana.
Usanifu wa IoT Fog-to-Cloud (F2C).
Labda umegundua ni juhudi ngapi zinawekwa katika kuchunguza faida na manufaa yanayohusiana na usimamizi mahiri na ulioratibiwa wa IoT, wingu na ukungu. Ikiwa sivyo, basi hapa kuna mipango mitatu ya kusawazisha: , ΠΈ .
Ikiwa hapo awali viwango 2 tu vilizingatiwa, mawingu na vifaa vya mwisho, basi usanifu uliopendekezwa huanzisha kiwango kipya - kompyuta ya ukungu. Katika kesi hii, kiwango cha ukungu kinaweza kugawanywa katika viwango vidogo kadhaa, kulingana na maalum ya rasilimali au seti ya sera zinazoamua matumizi ya vifaa tofauti katika viwango vidogo hivi.
Je, uondoaji huu unaweza kuonekanaje? Hapa kuna mfumo wa ikolojia wa kawaida wa IoT-Fog-Cloud. Vifaa vya IoT hutuma data kwa seva zenye kasi zaidi na vifaa vya kompyuta ili kutatua matatizo ambayo yanahitaji muda wa chini wa kusubiri. Katika mfumo huo huo, mawingu ni wajibu wa kutatua matatizo ambayo yanahitaji kiasi kikubwa cha rasilimali za kompyuta au nafasi ya kuhifadhi data.
Simu mahiri, saa mahiri na vifaa vingine vinaweza pia kuwa sehemu ya IoT. Lakini vifaa kama hivyo, kama sheria, hutumia itifaki za mawasiliano ya wamiliki kutoka kwa watengenezaji wakubwa. Data iliyozalishwa ya IoT huhamishiwa kwenye safu ya ukungu kupitia itifaki ya REST HTTP, ambayo hutoa kunyumbulika na ushirikiano wakati wa kuunda huduma za RESTful. Hii ni muhimu kwa kuzingatia hitaji la kuhakikisha upatanifu wa nyuma na miundombinu ya kompyuta iliyopo kwenye kompyuta za ndani, seva au nguzo ya seva. Rasilimali za ndani, zinazoitwa "nodi za ukungu," huchuja data iliyopokelewa na kuichakata ndani ya nchi au kuituma kwa wingu kwa hesabu zaidi.
Clouds hutumia itifaki tofauti za mawasiliano, inayojulikana zaidi ni AMQP na REST HTTP. Kwa kuwa HTTP inajulikana sana na iliyoundwa kwa ajili ya Mtandao, swali linaweza kutokea: "Je! hatupaswi kuitumia kufanya kazi na IoT na ukungu?" Hata hivyo, itifaki hii ina masuala ya utendaji. Zaidi juu ya hili baadaye.
Kwa ujumla, kuna mifano 2 ya itifaki za mawasiliano zinazofaa kwa mfumo tunaohitaji. Haya ni majibu ya ombi na uchapishe-jisajili. Mfano wa kwanza unajulikana zaidi, haswa katika usanifu wa mteja wa seva. Mteja huomba habari kutoka kwa seva, na seva inapokea ombi, inashughulikia na kurudisha ujumbe wa majibu. Itifaki za REST HTTP na CoAP zinafanya kazi kwenye muundo huu.
Mfano wa pili uliibuka kutoka kwa hitaji la kutoa unganisho usio na usawa, uliosambazwa, huru kati ya vyanzo vinavyozalisha data na wapokeaji wa data hii.
Mfano huo unachukua washiriki watatu: mchapishaji (chanzo cha data), wakala (mtangazaji) na msajili (mpokeaji). Hapa, mteja anayefanya kama mteja sio lazima aombe habari kutoka kwa seva. Badala ya kutuma maombi, inajiandikisha kwa matukio fulani katika mfumo kwa njia ya wakala, ambayo ina jukumu la kuchuja ujumbe wote unaoingia na kuwaelekeza kati ya wachapishaji na waliojisajili. Na mchapishaji, tukio linapotokea kuhusu mada fulani, huichapisha kwa wakala, ambayo hutuma data juu ya mada iliyoombwa kwa msajili.
Kimsingi, usanifu huu unategemea matukio. Na mtindo huu wa mwingiliano ni wa kuvutia kwa programu katika IoT, wingu, ukungu kwa sababu ya uwezo wake wa kutoa scalability na kurahisisha muunganisho kati ya vifaa tofauti, kusaidia mawasiliano ya wengi-kwa-nyingi na mawasiliano asynchronous. Baadhi ya itifaki sanifu zinazojulikana zaidi zinazotumia muundo wa uchapishaji wa uchapishaji ni pamoja na MQTT, AMQP na DDS.
Ni wazi, mtindo wa uchapishaji wa uchapishaji una faida nyingi:
- Wachapishaji na waandikishaji hawana haja ya kujua kuhusu kuwepo kwa kila mmoja;
- Msajili mmoja anaweza kupokea taarifa kutoka kwa machapisho mengi tofauti, na mchapishaji mmoja anaweza kutuma data kwa waliojisajili wengi tofauti (kanuni ya wengi hadi wengi);
- Mchapishaji na mteja si lazima wawe hai kwa wakati mmoja ili kuwasiliana, kwa sababu wakala (anayefanya kazi kama mfumo wa kupanga foleni) ataweza kuhifadhi ujumbe kwa wateja ambao hawajaunganishwa kwenye mtandao kwa sasa.
Walakini, mfano wa kujibu ombi pia una nguvu zake. Katika hali ambapo uwezo wa upande wa seva kushughulikia maombi mengi ya mteja sio suala, ni jambo la busara kutumia masuluhisho yaliyothibitishwa na ya kuaminika.
Pia kuna itifaki zinazounga mkono mifano yote miwili. Kwa mfano, XMPP na HTTP 2.0, ambayo inasaidia chaguo la "kusukuma kwa seva". IETF pia imetoa CoAP. Katika kujaribu kutatua tatizo la utumaji ujumbe, suluhu zingine kadhaa zimeundwa, kama vile itifaki ya WebSockets au matumizi ya itifaki ya HTTP kupitia QUIC (Miunganisho ya Mtandao ya UDP ya Haraka).
Kwa upande wa WebSockets, ingawa inatumika kuhamisha data kwa wakati halisi kutoka kwa seva hadi kwa mteja wa wavuti na hutoa miunganisho inayoendelea na mawasiliano ya pande mbili kwa wakati mmoja, haikusudiwi kwa vifaa vilivyo na rasilimali chache za kompyuta. QUIC pia inastahili kuzingatiwa, kwa kuwa itifaki mpya ya usafiri inatoa fursa nyingi mpya. Lakini kwa kuwa QUIC bado haijasawazishwa, ni mapema kutabiri utumiaji wake unaowezekana na athari kwenye suluhisho za IoT. Kwa hivyo tunaweka WebSockets na QUIC akilini kwa kutazama siku zijazo, lakini hatutaisoma kwa undani zaidi kwa sasa.
Nani ni mrembo zaidi ulimwenguni: kulinganisha itifaki
Sasa hebu tuzungumze juu ya nguvu na udhaifu wa itifaki. Kuangalia mbele, hebu tufanye uhakikisho mara moja kwamba hakuna kiongozi aliye wazi. Kila itifaki ina faida/hasara fulani.
Wakati wa kujibu
Moja ya sifa muhimu zaidi za itifaki za mawasiliano, hasa kuhusiana na Mtandao wa Mambo, ni muda wa majibu. Lakini kati ya itifaki zilizopo, hakuna mshindi wazi ambaye anaonyesha kiwango cha chini cha latency wakati wa kufanya kazi chini ya hali tofauti. Lakini kuna rundo zima la utafiti na kulinganisha uwezo wa itifaki.
Kwa mfano, ulinganisho wa ufanisi wa HTTP na MQTT wakati wa kufanya kazi na IoT ulionyesha kuwa muda wa majibu kwa maombi ya MQTT ni mdogo kuliko kwa HTTP. Na lini Muda wa safari ya kwenda na kurudi (RTT) wa MQTT na CoAP ulifichua kuwa wastani wa RTT wa CoAP ni 20% chini ya ule wa MQTT.
Nyingine na RTT kwa itifaki za MQTT na CoAP ilifanyika katika hali mbili: mtandao wa ndani na mtandao wa IoT. Ilibadilika kuwa wastani wa RTT ni mara 2-3 zaidi katika mtandao wa IoT. MQTT yenye QoS0 ilionyesha matokeo ya chini ikilinganishwa na CoAP, na MQTT yenye QoS1 ilionyesha RTT ya juu kutokana na ACKs kwenye tabaka za maombi na usafiri. Kwa viwango tofauti vya QoS, muda wa kusubiri wa mtandao bila msongamano ulikuwa milisekunde kwa MQTT, na mamia ya sekunde ndogo kwa CoAP. Walakini, inafaa kukumbuka kuwa wakati wa kufanya kazi kwenye mitandao isiyoaminika, MQTT inayoendesha juu ya TCP itaonyesha matokeo tofauti kabisa.
muda wa majibu kwa itifaki za AMQP na MQTT kwa kuongeza mzigo wa malipo ulionyesha kuwa kwa mzigo mdogo kiwango cha kusubiri kinakaribia sawa. Lakini wakati wa kuhamisha kiasi kikubwa cha data, MQTT inaonyesha muda mfupi wa majibu. katika moja zaidi CoAP ililinganishwa na HTTP katika hali ya mawasiliano ya mashine hadi mashine na vifaa vilivyowekwa juu ya magari yaliyo na vitambuzi vya gesi, vitambuzi vya hali ya hewa, vitambuzi vya eneo (GPS) na kiolesura cha mtandao wa simu (GPRS). Muda unaohitajika kutuma ujumbe wa CoAP kwenye mtandao wa simu ulikuwa mfupi mara tatu zaidi ya muda unaohitajika kutumia ujumbe wa HTTP.
Uchunguzi umefanywa ambao haulinganishwi mbili, lakini itifaki tatu. Kwa mfano, utendaji wa itifaki za IoT MQTT, DDS na CoAP katika hali ya maombi ya matibabu kwa kutumia emulator ya mtandao. DDS ilifanya vyema zaidi MQTT katika suala la muda uliojaribiwa wa telemetry chini ya hali mbalimbali duni za mtandao. UDP-msingi CoAP ilifanya kazi vizuri kwa programu ambazo zilihitaji nyakati za majibu ya haraka, hata hivyo, kutokana na kuwa msingi wa UDP, kulikuwa na upotevu mkubwa wa pakiti usiotabirika.
Mbinu
MQTT na CoAP katika suala la ufanisi wa kipimo data ilifanywa kama hesabu ya jumla ya data iliyopitishwa kwa kila ujumbe. CoAP imeonyesha uwezo wa chini zaidi kuliko MQTT wakati wa kutuma ujumbe mdogo. Lakini wakati wa kulinganisha ufanisi wa itifaki kwa suala la uwiano wa idadi ya byte za habari muhimu kwa jumla ya kaiti zilizohamishwa, CoAP iligeuka kuwa yenye ufanisi zaidi.
Katika kwa kutumia MQTT, DDS (iliyo na TCP kama itifaki ya usafiri) na kipimo data cha CoAP, ilibainika kuwa CoAP kwa ujumla ilionyesha matumizi ya chini ya kipimo data, ambayo hayakuongezeka kwa upotevu wa pakiti za mtandao au kuongezeka kwa kasi ya mtandao, tofauti na MQTT na DDS, ambapo kulikuwa na ongezeko la matumizi ya bandwidth katika matukio yaliyotajwa. Hali nyingine ilihusisha idadi kubwa ya vifaa vinavyosambaza data kwa wakati mmoja, ambayo ni ya kawaida katika mazingira ya IoT. Matokeo yalionyesha kuwa kwa matumizi ya juu ni bora kutumia CoAP.
Chini ya upakiaji mwepesi, CoAP ilitumia kipimo data kidogo zaidi, ikifuatiwa na MQTT na REST HTTP. Hata hivyo, wakati ukubwa wa mizigo uliongezeka, REST HTTP ilikuwa na matokeo bora zaidi.
Matumizi ya Nguvu
Suala la matumizi ya nishati daima ni muhimu sana, na haswa katika mfumo wa IoT. Kama Ingawa MQTT na HTTP hutumia umeme, HTTP hutumia zaidi. Na CoAP ni zaidi ikilinganishwa na MQTT, kuruhusu usimamizi wa nguvu. Hata hivyo, katika hali rahisi, MQTT inafaa zaidi kwa kubadilishana habari katika mitandao ya Mtandao wa Mambo, hasa ikiwa hakuna vikwazo vya nguvu.
Jaribio lililolinganisha uwezo wa AMQP na MQTT kwenye mtandao wa simu au usio thabiti wa mtandao wa wireless testbed iligundua kuwa AMQP inatoa uwezo zaidi wa usalama huku MQTT ikiwa na matumizi bora ya nishati.
usalama
Usalama ni suala lingine muhimu lililoibuliwa wakati wa kusoma mada ya Mtandao wa Mambo na kompyuta ya ukungu/wingu. Utaratibu wa usalama kwa kawaida hutegemea TLS katika HTTP, MQTT, AMQP na XMPP, au DTLS katika CoAP, na hutumia vibadala vyote viwili vya DDS.
TLS na DTLS huanza na mchakato wa kuanzisha mawasiliano kati ya mteja na pande za seva ili kubadilishana suti na funguo za cipher zinazotumika. Pande zote mbili hujadiliana seti ili kuhakikisha kwamba mawasiliano zaidi yanatokea kwenye njia salama. Tofauti kati ya hizi mbili iko katika marekebisho madogo ambayo huruhusu DTLS yenye msingi wa UDP kufanya kazi kwenye muunganisho usiotegemewa.
Katika Utekelezaji kadhaa tofauti wa TLS na DTLS uligundua kuwa TLS ilifanya kazi nzuri zaidi. Mashambulizi kwenye DTLS yalifanikiwa zaidi kutokana na uvumilivu wake wa makosa.
Walakini, shida kubwa ya itifaki hizi ni kwamba hazikuundwa kwa matumizi katika IoT na hazikusudiwa kufanya kazi kwenye ukungu au wingu. Kupitia kupeana mikono, huongeza trafiki ya ziada kwa kila uanzishaji wa muunganisho, ambao huondoa rasilimali za kompyuta. Kwa wastani, kuna ongezeko la 6,5% kwa TLS na 11% kwa DTLS kwa malipo ya ziada ikilinganishwa na mawasiliano bila safu ya usalama. Katika mazingira ya utajiri wa rasilimali, ambayo kwa kawaida iko kiwango, hii haitakuwa tatizo, lakini katika uhusiano kati ya IoT na kiwango cha ukungu, hii inakuwa kizuizi muhimu.
Nini cha kuchagua? Hakuna jibu wazi. MQTT na HTTP zinaonekana kuwa itifaki za kuahidi zaidi kwani zinachukuliwa kuwa suluhu za IoT zilizokomaa na thabiti zaidi ikilinganishwa na itifaki zingine.
Suluhisho kulingana na itifaki ya mawasiliano iliyounganishwa
Mazoezi ya ufumbuzi wa itifaki moja ina hasara nyingi. Kwa mfano, itifaki inayolingana na mazingira yenye vikwazo inaweza isifanye kazi katika kikoa ambacho kina mahitaji madhubuti ya usalama. Kwa kuzingatia hili, tumesalia kutupa takriban masuluhisho yote yanayowezekana ya itifaki moja katika mfumo ikolojia wa Fog-to-Cloud katika IoT, isipokuwa MQTT na REST HTTP.
REST HTTP kama suluhisho la itifaki moja
Kuna mfano mzuri wa jinsi maombi na majibu ya REST HTTP yanavyoingiliana katika nafasi ya IoT-to-Fog: . Wanyama hao wana vihisi vinavyoweza kuvaliwa (mteja wa IoT, C) na kudhibitiwa kupitia kompyuta ya wingu na mfumo mahiri wa kilimo (Seva ya ukungu, S).
Kijajuu cha mbinu ya POST hubainisha nyenzo ya kurekebisha (/shamba/wanyama) pamoja na toleo la HTTP na aina ya maudhui, ambayo katika hali hii ni kifaa cha JSON kinachowakilisha ufugaji wa wanyama ambao mfumo unapaswa kudhibiti (Dulcinea/ng'ombe) . Jibu kutoka kwa seva linaonyesha kuwa ombi lilifanikiwa kwa kutuma msimbo wa hali ya HTTPS 201 (rasilimali imeundwa). Mbinu ya GET lazima ibainishe tu nyenzo iliyoombwa katika URI (kwa mfano, /farm/animals/1), ambayo inarejesha uwakilishi wa JSON wa mnyama aliye na kitambulisho hicho kutoka kwa seva.
Mbinu ya PUT inatumika wakati rekodi fulani ya rasilimali inahitaji kusasishwa. Katika hali hii, rasilimali inabainisha URI kwa kigezo kubadilishwa na thamani ya sasa (kwa mfano, kuonyesha kwamba ng'ombe anatembea kwa sasa, /farm/animals/1? state=walking). Hatimaye, njia ya DELETE inatumiwa sawa na njia ya GET, lakini inafuta tu rasilimali kama matokeo ya uendeshaji.
MQTT kama suluhisho la itifaki moja
Hebu tuchukue shamba hilo hilo mahiri, lakini badala ya REST HTTP tunatumia itifaki ya MQTT. Seva ya ndani iliyo na maktaba ya Mosquitto iliyosakinishwa hufanya kazi kama wakala. Katika mfano huu, kompyuta rahisi (inayojulikana kama seva ya shamba) Raspberry Pi hutumika kama mteja wa MQTT, inayotekelezwa kupitia usakinishaji wa maktaba ya Paho MQTT, ambayo inaendana kikamilifu na wakala wa Mbu.
Kiteja hiki kinalingana na safu ya uondoaji ya IoT inayowakilisha kifaa chenye uwezo wa kuhisi na wa kompyuta. Mpatanishi, kwa upande mwingine, inalingana na kiwango cha juu cha uondoaji, kinachowakilisha node ya kompyuta ya ukungu inayojulikana na uwezo mkubwa wa usindikaji na kuhifadhi.
Katika hali ya shamba mahiri inayopendekezwa, Raspberry Pi huunganisha kwenye kipima kasi, GPS na vitambuzi vya halijoto na kuchapisha data kutoka kwa vitambuzi hivi hadi kwenye nodi ya ukungu. Kama unavyojua, MQTT huchukulia mada kama daraja. Mchapishaji mmoja wa MQTT anaweza kuchapisha ujumbe kwa seti maalum ya mada. Kwa upande wetu kuna tatu kati yao. Kwa kihisi kinachopima halijoto katika ghala la wanyama, mteja huchagua mandhari (shamba la wanyama/mwaga/joto). Kwa vitambuzi vinavyopima eneo la GPS na mwendo wa wanyama kupitia kipima kasi, mteja atachapisha masasisho kwa (shamba la wanyama/mnyama/GPS) na (shamba la wanyama/mnyama/mwendo).
Taarifa hizi zitatumwa kwa wakala, ambaye anaweza kuzihifadhi kwa muda katika hifadhidata ya ndani iwapo mteja mwingine anayevutiwa atakuja baadaye.
Mbali na seva ya ndani, ambayo hufanya kazi kama wakala wa MQTT kwenye ukungu na ambayo Raspberry Pis, inayofanya kazi kama wateja wa MQTT, hutuma data ya kihisi, kunaweza kuwa na wakala mwingine wa MQTT katika kiwango cha wingu. Katika hali hii, taarifa zinazotumwa kwa wakala wa ndani zinaweza kuhifadhiwa kwa muda katika hifadhidata ya ndani na/au kutumwa kwa wingu. Dalali wa MQTT wa ukungu katika hali hii hutumiwa kuhusisha data zote na wakala wa MQTT wa wingu. Kwa usanifu huu, mtumiaji wa programu ya simu anaweza kujiandikisha kwa mawakala wote wawili.
Ikiwa uunganisho kwa mmoja wa mawakala (kwa mfano, wingu) unashindwa, mtumiaji wa mwisho atapokea taarifa kutoka kwa mwingine (ukungu). Hii ni kipengele cha tabia ya mifumo ya pamoja ya ukungu na kompyuta ya wingu. Kwa chaguo-msingi, programu ya simu inaweza kusanidiwa kuunganisha kwa wakala wa MQTT wa ukungu kwanza, na ikiwa hiyo itashindikana, kuunganisha kwa wakala wa MQTT wa wingu. Suluhisho hili ni moja tu ya mengi katika mifumo ya IoT-F2C.
Ufumbuzi wa itifaki nyingi
Suluhisho za itifaki moja ni maarufu kwa sababu ya utekelezaji wao rahisi. Lakini ni wazi kuwa katika mifumo ya IoT-F2C inafanya akili kuchanganya itifaki tofauti. Wazo ni kwamba itifaki tofauti zinaweza kufanya kazi katika viwango tofauti. Chukua, kwa mfano, vifupisho vitatu: tabaka za IoT, ukungu na kompyuta ya wingu. Vifaa katika kiwango cha IoT kwa ujumla huchukuliwa kuwa na ukomo. Kwa muhtasari huu, wacha tuzingatie viwango vya IoT kama vilivyozuiliwa zaidi, funika kiwango cha chini cha kizuizi, na kompyuta ya ukungu kama "mahali fulani katikati." Inabadilika kuwa kati ya IoT na uondoaji wa ukungu, suluhisho za sasa za itifaki ni pamoja na MQTT, CoAP na XMPP. Kati ya ukungu na wingu, kwa upande mwingine, AMQP ni mojawapo ya itifaki kuu zinazotumiwa, pamoja na REST HTTP, ambayo kutokana na kubadilika kwake pia hutumiwa kati ya IoT na tabaka za ukungu.
Tatizo kuu hapa ni ushirikiano wa itifaki na urahisi wa kuhamisha ujumbe kutoka kwa itifaki moja hadi nyingine. Kwa hakika, katika siku zijazo, usanifu wa mfumo wa Mtandao wa Mambo na rasilimali za wingu na ukungu utakuwa huru kwa itifaki ya mawasiliano inayotumiwa na itahakikisha ushirikiano mzuri kati ya itifaki tofauti.
Kwa kuwa hii sio sasa, ni mantiki kuchanganya itifaki ambazo hazina tofauti kubwa. Ili kufikia mwisho huu, suluhisho moja linalowezekana linatokana na mchanganyiko wa itifaki mbili zinazofuata mtindo sawa wa usanifu, REST HTTP na CoAP. Suluhisho lingine linalopendekezwa linatokana na mchanganyiko wa itifaki mbili zinazotoa mawasiliano ya kuchapisha, MQTT na AMQP. Kutumia dhana zinazofanana (vyote MQTT na AMQP hutumia vidalali, CoAP na HTTP hutumia REST) ββββhufanya michanganyiko hii iwe rahisi kutekeleza na inahitaji juhudi kidogo ya ujumuishaji.
Kielelezo (a) kinaonyesha miundo miwili kulingana na ombi, HTTP na CoAP, na uwezekano wa kuwekwa katika suluhisho la IoT-F2C. Kwa kuwa HTTP ni mojawapo ya itifaki zinazojulikana zaidi na zilizopitishwa kwenye mitandao ya kisasa, hakuna uwezekano kwamba itabadilishwa kabisa na itifaki nyingine za ujumbe. Miongoni mwa nodi zinazowakilisha vifaa vyenye nguvu ambavyo hukaa kati ya wingu na ukungu, REST HTTP ni suluhisho mahiri.
Kwa upande mwingine, kwa vifaa vilivyo na rasilimali chache za kompyuta zinazowasiliana kati ya safu za Fog na IoT, ni bora zaidi kutumia CoAP. Mojawapo ya faida kubwa za CoAP ni utangamano wake na HTTP, kwani itifaki zote mbili zinategemea kanuni za REST.
Kielelezo (b) kinaonyesha miundo miwili ya mawasiliano ya uchapishaji-kusajili katika hali sawa, ikijumuisha MQTT na AMQP. Ingawa itifaki zote mbili zinaweza kutumiwa kimawazo kwa mawasiliano kati ya vifundo katika kila safu ya uondoaji, nafasi yao inapaswa kuamuliwa kulingana na utendakazi. MQTT iliundwa kama itifaki nyepesi kwa vifaa vilivyo na rasilimali chache za kompyuta, kwa hivyo inaweza kutumika kwa mawasiliano ya IoT-Fog. AMQP inafaa zaidi kwa vifaa vyenye nguvu zaidi, ambavyo vinaweza kuiweka kati ya ukungu na nodi za wingu. Badala ya MQTT, itifaki ya XMPP inaweza kutumika katika IoT kwani inachukuliwa kuwa nyepesi. Lakini haitumiwi sana katika hali kama hizi.
Matokeo
Haiwezekani kwamba moja ya itifaki zilizojadiliwa zitatosha kufunika mawasiliano yote katika mfumo, kutoka kwa vifaa vilivyo na rasilimali ndogo ya kompyuta hadi seva za wingu. Utafiti huo uligundua kuwa chaguo mbili za kuahidi zaidi ambazo wasanidi hutumia zaidi ni MQTT na RESTful HTTP. Itifaki hizi mbili sio tu zilizokomaa zaidi na dhabiti, lakini pia zinajumuisha utekelezwaji na rasilimali nyingi za mtandaoni zilizohifadhiwa vizuri na zilizofanikiwa.
Kwa sababu ya uthabiti na usanidi wake rahisi, MQTT ni itifaki ambayo imethibitisha utendakazi wake bora kwa wakati inapotumiwa katika kiwango cha IoT na vifaa vichache. Katika sehemu za mfumo ambapo mawasiliano machache na matumizi ya betri si tatizo, kama vile baadhi ya vikoa vya ukungu na kompyuta nyingi za wingu, RESTful HTTP ni chaguo rahisi. CoAP inapaswa pia kutiliwa maanani kwani inabadilika kwa kasi pia kama kiwango cha utumaji ujumbe cha IoT na kuna uwezekano kwamba itafikia kiwango cha uthabiti na ukomavu sawa na MQTT na HTTP katika siku za usoni. Lakini kiwango kwa sasa kinabadilika, ambacho kinakuja na masuala ya utangamano ya muda mfupi.
Nini kingine unaweza kusoma kwenye blogi?
β
β
β
β
β
Jiandikishe kwa yetu -channel, ili usikose makala inayofuata! Hatuandiki zaidi ya mara mbili kwa wiki na kwa biashara tu.
Chanzo: mapenzi.com