IoT၊ မြူနှင့် တိမ်များ- နည်းပညာအကြောင်း ပြောကြရအောင်။

ဆော့ဖ်ဝဲလ်နှင့် ဟာ့ဒ်ဝဲနယ်ပယ်တွင် နည်းပညာများ ဖွံ့ဖြိုးတိုးတက်လာခြင်း၊ ဆက်သွယ်ရေးပရိုတိုကောအသစ်များ ပေါ်ပေါက်လာခြင်းသည် Internet of Things (IoT) ကို ချဲ့ထွင်လာစေသည်။ စက်ပစ္စည်းများ၏ အရေအတွက်သည် တစ်နေ့ထက်တစ်နေ့ တိုးပွားလာနေပြီး ၎င်းတို့သည် ဒေတာပမာဏများစွာကို ဖန်တီးလျက်ရှိသည်။ ထို့ကြောင့်၊ ဤဒေတာကို စီမံဆောင်ရွက်ခြင်း၊ သိမ်းဆည်းခြင်းနှင့် ပို့လွှတ်နိုင်သည့် အဆင်ပြေသော စနစ်တည်ဆောက်ပုံတစ်ခု လိုအပ်ပါသည်။

ယခုအခါ ဤရည်ရွယ်ချက်များအတွက် cloud ဝန်ဆောင်မှုများကို အသုံးပြုပါသည်။ သို့သော်၊ ပိုမိုရေပန်းစားလာသော မြူကွန်ပြူတာဆိုင်ရာ ပါရာဒိုင်း (Fog) သည် IoT အခြေခံအဆောက်အအုံကို ချဲ့ထွင်ခြင်းနှင့် အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်ခြင်းဖြင့် cloud ဖြေရှင်းချက်များကို ဖြည့်စွမ်းပေးနိုင်ပါသည်။

Cloud များသည် IoT တောင်းဆိုမှုအများစုကို ဖုံးအုပ်ပေးနိုင်သည်။ ဥပမာအားဖြင့်၊ ဝန်ဆောင်မှုများကို စောင့်ကြည့်ခြင်း၊ စက်ပစ္စည်းများမှ ထုတ်ပေးသည့် မည်သည့်ဒေတာပမာဏကိုမဆို လျင်မြန်စွာလုပ်ဆောင်ခြင်းအပြင် ၎င်းတို့၏ အမြင်အာရုံကို ပံ့ပိုးပေးရန်။ Fog computing သည် အချိန်နှင့်တပြေးညီ ပြဿနာများကို ဖြေရှင်းရာတွင် ပိုမိုထိရောက်သည်။ ၎င်းတို့သည် တောင်းဆိုမှုများကို လျင်မြန်စွာ တုံ့ပြန်နိုင်ပြီး ဒေတာလုပ်ဆောင်ခြင်းတွင် latency အနည်းဆုံးဖြစ်သည်။ ဆိုလိုသည်မှာ၊ Fog သည် "တိမ်များ" ကိုဖြည့်စွက်ပြီး၎င်း၏စွမ်းရည်များကိုချဲ့ထွင်သည်။

သို့သော် အဓိကမေးခွန်းမှာ ကွဲပြားသည်- ဤအရာအားလုံးသည် IoT ၏အခြေအနေတွင် မည်သို့အကျိုးသက်ရောက်သင့်သနည်း။ ပေါင်းစပ် IoT-Fog-Cloud စနစ်တွင် အလုပ်လုပ်သောအခါ မည်သည့်ဆက်သွယ်ရေးပရိုတိုကောများသည် အထိရောက်ဆုံးဖြစ်မည်နည်း။

HTTP ၏ ထင်ရှားစွာ လွှမ်းမိုးထားသော်လည်း IoT၊ Fog နှင့် Cloud စနစ်များတွင် အသုံးပြုသည့် အခြားသော ဖြေရှင်းချက် အများအပြား ရှိပါသည်။ အဘယ်ကြောင့်ဆိုသော် IoT သည် သုံးစွဲသူများ၏ လုံခြုံရေး၊ လိုက်ဖက်ညီမှုနှင့် အခြားလိုအပ်ချက်များနှင့် စက်ကိရိယာအာရုံခံကိရိယာအမျိုးမျိုး၏ လုပ်ဆောင်နိုင်စွမ်းကို ပေါင်းစပ်ရသောကြောင့်ဖြစ်သည်။

သို့သော် ကိုးကားမှုဗိသုကာနှင့် ဆက်သွယ်ရေးစံနှုန်းနှင့်ပတ်သက်၍ တစ်ခုတည်းသော စိတ်ကူးမရှိပါ။ ထို့ကြောင့်၊ ပရိုတိုကောအသစ်တစ်ခုဖန်တီးခြင်း သို့မဟုတ် သီးခြား IoT လုပ်ဆောင်ချက်များအတွက် ရှိပြီးသားတစ်ခုကို ပြုပြင်ခြင်းသည် အိုင်တီအသိုင်းအဝိုင်းနှင့်ရင်ဆိုင်နေရသော အရေးကြီးဆုံးအလုပ်များထဲမှတစ်ခုဖြစ်သည်။

မည်သည့်ပရိုတိုကောများကို လက်ရှိအသုံးပြုနေပြီး ၎င်းတို့သည် အဘယ်အရာကို ပေးဆောင်နိုင်သနည်း။ အဖြေရှာကြည့်ရအောင်။ သို့သော် ဦးစွာ၊ တိမ်များ၊ မြူများနှင့် အရာများ၏အင်တာနက်တို့ အပြန်အလှန် သက်ရောက်မှုရှိသော ဂေဟစနစ်၏ အခြေခံမူများကို ဆွေးနွေးကြည့်ကြပါစို့။

IoT Fog-to-Cloud (F2C) ဗိသုကာ

IoT၊ cloud နှင့် fog တို့၏ စမတ်ကျသော ညှိနှိုင်းစီမံမှုနှင့် ဆက်စပ်နေသော အားသာချက်များနှင့် အကျိုးကျေးဇူးများကို ရှာဖွေရာတွင် မည်မျှကြိုးစားအားထုတ်ထားသည်ကို သင်သတိပြုမိပေမည်။ မဟုတ်ပါက၊ ဤသည်မှာ စံပြုခြင်းအစပျိုးခြင်း သုံးခုဖြစ်သည်။ OpenFog လုပ်ငန်းစု, Edge Computing လုပ်ငန်းစု и mF2C H2020 EU ပရောဂျက်.

ယခင်က အဆင့် 2 ဆင့်ကိုသာ cloud နှင့် end devices များဟု ယူဆပါက၊ အဆိုပြုထားသော ဗိသုကာသည် အဆင့်အသစ် - fog computing ကို မိတ်ဆက်ပေးသည်။ ဤကိစ္စတွင်၊ အရင်းအမြစ်များ၏ သီးခြား သို့မဟုတ် ဤအဆင့်ခွဲများတွင် မတူညီသောစက်ပစ္စည်းများအသုံးပြုမှုကို ဆုံးဖြတ်သည့် မူဝါဒများပေါ်မူတည်၍ မြူအဆင့်ကို အဆင့်ခွဲများစွာသို့ ပိုင်းခြားနိုင်ပါသည်။

ဒီ abstraction က ဘယ်လိုမျိုး ဖြစ်နိုင်လဲ။ ဤသည်မှာ ပုံမှန် IoT-Fog-Cloud ဂေဟစနစ်ဖြစ်သည်။ IoT စက်ပစ္စည်းများသည် latency နည်းရန် လိုအပ်သော ပြဿနာများကို ဖြေရှင်းရန်အတွက် ပိုမိုမြန်ဆန်သော ဆာဗာများနှင့် ကွန်ပျူတာစက်ပစ္စည်းများသို့ ဒေတာပေးပို့ပါသည်။ တူညီသောစနစ်တွင်၊ cloud များသည် ကွန်ပျူတာအရင်းအမြစ်များ သို့မဟုတ် ဒေတာသိုလှောင်မှုနေရာအမြောက်အမြား လိုအပ်သည့် ပြဿနာများကို ဖြေရှင်းရန်အတွက် တာဝန်ရှိပါသည်။

စမတ်ဖုန်းများ၊ စမတ်နာရီများနှင့် အခြားသော gadget များသည် IoT ၏ အစိတ်အပိုင်းလည်း ဖြစ်နိုင်သည်။ သို့သော် စည်းကမ်းအရ၊ ထိုကဲ့သို့သော စက်များသည် ကြီးမားသော developer များထံမှ သီးသန့်ဆက်သွယ်ရေးပရိုတိုကောများကို အသုံးပြုသည်။ ထုတ်လုပ်လိုက်သော IoT ဒေတာကို RESTful ဝန်ဆောင်မှုများဖန်တီးရာတွင် ပြောင်းလွယ်ပြင်လွယ်နှင့် အပြန်အလှန်လုပ်ဆောင်နိုင်မှုကို ပံ့ပိုးပေးသည့် REST HTTP ပရိုတိုကောမှတစ်ဆင့် မြူအလွှာသို့ လွှဲပြောင်းပေးပါသည်။ ပြည်တွင်းကွန်ပျူတာများ၊ ဆာဗာများ သို့မဟုတ် ဆာဗာအစုအဝေးတွင် လုပ်ဆောင်နေသော လက်ရှိကွန်ပျူတာအခြေခံအဆောက်အအုံနှင့် နောက်ပြန်လိုက်ဖက်မှုရှိရန် လိုအပ်ခြင်းကြောင့် ၎င်းသည် အရေးကြီးပါသည်။ “fog nodes” ဟုခေါ်သော ဒေသဆိုင်ရာရင်းမြစ်များသည် လက်ခံရရှိထားသောဒေတာကို စစ်ထုတ်ပြီး ၎င်းကို စက်တွင်းလုပ်ဆောင်ခြင်း သို့မဟုတ် နောက်ထပ်တွက်ချက်မှုများအတွက် cloud သို့ ပေးပို့ပါ။

Clouds သည် မတူညီသောဆက်သွယ်ရေးပရိုတိုကောများကို ပံ့ပိုးပေးသည်၊ အသုံးအများဆုံးမှာ AMQP နှင့် REST HTTP ဖြစ်သည်။ HTTP သည် အင်တာနက်အတွက် လူသိများပြီး အံဝင်ခွင်ကျဖြစ်သောကြောင့်၊ "IoT နှင့် fog တို့နှင့် တွဲဖက်လုပ်ဆောင်ရန် ၎င်းကို ကျွန်ုပ်တို့ အသုံးပြုသင့်သည် မဟုတ်ပါလော။" သို့သော်၊ ဤပရိုတိုကောသည် စွမ်းဆောင်ရည်ဆိုင်ရာ ပြဿနာများရှိသည်။ ဒီအကြောင်းကို နောက်မှပြောပါ။

ယေဘုယျအားဖြင့်၊ ကျွန်ုပ်တို့လိုအပ်သော စနစ်အတွက် သင့်လျော်သော ဆက်သွယ်ရေးပရိုတိုကော မော်ဒယ် ၂ ခုရှိသည်။ ၎င်းတို့သည် တောင်းဆိုချက်-တုံ့ပြန်မှုနှင့် ထုတ်ဝေ-စာရင်းသွင်းမှုတို့ဖြစ်သည်။ ပထမမော်ဒယ်ကို အထူးသဖြင့် ဆာဗာ-ဖောက်သည် ဗိသုကာလက်ရာများတွင် ပိုမိုကျယ်ပြန့်စွာ သိရှိကြသည်။ ဖောက်သည်သည် ဆာဗာမှ အချက်အလက်ကို တောင်းဆိုပြီး ဆာဗာသည် တောင်းဆိုချက်ကို လက်ခံရရှိသည်၊ ၎င်းကို လုပ်ဆောင်ပြီး တုံ့ပြန်သည့် မက်ဆေ့ချ်ကို ပြန်ပေးသည်။ REST HTTP နှင့် CoAP ပရိုတိုကောများသည် ဤမော်ဒယ်တွင် လုပ်ဆောင်သည်။

ဒုတိယမော်ဒယ်သည် ဒေတာထုတ်ပေးသည့်ရင်းမြစ်များနှင့် ဤဒေတာလက်ခံရရှိသူများကြား တပြိုင်နက်တည်း၊ ဖြန့်ဝေမှု၊ လျော့ရဲရဲတွဲချိတ်မှုကို ပံ့ပိုးပေးရန် လိုအပ်မှုမှ ပေါ်ပေါက်လာခြင်းဖြစ်သည်။

မော်ဒယ်တွင် ပါဝင်သူ သုံးဦးပါဝင်သည်- ထုတ်ဝေသူ (ဒေတာရင်းမြစ်)၊ ပွဲစား (ပေးပို့သူ) နှင့် စာရင်းသွင်းသူ (လက်ခံသူ) တို့ဖြစ်သည်။ ဤတွင်၊ စာရင်းသွင်းသူအဖြစ်ဆောင်ရွက်သော client သည် ဆာဗာမှ အချက်အလက်များကို တောင်းဆိုရန်မလိုအပ်ပါ။ တောင်းဆိုမှုများ ပေးပို့မည့်အစား၊ ၎င်းသည် အဝင်မက်ဆေ့ဂျ်အားလုံးကို စစ်ထုတ်ပြီး ထုတ်ဝေသူများနှင့် စာရင်းသွင်းသူများကြားတွင် ၎င်းတို့ကို လမ်းကြောင်းသတ်မှတ်ရန် တာဝန်ရှိသည့် ပွဲစားမှတစ်ဆင့် စနစ်အတွင်းရှိ အချို့သောဖြစ်ရပ်များကို စာရင်းသွင်းပါသည်။ ထုတ်ဝေသူသည် သတ်မှတ်ထားသော အကြောင်းအရာတစ်ခုနှင့် ပတ်သက်သည့် အဖြစ်အပျက်တစ်ခု ဖြစ်ပေါ်လာသောအခါ၊ စာရင်းသွင်းသူထံ တောင်းဆိုထားသည့် အကြောင်းအရာနှင့် ဒေတာများကို ပေးပို့သည့် ပွဲစားထံ ထုတ်ဝေသည်။

အခြေခံအားဖြင့်၊ ဤဗိသုကာသည် ဖြစ်ရပ်ကိုအခြေခံသည်။ ထို့အပြင် IoT၊ cloud၊ fog ရှိ အက်ပ်လီကေးရှင်းများအတွက် စိတ်ဝင်စားစရာကောင်းပြီး မတူညီသောစက်ပစ္စည်းများအကြား အပြန်အလှန်ချိတ်ဆက်မှုကို ရိုးရှင်းစေရန်၊ သွက်လက်သော အများအပြားမှများစွာသော ဆက်သွယ်ရေးနှင့် အပြိုင်အဆိုင်ဆက်သွယ်မှုကို ပံ့ပိုးပေးနိုင်သောကြောင့် စိတ်ဝင်စားစရာကောင်းပါသည်။ ထုတ်ဝေ-စာရင်းသွင်းမှု မော်ဒယ်ကို အသုံးပြုသည့် လူသိအများဆုံး စံသတ်မှတ်ထားသော စာတိုပေးပို့ရေး ပရိုတိုကောအချို့တွင် MQTT၊ AMQP နှင့် DDS တို့ ပါဝင်ပါသည်။

သိသာထင်ရှားစွာ၊ ထုတ်ဝေ-စာရင်းသွင်းမှုပုံစံတွင် အားသာချက်များစွာရှိသည်-

• ထုတ်ဝေသူများနှင့် စာရင်းသွင်းသူများသည် အချင်းချင်း၏ဖြစ်တည်မှုအကြောင်း သိရန်မလိုအပ်ပါ။
• စာရင်းသွင်းသူ တစ်ဦးသည် မတူညီသော ပုံနှိပ်တိုက်များစွာမှ အချက်အလက်များကို လက်ခံရရှိနိုင်ပြီး ထုတ်ဝေသူတစ်ဦးသည် မတူညီသော စာရင်းသွင်းသူအများအပြားထံ ဒေတာပေးပို့နိုင်သည် (များစွာသော နိယာမတစ်ခုမှ တစ်ခုသို့)၊
• ထုတ်ဝေသူနှင့် စာရင်းသွင်းသူသည် တစ်ချိန်တည်းတွင် ဆက်သွယ်ရန် တက်ကြွနေရန် မလိုအပ်ပါ။ အကြောင်းမှာ ပွဲစားသည် (တန်းစီခြင်းစနစ်တစ်ခုအဖြစ် လုပ်ဆောင်နေသည်) သည် ကွန်ရက်နှင့် ချိတ်ဆက်မထားသည့် ဖောက်သည်များအတွက် မက်ဆေ့ချ်ကို သိမ်းဆည်းနိုင်မည်ဖြစ်သည်။

သို့သော် တောင်းဆိုချက်-တုံ့ပြန်မှုပုံစံတွင်လည်း ၎င်း၏အားသာချက်များရှိသည်။ ဆာဗာဖက်မှ ဖောက်သည်တောင်းဆိုချက်များစွာကို ကိုင်တွယ်ဖြေရှင်းနိုင်မှုမှာ ပြဿနာမဟုတ်သည့်ကိစ္စများတွင် သက်သေပြပြီး ယုံကြည်စိတ်ချရသော ဖြေရှင်းချက်များကို အသုံးပြုခြင်းသည် အဓိပ္ပာယ်ရှိစေသည်။

မော်ဒယ်နှစ်မျိုးလုံးကို ပံ့ပိုးပေးသည့် ပရိုတိုကောများလည်း ရှိပါသည်။ ဥပမာအားဖြင့်၊ "ဆာဗာတွန်းခြင်း" ရွေးချယ်မှုကိုပံ့ပိုးပေးသော XMPP နှင့် HTTP 2.0။ IETF မှလည်း CoAP ကိုထုတ်ပြန်ခဲ့သည်။ စာတိုပေးပို့ခြင်းပြဿနာကို ဖြေရှင်းရန် ကြိုးပမ်းမှုတွင် WebSockets ပရိုတိုကော သို့မဟုတ် QUIC (Quick UDP Internet Connections များပေါ်တွင် HTTP ပရိုတိုကောကို အသုံးပြုခြင်း) ကဲ့သို့သော အခြားသော ဖြေရှင်းချက်များစွာကို ဖန်တီးထားသည်။

WebSockets ကိစ္စတွင်၊ ဆာဗာတစ်ခုမှ ဝဘ်ဖောက်သည်ထံသို့ အချိန်နှင့်တပြေးညီ ဒေတာလွှဲပြောင်းရန် အသုံးပြုပြီး တစ်ပြိုင်နက် နှစ်လမ်းညွန် ဆက်သွယ်မှုဖြင့် ဆက်တိုက်ချိတ်ဆက်မှုများကို ပံ့ပိုးပေးသော်လည်း ၎င်းသည် အကန့်အသတ်ရှိသော ကွန်ပျူတာအရင်းအမြစ်များရှိသော စက်များအတွက် ရည်ရွယ်ခြင်းမဟုတ်ပါ။ သယ်ယူပို့ဆောင်ရေးပရိုတိုကောအသစ်သည် အခွင့်အလမ်းသစ်များစွာကို ပေးစွမ်းသောကြောင့် QUIC သည်လည်း အာရုံစိုက်မှုခံယူထိုက်ပါသည်။ သို့သော် QUIC သည် စံချိန်စံညွှန်းမမီသေးသောကြောင့် ၎င်း၏ဖြစ်နိုင်ချေရှိသော အသုံးချပလီကေးရှင်းနှင့် IoT ဖြေရှင်းချက်များအပေါ် အကျိုးသက်ရောက်မှုကို ခန့်မှန်းရန် အချိန်မတန်သေးပါ။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် အနာဂတ်တွင် WebSockets နှင့် QUIC တို့ကို စိတ်ထဲတွင် ထားရှိထားသော်လည်း ယခုအချိန်တွင် ၎င်းကို အသေးစိတ်လေ့လာမည်မဟုတ်ပါ။

ကမ္ဘာပေါ်တွင် အချောဆုံးက ဘယ်သူလဲ- ပရိုတိုကောများကို နှိုင်းယှဉ်ပါ။

အခု Protocol တွေရဲ့ အားသာချက် အားနည်းချက်တွေအကြောင်း ပြောကြရအောင်။ ရှေ့ကိုကြည့်လိုက်၊ ပြတ်သားတဲ့ခေါင်းဆောင်တစ်ယောက်မှမရှိဘူးလို့ ချက်ချင်းကြိုတင်စာရင်းသွင်းလိုက်ကြရအောင်။ ပရိုတိုကောတစ်ခုစီတွင် အားသာချက်/အားနည်းချက်အချို့ရှိသည်။

တုံ့ပြန်မှုအချိန်

အထူးသဖြင့် Internet of Things နှင့် ဆက်နွှယ်နေသည့် ဆက်သွယ်ရေးပရိုတိုကောများ၏ အရေးကြီးဆုံးလက္ခဏာများထဲမှတစ်ခုမှာ တုံ့ပြန်ချိန်ဖြစ်သည်။ သို့သော် လက်ရှိပရိုတိုကောများကြားတွင် မတူညီသောအခြေအနေများအောက်တွင် အလုပ်လုပ်သည့်အခါ latency အနည်းဆုံးအဆင့်ကို သရုပ်ပြသည့် ရှင်းရှင်းလင်းလင်းအောင်နိုင်သူမရှိပါ။ သို့သော် သုတေသနနှင့် ပရိုတိုကော စွမ်းရည်များကို နှိုင်းယှဉ်မှုများ အစုံအလင်ရှိသည်။

ဥပမာအားဖြင့်, ရလဒ်များကို IoT နှင့်အလုပ်လုပ်သောအခါ HTTP နှင့် MQTT ၏ထိရောက်မှုနှိုင်းယှဉ်ချက်များသည် MQTT အတွက်တောင်းဆိုမှုများအတွက်တုံ့ပြန်ချိန်သည် HTTP အတွက်ထက်နည်းကြောင်းပြသခဲ့သည်။ ပြီးလိုက်တာ လေ့လာနေပါတယ်။ MQTT နှင့် CoAP ၏ အသွားအပြန်အချိန် (RTT) သည် CoAP ၏ ပျမ်းမျှ RTT သည် MQTT ထက် 20% လျော့နည်းကြောင်း ဖော်ပြခဲ့သည်။

အခြား စမ်းသပ်မှု MQTT နှင့် CoAP ပရိုတိုကောများအတွက် RTT ဖြင့် ဖြစ်ရပ်နှစ်ခု- ပြည်တွင်းကွန်ရက်နှင့် IoT ကွန်ရက်။ IoT ကွန်ရက်တစ်ခုတွင် ပျမ်းမျှ RTT သည် 2-3 ဆ ပိုများကြောင်း တွေ့ရှိခဲ့ရသည်။ QoS0 ပါသော MQTT သည် CoAP နှင့် နှိုင်းယှဉ်ပါက နိမ့်ကျသော ရလဒ်ကို ပြသခဲ့ပြီး MQTT နှင့် QoS1 သည် အပလီကေးရှင်းနှင့် သယ်ယူပို့ဆောင်ရေး အလွှာများရှိ ACKs များကြောင့် RTT ပိုများသည်ကို ပြသခဲ့သည်။ မတူညီသော QoS အဆင့်များအတွက်၊ ပိတ်ဆို့ခြင်းမရှိဘဲ ကွန်ရက်ကြာချိန်သည် MQTT အတွက် မီလီစက္ကန့်များနှင့် CoAP အတွက် ရာနှင့်ချီသော မိုက်ခရိုစက္ကန့်များဖြစ်သည်။ သို့သော်၊ ယုံကြည်စိတ်ချရမှုနည်းသော ကွန်ရက်များတွင် အလုပ်လုပ်သောအခါ TCP ၏ထိပ်တွင် လုပ်ဆောင်နေသည့် MQTT သည် လုံးဝကွဲပြားသည့်ရလဒ်ကိုပြသမည်ကို သတိရသင့်သည်။

နှိုင်းယှဉ်မှု payload ကိုတိုးမြှင့်ခြင်းဖြင့် AMQP နှင့် MQTT ပရိုတိုကောများအတွက် တုံ့ပြန်ချိန်သည် light load နှင့် latency အဆင့်နီးပါးတူညီကြောင်းပြသခဲ့သည်။ သို့သော် ဒေတာအမြောက်အမြားကို လွှဲပြောင်းသည့်အခါ၊ MQTT သည် တိုတောင်းသော တုံ့ပြန်မှုအချိန်များကို သရုပ်ပြသည်။ နောက်ထပ်တစ်ခု လေ့လာ CoAP သည် ဓာတ်ငွေ့အာရုံခံကိရိယာများ၊ မိုးလေဝသအာရုံခံကိရိယာများ၊ တည်နေရာအာရုံခံကိရိယာများ (GPS) နှင့် မိုဘိုင်းကွန်ရက်ကြားခံစနစ် (GPRS) တပ်ဆင်ထားသော ယာဉ်များပေါ်တွင် တပ်ဆင်ထားသော စက်များနှင့်အတူ စက်တစ်ခုမှစက်ဆက်သွယ်မှုအခြေအနေတွင် HTTP နှင့် နှိုင်းယှဉ်ထားသည်။ မိုဘိုင်းကွန်ရက်ပေါ်ရှိ CoAP မက်ဆေ့ဂျ်ကို ပေးပို့ရန် လိုအပ်သည့်အချိန်သည် HTTP မက်ဆေ့ချ်များကို အသုံးပြုရန် လိုအပ်သည့်အချိန်ထက် သုံးဆနီးပါး ပိုတိုပါသည်။

ပရိုတိုကော နှစ်ခုမဟုတ်ဘဲ သုံးခုကို နှိုင်းယှဉ်လေ့လာမှုများ ပြုလုပ်ခဲ့သည်။ ဥပမာအားဖြင့်, နှိုင်းယှဉ်မှု ကွန်ရက် emulator ကို အသုံးပြု၍ ဆေးဘက်ဆိုင်ရာ အပလီကေးရှင်း အခြေအနေတွင် IoT ပရိုတိုကော MQTT၊ DDS နှင့် CoAP ၏ စွမ်းဆောင်ရည်။ DDS သည် ညံ့ဖျင်းသော ကွန်ရက်အခြေအနေအမျိုးမျိုးအောက်တွင် စမ်းသပ်ထားသော တယ်လီမက်ထရီကြာချိန်၏ သတ်မှတ်ချက်များအရ MQTT ကို စွမ်းဆောင်ရည်ထက် သာလွန်စေသည်။ UDP-based CoAP သည် လျင်မြန်သောတုံ့ပြန်မှုအချိန်များလိုအပ်သော အပလီကေးရှင်းများအတွက် ကောင်းမွန်စွာလုပ်ဆောင်နိုင်သော်လည်း ၎င်းသည် UDP-based ဖြစ်ခြင်းကြောင့် သိသာထင်ရှားသော ခန့်မှန်းမရနိုင်သော ပက်ကတ်ဆုံးရှုံးမှုရှိသည်။

စွမ်းရည်

နှိုင်းယှဉ်မှု MQTT နှင့် CoAP သည် bandwidth ထိရောက်မှု၏စည်းကမ်းချက်များ၌ မက်ဆေ့ချ်တစ်ခုလျှင် ပေးပို့သည့်ဒေတာစုစုပေါင်းပမာဏကို တွက်ချက်မှုအဖြစ် ဆောင်ရွက်ခဲ့ပါသည်။ CoAP သည် သေးငယ်သော မက်ဆေ့ချ်များကို ပို့သည့်အခါ MQTT ထက် နိမ့်သော ပမာဏကို ပြသထားသည်။ သို့သော် ပရိုတိုကောများ၏ ထိရောက်မှုကို လွှဲပြောင်းပေးသည့် စုစုပေါင်းဘိုက်အရေအတွက်နှင့် အသုံးဝင်သော အချက်အလက်အရေအတွက် အချိုးအစားအရ နှိုင်းယှဉ်သောအခါတွင် CoAP သည် ပိုမိုထိရောက်မှုရှိလာခဲ့သည်။

တွင် ခွဲခြမ်းစိတ်ဖြာခြင်း MQTT၊ DDS (သယ်ယူပို့ဆောင်ရေးပရိုတိုကောအဖြစ် TCP) နှင့် CoAP လှိုင်းဘန်းဝဒ်တို့ကို အသုံးပြု၍ CoAP သည် ယေဘုယျအားဖြင့် နှိုင်းယှဉ်ပါက လှိုင်းသုံးစွဲမှုနည်းပါးကြောင်းပြသခဲ့သည်၊ ထိုနေရာတွင် MQTT နှင့် DDS တို့ကဲ့သို့ များပြားလာသော ကွန်ရက်ပက်ကတ်ဆုံးရှုံးမှု သို့မဟုတ် တိုးမြှင့်ထားသည့်ကွန်ရက် latency နှင့်အတူ တိုးလာခြင်းမရှိကြောင်း တွေ့ရှိရပါသည်။ ဖော်ပြထားသော အခြေအနေများတွင် bandwidth အသုံးချမှု တိုးလာသည်။ IoT ပတ်၀န်းကျင်တွင် ပုံမှန်ဖြစ်သည့် ဒေတာများကို တစ်ပြိုင်နက် ပို့လွှတ်သည့် စက်ပစ္စည်း အများအပြား ပါဝင်သည့် အခြားသော မြင်ကွင်း။ ရလဒ်များပိုမိုမြင့်မားစွာအသုံးပြုရန်အတွက် CoAP ကိုအသုံးပြုခြင်းသည်ပိုမိုကောင်းမွန်ကြောင်းပြသခဲ့သည်။

ပေါ့ပါးသောဝန်အောက်တွင် CoAP သည် အနည်းဆုံး bandwidth ကိုအသုံးပြုပြီး နောက်တွင် MQTT နှင့် REST HTTP တို့ဖြစ်သည်။ သို့သော်လည်း၊ payloads အရွယ်အစား တိုးလာသောအခါ၊ REST HTTP သည် အကောင်းဆုံးရလဒ်များ ရရှိခဲ့သည်။

စွမ်းအင်သုံးစွဲမှု

စွမ်းအင်သုံးစွဲမှုပြဿနာသည် အထူးသဖြင့် IoT စနစ်တွင် အလွန်အရေးကြီးပါသည်။ အကယ်လို့ နှိုင်းယှဉ် MQTT နှင့် HTTP သည် လျှပ်စစ်ဓာတ်အား သုံးစွဲနေချိန်တွင် HTTP သည် ပိုမိုသုံးစွဲသည်။ CoAP က ပိုများတယ်။ စွမ်းအင်ထိရောက်မှု MQTT နှင့် နှိုင်းယှဉ်ပါက ပါဝါစီမံခန့်ခွဲမှုကို ခွင့်ပြုသည်။ သို့ရာတွင်၊ ရိုးရှင်းသောအခြေအနေများတွင်၊ အထူးသဖြင့် ပါဝါကန့်သတ်ချက်များမရှိလျှင် MQTT သည် Internet of Things ကွန်ရက်များတွင် သတင်းအချက်အလက်ဖလှယ်ရန်အတွက် ပိုမိုသင့်လျော်ပါသည်။

အခြား AMQP နှင့် MQTT တို့၏ စွမ်းရည်များကို မိုဘိုင်း သို့မဟုတ် မတည်မငြိမ် ကြိုးမဲ့ကွန်ရက် စမ်းသပ်မှုတွင် နှိုင်းယှဉ်ထားသည့် စမ်းသပ်ချက်တစ်ခုတွင် AMQP သည် MQTT သည် စွမ်းအင်ပိုသက်သာသော်လည်း AMQP သည် ပိုမိုလုံခြုံရေးစွမ်းရည်များကို ပေးဆောင်သည်ကို တွေ့ရှိခဲ့သည်။

လုံခွုံမှု

Internet of Things နှင့် fog/cloud computing ဆိုင်ရာ ခေါင်းစဉ်ကို လေ့လာသည့်အခါ လုံခြုံရေးသည် အရေးကြီးသော ပြဿနာတစ်ခုဖြစ်သည်။ လုံခြုံရေးယန္တရားသည် ပုံမှန်အားဖြင့် HTTP၊ MQTT၊ AMQP နှင့် XMPP သို့မဟုတ် CoAP ရှိ DTLS တွင် TLS ကိုအခြေခံထားပြီး DDS မျိုးကွဲနှစ်မျိုးလုံးကို ပံ့ပိုးပေးသည်။

TLS နှင့် DTLS သည် ပံ့ပိုးပေးထားသော cipher suites နှင့် keys များကို ဖလှယ်ရန်အတွက် client နှင့် server နှစ်ဖက်ကြားတွင် ဆက်သွယ်မှုတည်ဆောက်ခြင်းလုပ်ငန်းစဉ်ဖြင့် စတင်ပါသည်။ နှစ်ဦးနှစ်ဘက်စလုံးသည် လုံခြုံသော ချန်နယ်တစ်ခုတွင် နောက်ထပ် ဆက်သွယ်မှုများ ဖြစ်ပေါ်နိုင်စေရန် သေချာစေရန် အစုံလိုက် ညှိနှိုင်းကြသည်။ ၎င်းတို့နှစ်ခုကြားက ခြားနားချက်မှာ UDP-based DTLS သည် ယုံကြည်စိတ်ချရသောချိတ်ဆက်မှုတစ်ခုအပေါ် လုပ်ဆောင်နိုင်စေမည့် အသေးစားမွမ်းမံမှုများတွင် တည်ရှိနေသည်။

တွင် စမ်းသပ်တိုက်ခိုက်မှုများ TLS နှင့် DTLS ၏ မတူညီသော အကောင်အထည်ဖော်မှုအများအပြားသည် TLS ပိုမိုကောင်းမွန်သည့်အလုပ်ဖြစ်ကြောင်း တွေ့ရှိခဲ့သည်။ ၎င်း၏ အမှားခံနိုင်ရည်ကြောင့် DTLS တွင် တိုက်ခိုက်မှုများ ပိုမိုအောင်မြင်ခဲ့သည်။

သို့သော်လည်း ဤပရိုတိုကောများ၏ အကြီးမားဆုံးပြဿနာမှာ ၎င်းတို့သည် IoT တွင် အသုံးပြုရန်အတွက် မူလက ဒီဇိုင်းထုတ်ထားခြင်းမဟုတ်ပဲ မြူခိုးများ သို့မဟုတ် တိမ်တိုက်များတွင် အလုပ်လုပ်ရန် ရည်ရွယ်ထားခြင်းမဟုတ်ခြင်းကြောင့် ဖြစ်သည်။ လက်ဆွဲနှုတ်ဆက်ခြင်းဖြင့်၊ ၎င်းတို့သည် ကွန်ပြူတာရင်းမြစ်များကို ကုန်ဆုံးစေသည့် ချိတ်ဆက်မှုတစ်ခုစီတွင် ထပ်လောင်းလမ်းကြောင်းကို ပေါင်းထည့်သည်။ ပျမ်းမျှအားဖြင့် TLS အတွက် 6,5% နှင့် DTLS အတွက် လုံခြုံရေးအလွှာမပါဘဲ ဆက်သွယ်ရေးများနှင့် နှိုင်းယှဉ်ပါက 11% တိုးလာပါသည်။ သယံဇာတ ပေါကြွယ်ဝသော ပတ်ဝန်းကျင်တွင် အများအားဖြင့် တည်ရှိနေသော၊ တိမ်ထူတယ်။ အဆင့်၊ ၎င်းသည် ပြဿနာမဟုတ်သော်လည်း IoT နှင့် fog အဆင့်ကြားတွင်၊ ၎င်းသည် အရေးကြီးသော ကန့်သတ်ချက်တစ်ခု ဖြစ်လာသည်။

ဘာကိုရွေးရမလဲ။ ရှင်းရှင်းလင်းလင်း အဖြေမရှိပါ။ MQTT နှင့် HTTP တို့သည် အခြားပရိုတိုကောများနှင့် နှိုင်းယှဉ်ပါက ပိုမိုရင့်ကျက်ပြီး ပိုမိုတည်ငြိမ်သော IoT ဖြေရှင်းချက်များကို ယူဆသောကြောင့် အလားအလာအရှိဆုံး ပရိုတိုကောများဖြစ်သည်။

ပေါင်းစည်းထားသော ဆက်သွယ်မှုပရိုတိုကောကို အခြေခံ၍ ဖြေရှင်းချက်များ

တစ်ခုတည်းသော ပရိုတိုကောဖြေရှင်းချက်၏ အလေ့အကျင့်တွင် အားနည်းချက်များစွာရှိသည်။ ဥပမာအားဖြင့်၊ ကန့်သတ်ထားသောပတ်ဝန်းကျင်နှင့် ကိုက်ညီသော ပရိုတိုကောသည် တင်းကျပ်သော လုံခြုံရေးလိုအပ်ချက်များရှိသည့် ဒိုမိန်းတွင် အလုပ်မဖြစ်နိုင်ပါ။ ဤအချက်ကို စိတ်ထဲတွင်တွေးထားပြီး၊ MQTT နှင့် REST HTTP မှလွဲ၍ IoT ရှိ Fog-to-Cloud ဂေဟစနစ်ရှိ ဖြစ်နိုင်ချေရှိသော တစ်ခုတည်းသော ပရိုတိုကောဖြေရှင်းချက်အားလုံးကို စွန့်ပစ်ရန် ကျန်ရှိနေပါသည်။

ပရိုတိုကောဖြေရှင်းချက်တစ်ခုတည်းအဖြစ် HTTP ကို ​​REST

REST HTTP တောင်းဆိုချက်များနှင့် တုံ့ပြန်မှုများသည် IoT-to-Fog space တွင် အပြန်အလှန်အကျိုးသက်ရောက်ပုံ ဥပမာကောင်းတစ်ခုရှိပါသည်။ စမတ်လယ်ယာ. တိရစ္ဆာန်များတွင် ဝတ်ဆင်နိုင်သော အာရုံခံကိရိယာများ (IoT client၊ C) တပ်ဆင်ထားပြီး စမတ်လယ်ယာစနစ် (Fog server၊ S) ဖြင့် cloud computing မှတဆင့် ထိန်းချုပ်ထားသည်။

POST နည်းလမ်း၏ ခေါင်းစီးသည် (/farm/animals) အပြင် HTTP ဗားရှင်းနှင့် အကြောင်းအရာ အမျိုးအစားကို ပြုပြင်ရန် အရင်းအမြစ်ကို သတ်မှတ်ပေးသည်၊ ဤကိစ္စတွင် စနစ်က စီမံခန့်ခွဲမည့် တိရစ္ဆာန်မွေးမြူရေးကို ကိုယ်စားပြုသည့် JSON အရာဝတ္ထု (Dulcinea/cow) . ဆာဗာမှ တုံ့ပြန်မှုသည် HTTPS အခြေအနေကုဒ် 201 (အရင်းအမြစ်ဖန်တီးထားသည်) ပေးပို့ခြင်းဖြင့် တောင်းဆိုမှု အောင်မြင်ကြောင်း ဖော်ပြသည်။ GET နည်းလမ်းသည် ဆာဗာမှ ID ဖြင့် တိရစ္ဆာန်၏ JSON ကိုယ်စားပြုမှုကို ပြန်ပေးသည့် URI (ဥပမာ၊ /farm/animals/1) တွင် တောင်းဆိုထားသော အရင်းအမြစ်များကိုသာ သတ်မှတ်ရပါမည်။

အချို့သော အရင်းအမြစ်မှတ်တမ်းကို အပ်ဒိတ်လုပ်ရန် လိုအပ်သည့်အခါ PUT နည်းလမ်းကို အသုံးပြုသည်။ ဤကိစ္စတွင်၊ အရင်းအမြစ်သည် ကန့်သတ်ချက်ပြောင်းလဲရန်အတွက် URI ကို သတ်မှတ်ပေးပြီး လက်ရှိတန်ဖိုး (ဥပမာ၊ နွားသည် လက်ရှိလမ်းလျှောက်နေကြောင်း၊ /farm/animals/1? state=walking) ကိုဖော်ပြသည်။ နောက်ဆုံးတွင်၊ DELETE နည်းလမ်းကို GET method တွင် တူညီစွာအသုံးပြုသော်လည်း လည်ပတ်မှုရလဒ်အနေဖြင့် အရင်းအမြစ်ကို ရိုးရိုးရှင်းရှင်း ဖျက်ပစ်ပါသည်။

MQTT သည် single-protocol ဖြေရှင်းချက်အဖြစ်

တူညီသော စမတ်လယ်ယာကို ယူကြပါစို့၊ သို့သော် REST HTTP အစား ကျွန်ုပ်တို့သည် MQTT ပရိုတိုကောကို အသုံးပြုသည်။ Mosquitto စာကြည့်တိုက်တွင် ထည့်သွင်းထားသော ဒေသန္တရဆာဗာတစ်ခုသည် ပွဲစားအဖြစ် လုပ်ဆောင်သည်။ ဤဥပမာတွင်၊ ရိုးရှင်းသောကွန်ပြူတာ (လယ်ယာဆာဗာဟုရည်ညွှန်းသည်) Raspberry Pi သည် Mosquitto ပွဲစားနှင့် အပြည့်အဝသဟဇာတဖြစ်သည့် Paho MQTT စာကြည့်တိုက်ကို တပ်ဆင်ခြင်းအားဖြင့် MQTT သုံးစွဲသူအဖြစ် ဆောင်ရွက်ပါသည်။

ဤကလိုင်းယင့်သည် အာရုံခံနိုင်စွမ်းနှင့် တွက်ချက်မှုစွမ်းရည်ရှိသော စက်ကိုကိုယ်စားပြုသည့် IoT abstraction အလွှာနှင့် သက်ဆိုင်သည်။ အခြားတစ်ဖက်တွင်မူ ဖျန်ဖြေသူသည် ပိုမိုကောင်းမွန်သော လုပ်ဆောင်မှုနှင့် သိုလှောင်မှုစွမ်းရည်ဖြင့် လက္ခဏာရပ်ဖြစ်သော မြူကွန်ပြူတာခုံးတစ်ခုကို ကိုယ်စားပြုသည့် ပိုမိုမြင့်မားသော abstraction အဆင့်နှင့် သက်ဆိုင်သည်။

အဆိုပြုထားသည့် စမတ်လယ်ယာအခြေအနေတွင်၊ Raspberry Pi သည် accelerometer၊ GPS၊ နှင့် အပူချိန်အာရုံခံကိရိယာများသို့ ချိတ်ဆက်ပြီး အဆိုပါအာရုံခံကိရိယာများမှ အချက်အလက်များကို မြူခိုးများဆီသို့ လွှင့်တင်သည်။ သင်သိသည့်အတိုင်း၊ MQTT သည် အကြောင်းအရာများကို အထက်တန်းအဆင့်အဖြစ် သတ်မှတ်သည်။ MQTT ထုတ်ဝေသူတစ်ခုတည်းသည် တိကျသောအကြောင်းအရာအစုံသို့ မက်ဆေ့ချ်များကို ထုတ်ဝေနိုင်သည်။ ငါတို့ကိစ္စမှာ သူတို့သုံးယောက်ရှိတယ်။ တိရစ္ဆာန်စပါးကျီရှိ အပူချိန်ကို တိုင်းတာသည့် အာရုံခံကိရိယာအတွက် သုံးစွဲသူသည် အပြင်အဆင် (တိရစ္ဆာန်မွေးမြူရေး/တဲ/အပူချိန်) ကို ရွေးချယ်သည်။ accelerometer မှတဆင့် GPS တည်နေရာနှင့် တိရိစ္ဆာန်လှုပ်ရှားမှုများကို တိုင်းတာသည့် အာရုံခံကိရိယာများအတွက်၊ client သည် (animalfarm/animal/GPS) နှင့် (animalfarm/animal/movement) သို့ အပ်ဒိတ်များကို ထုတ်ပြန်မည်ဖြစ်ပါသည်။

အခြားစိတ်ဝင်စားသူ စာရင်းသွင်းသူ နောက်မှပါလာပါက ၎င်းကို ဒေသတွင်းဒေတာဘေ့စ်တွင် ယာယီသိမ်းဆည်းထားနိုင်သည့် အကျိုးဆောင်ထံသို့ ဤအချက်အလက်များကို ပေးပို့မည်ဖြစ်သည်။

မြူခိုးများတွင် MQTT ပွဲစားအဖြစ်လုပ်ဆောင်သည့် ပြည်တွင်းဆာဗာအပြင် Raspberry Pis သည် MQTT ဖောက်သည်များအဖြစ် လုပ်ဆောင်ကာ အာရုံခံဒေတာပေးပို့ခြင်းအပြင် cloud အဆင့်ရှိ အခြားသော MQTT ပွဲစားလည်း ရှိနိုင်ပါသည်။ ဤကိစ္စတွင်၊ ပြည်တွင်းပွဲစားထံ ပေးပို့သော အချက်အလက်များကို ဒေသတွင်းဒေတာဘေ့စ်တစ်ခုတွင် ယာယီသိမ်းဆည်းနိုင်ပြီး/သို့မဟုတ် cloud သို့ ပေးပို့နိုင်သည်။ ဤအခြေအနေရှိမြူခိုး MQTT ပွဲစားကို cloud MQTT ပွဲစားနှင့် ဒေတာအားလုံးကို ချိတ်ဆက်ရန်အတွက် အသုံးပြုပါသည်။ ဤတည်ဆောက်ပုံဖြင့်၊ မိုဘိုင်းအက်ပလီကေးရှင်းအသုံးပြုသူတစ်ဦးသည် ပွဲစားနှစ်ဦးစလုံးထံ စာရင်းသွင်းနိုင်ပါသည်။

ပွဲစားများထဲမှ တစ်ဦးနှင့် ချိတ်ဆက်မှု (ဥပမာ၊ cloud) မအောင်မြင်ပါက၊ အသုံးပြုသူသည် အခြား (fog) ထံမှ အချက်အလက်များကို လက်ခံရရှိမည်ဖြစ်သည်။ ၎င်းသည် ပေါင်းစပ်မြူခိုးများနှင့် တိမ်တိုက်ကွန်ပြူတာစနစ်များ၏ အင်္ဂါရပ်တစ်ခုဖြစ်သည်။ ပုံသေအားဖြင့်၊ မိုဘိုင်းအက်ပ်ကို မြူ MQTT ပွဲစားထံ ဦးစွာချိတ်ဆက်ရန် ပြင်ဆင်သတ်မှတ်နိုင်ပြီး ပျက်ကွက်ပါက cloud MQTT ပွဲစားနှင့် ချိတ်ဆက်ရန်။ ဤဖြေရှင်းချက်သည် IoT-F2C စနစ်များရှိ အများအပြားထဲမှ တစ်ခုသာဖြစ်သည်။

Multi-protocol ဖြေရှင်းချက်များ

ရိုးရှင်းသော ပရိုတိုကောဖြေရှင်းနည်းများသည် ၎င်းတို့၏ပိုမိုလွယ်ကူစွာ အကောင်အထည်ဖော်ခြင်းကြောင့် လူကြိုက်များသည်။ ဒါပေမယ့် IoT-F2C စနစ်တွေမှာ မတူညီတဲ့ ပရိုတိုကောတွေကို ပေါင်းစပ်ဖို့ အဓိပ္ပာယ်ရှိတယ်ဆိုတာ ရှင်းပါတယ်။ အယူအဆမှာ မတူညီသော ပရိုတိုကောများသည် မတူညီသော အဆင့်များတွင် လုပ်ဆောင်နိုင်သည် ။ ဥပမာအားဖြင့်၊ IoT အလွှာများ၊ မြူနှင့် cloud computing တို့၏ အလွှာသုံးခုကို ကြည့်ပါ။ IoT အဆင့်ရှိ စက်ပစ္စည်းများကို ယေဘူယျအားဖြင့် ကန့်သတ်ထားသည်ဟု ယူဆပါသည်။ ဤခြုံငုံသုံးသပ်ချက်အတွက်၊ IoT အဆင့်များကို အချုပ်အနှောင်အရှိဆုံး၊ အချုပ်အနှောင်အနည်းဆုံးအဖြစ် cloud နှင့် "အလယ်တစ်နေရာ" အဖြစ် မြူကွန်ပြူတာအဖြစ် သုံးသပ်ကြည့်ကြပါစို့။ IoT နှင့် fog abstraction များကြားတွင်၊ လက်ရှိ protocol ဖြေရှင်းချက်များတွင် MQTT၊ CoAP နှင့် XMPP တို့ ပါဝင်ပါသည်။ မြူနှင့်တိမ်ကြားတွင်၊ အခြားတစ်ဖက်တွင်၊ AMQP သည် ၎င်း၏ပြောင်းလွယ်ပြင်လွယ်ကြောင့် IoT နှင့် မြူအလွှာများကြားတွင် အသုံးပြုသည့် REST HTTP နှင့်အတူ အဓိကပရိုတိုကောများထဲမှတစ်ခုဖြစ်သည်။

ဤနေရာတွင် အဓိကပြဿနာမှာ ပရိုတိုကောများ၏ အပြန်အလှန်လုပ်ဆောင်နိုင်မှုနှင့် မက်ဆေ့ချ်များကို ပရိုတိုကောတစ်ခုမှ အခြားတစ်ခုသို့ လွှဲပြောင်းရာတွင် လွယ်ကူမှုဖြစ်သည်။ အကောင်းဆုံးကတော့ အနာဂတ်တွင်၊ cloud နှင့် fog အရင်းအမြစ်များပါရှိသော Internet of Things စနစ်၏ တည်ဆောက်ပုံသည် အသုံးပြုထားသော ဆက်သွယ်မှုပရိုတိုကောနှင့် ကင်းကွာမည်ဖြစ်ပြီး မတူညီသော ပရိုတိုကောများအကြား ကောင်းမွန်သော အပြန်အလှန်လုပ်ဆောင်နိုင်မှုကို သေချာစေမည်ဖြစ်သည်။

ယင်းသည် လောလောဆယ်မဟုတ်သောကြောင့်၊ သိသာထင်ရှားသောခြားနားချက်များမရှိသော ပရိုတိုကောများကို ပေါင်းစပ်ခြင်းသည် အဓိပ္ပာယ်ရှိပေသည်။ ဤအဆုံးသတ်အတွက် ဖြစ်နိုင်ချေရှိသော ဖြေရှင်းချက်တစ်ခုသည် တူညီသောဗိသုကာစတိုင်၊ REST HTTP နှင့် CoAP တို့ကို လိုက်နာသည့် ပရိုတိုကောနှစ်ခုပေါင်းစပ်မှုအပေါ် အခြေခံထားသည်။ နောက်ထပ်အဆိုပြုထားသည့်ဖြေရှင်းချက်သည် ထုတ်ဝေ-စာရင်းသွင်းဆက်သွယ်ရေး၊ MQTT နှင့် AMQP တို့ကိုပေးဆောင်သည့် ပရိုတိုကောနှစ်ခုပေါင်းစပ်မှုအပေါ် အခြေခံထားသည်။ အလားတူ သဘောတရားများကို အသုံးပြုခြင်း (MQTT နှင့် AMQP နှစ်ခုလုံးသည် ပွဲစားများကို အသုံးပြုခြင်း၊ CoAP နှင့် HTTP အသုံးပြုခြင်း REST) ​​​​ဤပေါင်းစပ်မှုများကို အကောင်အထည်ဖော်ရန် ပိုမိုလွယ်ကူစေပြီး ပေါင်းစည်းမှုနည်းရန် လိုအပ်ပါသည်။

ပုံ (က) သည် တောင်းဆိုချက်-တုံ့ပြန်မှုအခြေခံမော်ဒယ်နှစ်ခု၊ HTTP နှင့် CoAP နှင့် IoT-F2C ဖြေရှင်းချက်တွင် ၎င်းတို့၏ ဖြစ်နိုင်ခြေရှိသော နေရာချထားမှုကို ပြသည်။ HTTP သည် ခေတ်မီကွန်ရက်များတွင် အကျော်ကြားဆုံးနှင့် လက်ခံကျင့်သုံးသည့် ပရိုတိုကောများထဲမှ တစ်ခုဖြစ်သောကြောင့်၊ ၎င်းကို အခြားစာတိုပေးပို့ခြင်းဆိုင်ရာ ပရိုတိုကောများဖြင့် လုံးလုံးလျားလျား အစားထိုးရန် မဖြစ်နိုင်ပေ။ မိုဃ်းတိမ်နှင့် မြူများကြားတွင် တည်ရှိနေသော အားကောင်းသည့် စက်များကို ကိုယ်စားပြုသည့် ဆုံမှတ်များထဲတွင် REST HTTP သည် စမတ်ကျသော ဖြေရှင်းချက်တစ်ခုဖြစ်သည်။

အခြားတစ်ဖက်တွင်၊ Fog နှင့် IoT အလွှာများကြား ဆက်သွယ်နိုင်သည့် အကန့်အသတ်ရှိသော ကွန်ပြူတာရင်းမြစ်များရှိသည့် စက်များအတွက် CoAP ကို ​​အသုံးပြုခြင်းသည် ပိုမိုထိရောက်ပါသည်။ CoAP ၏ကြီးမားသောအားသာချက်များထဲမှတစ်ခုမှာအမှန်တကယ် HTTP နှင့်၎င်း၏လိုက်ဖက်ညီမှုဖြစ်သည်၊ အဘယ်ကြောင့်ဆိုသော်ပရိုတိုကောနှစ်ခုလုံးသည် REST စည်းမျဉ်းများအပေါ်အခြေခံသောကြောင့်ဖြစ်သည်။

ပုံ (ခ) MQTT နှင့် AMQP အပါအဝင် တူညီသောအခြေအနေတွင် ထုတ်ဝေ-စာရင်းသွင်းဆက်သွယ်ရေးမော်ဒယ်နှစ်ခုကို ပြသထားသည်။ ပရိုတိုကော နှစ်ခုစလုံးကို abstraction အလွှာတစ်ခုစီရှိ node များကြား ဆက်သွယ်ရေးအတွက် ဟန်ချက်ညီစွာ အသုံးပြုနိုင်သော်လည်း ၎င်းတို့၏ အနေအထားကို စွမ်းဆောင်ရည်အပေါ် မူတည်၍ ဆုံးဖြတ်သင့်သည်။ MQTT ကို အကန့်အသတ်ရှိသော ကွန်ပြူတာရင်းမြစ်များရှိသည့် စက်များအတွက် ပေါ့ပါးသော ပရိုတိုကောအဖြစ် ဒီဇိုင်းထုတ်ထားသောကြောင့် IoT-Fog ဆက်သွယ်ရေးအတွက် အသုံးပြုနိုင်ပါသည်။ AMQP သည် မြူခိုးများနှင့် cloud node များကြားတွင် နေရာချပေးမည့် ပိုမိုအားကောင်းသော စက်ပစ္စည်းများအတွက် ပိုမိုသင့်လျော်ပါသည်။ MQTT အစား၊ XMPP ပရိုတိုကောကို ပေါ့ပါးသည်ဟု ယူဆသောကြောင့် IoT တွင် သုံးနိုင်သည်။ သို့သော် ထိုသို့သော အခြေအနေများတွင် တွင်ကျယ်စွာ အသုံးမချပါ။

တွေ့ရှိချက်များ

ဆွေးနွေးထားသော ပရိုတိုကောများအနက်မှ တစ်ခုသည် စနစ်တစ်ခုအတွင်းရှိ ဆက်သွယ်ရေးအားလုံးကို လွှမ်းခြုံရန် လုံလောက်လိမ့်မည်မဟုတ်ပေ။ developer အများစုအသုံးပြုသည့် အလားအလာအကောင်းဆုံးရွေးချယ်စရာနှစ်ခုမှာ MQTT နှင့် RESTful HTTP တို့ဖြစ်ကြောင်း လေ့လာမှုက တွေ့ရှိခဲ့သည်။ ဤပရိုတိုကောနှစ်ခုသည် အရင့်ကျက်ဆုံးနှင့် တည်ငြိမ်ရုံသာမက၊ ကောင်းစွာမှတ်တမ်းတင်ထားပြီး အောင်မြင်သောအကောင်အထည်ဖော်မှုများနှင့် အွန်လိုင်းအရင်းအမြစ်များစွာလည်း ပါဝင်သည်။

၎င်း၏တည်ငြိမ်မှုနှင့် ရိုးရှင်းသောဖွဲ့စည်းပုံကြောင့်၊ MQTT သည် IoT အဆင့်တွင် အကန့်အသတ်ရှိသော စက်များဖြင့် အသုံးပြုသောအခါတွင် ၎င်း၏ သာလွန်ကောင်းမွန်သောစွမ်းဆောင်ရည်ကို သက်သေပြခဲ့သည့် ပရိုတိုကောတစ်ခုဖြစ်သည်။ အချို့သော မြူဒိုမိန်းများနှင့် cloud computing အများစုကဲ့သို့ အကန့်အသတ်ရှိသော ဆက်သွယ်မှုနှင့် ဘက်ထရီသုံးစွဲမှု ပြဿနာမရှိသည့် စနစ်၏အစိတ်အပိုင်းများတွင် RESTful HTTP သည် လွယ်ကူသောရွေးချယ်မှုတစ်ခုဖြစ်သည်။ CoAP သည် IoT စာတိုပေးပို့ခြင်းစံနှုန်းတစ်ခုအဖြစ် လျင်မြန်စွာပြောင်းလဲနေပြီဖြစ်သောကြောင့် ထည့်သွင်းစဉ်းစားသင့်ပြီး မဝေးတော့သောအနာဂတ်တွင် MQTT နှင့် HTTP တို့ကဲ့သို့ တည်ငြိမ်မှုနှင့်ရင့်ကျက်မှုအဆင့်သို့ ရောက်ရှိနိုင်ဖွယ်ရှိသည်။ သို့သော် စံနှုန်းသည် လက်ရှိတွင် ပြောင်းလဲနေပြီး ရေတို လိုက်ဖက်ညီမှုဆိုင်ရာ ပြဿနာများပါရှိသည်။

ဘလော့ဂ်မှာ တခြားဘာတွေဖတ်နိုင်မလဲ။ Cloud4Y

→ ကွန်ပြူတာက သင့်ကို အရသာရှိစေမှာပါ။
→ AI သည် အာဖရိကရှိ တိရစ္ဆာန်များကို လေ့လာရာတွင် ကူညီပေးသည်။
→ နွေရာသီကုန်ခါနီးပြီ။ ပေါက်ကြားသွားသော ဒေတာများ မကျန်တော့ပါ။
→ Cloud Backup တွင် သိမ်းဆည်းရန် နည်းလမ်း 4 ခု
→ လူဦးရေနှင့်ပတ်သက်သော အချက်အလက်ပါရှိသော စုစည်းထားသော ဖက်ဒရယ်အချက်အလက် အရင်းအမြစ်တစ်ခုပေါ်တွင်

ကျွန်ုပ်တို့ထံ စာရင်းသွင်းပါ။ ကွေးနနျးစာ-channel သို့သင်နောက်ဆောင်းပါးကိုလက်လွတ်မခံပါနဲ့။ ကျွန်ုပ်တို့သည် တစ်ပတ်လျှင် နှစ်ကြိမ်ထက် ပိုမရေးဘဲ လုပ်ငန်းအတွက်သာ ဖြစ်သည်။

source: www.habr.com