د سافټویر او هارډویر په برخه کې د ټیکنالوژیو پراختیا، د نوي مخابراتي پروتوکولونو راڅرګندېدل د شیانو انټرنیټ (IoT) پراختیا لامل شوی. د وسیلو شمیر ورځ په ورځ وده کوي او دوی د ډیټا لوی مقدار تولیدوي. له همدې امله، د دې معلوماتو پروسس، ذخیره کولو او لیږدولو وړ یو مناسب سیسټم جوړښت ته اړتیا ده.
اوس د بادل خدمتونه د دې موخو لپاره کارول کیږي. په هرصورت، په زیاتیدونکي توګه د فوګ کمپیوټري تمثیل (Fog) کولی شي د IoT زیربنا اندازه کولو او اصلاح کولو سره د کلاوډ حلونه بشپړ کړي.
بادل د IoT ډیری غوښتنې پوښلو وړ دي. د مثال په توګه، د خدماتو څارنه چمتو کول، د وسیلو لخوا تولید شوي هر ډول ډیټا چټک پروسس کول، او همدارنګه د دوی لید. د فوګ کمپیوټري خورا مؤثره ده کله چې د ریښتیني وخت ستونزې حل کړئ. دوی غوښتنو ته ګړندي ځواب چمتو کوي او د معلوماتو پروسس کولو کې لږترلږه ځنډ. دا دی، فوګ "بادل" بشپړوي او د هغې وړتیاوې پراخوي.
په هرصورت، اصلي پوښتنه توپیر لري: دا ټول باید د IoT په شرایطو کې څنګه تعامل وکړي؟ کوم ارتباطي پروتوکولونه به خورا اغیزمن وي کله چې په ګډ IoT-Fog-Cloud سیسټم کې کار کوي؟
د HTTP د ښکاره واکمنۍ سره سره، د IoT، فوګ او کلاوډ سیسټمونو کې کارول شوي ډیری نور حلونه شتون لري. دا ځکه چې IoT باید د مختلف وسیلو سینسرونو فعالیت د امنیت ، مطابقت او د کاروونکو نورو اړتیاو سره یوځای کړي.
مګر د حوالې جوړښت او مخابراتو معیار په اړه په ساده ډول هیڅ نظر شتون نلري. له همدې امله ، د نوي پروتوکول رامینځته کول یا د ځانګړي IoT دندو لپاره د موجوده یو ترمیم کول یو له خورا مهم کارونو څخه دی چې د IT ټولنې سره مخ دي.
کوم پروتوکولونه اوس مهال کارول کیږي او دوی څه وړاندیز کولی شي؟ راځئ چې دا معلومه کړو. مګر لومړی، راځئ چې د ایکوسیستم اصولو په اړه بحث وکړو په کوم کې چې ورېځې، غبار او د شیانو انټرنیټ متقابل عمل کوي.
IoT Fog-to-Cloud (F2C) جوړښت
تاسو شاید لیدلي وي چې د IoT ، بادل او فوګ سمارټ او همغږي مدیریت پورې اړوند د ګټو او ګټو سپړلو کې څومره هڅې کیږي. که نه، نو دلته د معیاري کولو درې نوښتونه دي: , и .
که مخکې یوازې 2 کچې په پام کې نیول شوي، بادل او پای وسایل، نو بیا وړاندیز شوی جوړښت نوې کچه معرفي کوي - fog computing. پدې حالت کې ، د فوګ کچه په څو فرعي لیولونو ویشل کیدی شي ، د سرچینو ځانګړتیاو یا د پالیسیو سیټ پورې اړه لري چې پدې فرعي سطحو کې د مختلف وسیلو کارول ټاکي.
دا خلاصون څه ډول ښکاري؟ دلته یو عادي IoT-Fog-Cloud ایکوسیستم دی. د IoT وسیلې ګړندي سرورونو او کمپیوټري وسیلو ته ډیټا لیږي ترڅو ستونزې حل کړي چې ټیټ ځنډ ته اړتیا لري. په ورته سیسټم کې، بادل د ستونزو د حل لپاره مسؤل دي چې د کمپیوټري سرچینو یا د معلوماتو ذخیره کولو ځای ته اړتیا لري.
سمارټ فونونه، سمارټ واچونه او نور وسایل هم د IoT برخه کیدی شي. مګر دا ډول وسایل، د یوې قاعدې په توګه، د لوی پراختیا کونکو څخه د ملکیت ارتباط پروتوکولونه کاروي. تولید شوي IoT ډیټا د REST HTTP پروتوکول له لارې د فوګ پرت ته لیږدول کیږي ، کوم چې د RESTful خدماتو رامینځته کولو پرمهال انعطاف او متقابل عمل چمتو کوي. دا د اړتیا په رڼا کې مهم دی چې د موجوده کمپیوټري زیربنا سره د ځایی کمپیوټرونو، سرورونو یا سرور کلستر کې د شاتنۍ مطابقت ډاډ ترلاسه کړئ. ځایی سرچینې، چې د "فګ نوډز" په نوم یادیږي، ترلاسه شوي ډاټا فلټر کوي او په محلي ډول یې پروسس کوي یا د نورو محاسبو لپاره بادل ته لیږئ.
بادل د مختلف مخابراتي پروتوکولونو ملاتړ کوي، چې تر ټولو عام یې AMQP او REST HTTP دي. څرنګه چې HTTP د انټرنیټ لپاره ښه پیژندل شوی او مناسب دی، پوښتنه راپورته کیدی شي: "ایا موږ باید دا د IoT او فوګ سره کار کولو لپاره ونه کاروو؟" په هرصورت، دا پروتوکول د فعالیت مسلې لري. په دې اړه نور وروسته.
په عموم کې، د اړیکو پروتوکولونو 2 ماډلونه شتون لري چې موږ ورته اړتیا لرو. دا د غوښتنې ځواب او خپرول - ګډون دی. لومړی ماډل په پراخه کچه پیژندل شوی، په ځانګړې توګه د سرور مراجعینو جوړښت کې. پیرودونکي د سرور څخه د معلوماتو غوښتنه کوي، او سرور غوښتنه ترلاسه کوي، پروسس کوي او د ځواب پیغام بیرته راولي. د REST HTTP او CoAP پروتوکولونه پدې ماډل کې کار کوي.
دوهم ماډل د دې اړتیا څخه رامینځته شوی چې د معلوماتو رامینځته کونکو سرچینو او د دې معلوماتو ترلاسه کونکو ترمینځ غیر متناسب ، توزیع شوي ، نرم جوړه چمتو کړي.
ماډل درې برخه اخیستونکي په غاړه لري: یو خپرونکی (د معلوماتو سرچینه)، یو بروکر (لیږونکی) او یو پیرودونکي (تر لاسه کونکی). دلته، پیرودونکي د پیرودونکي په توګه کار کوي اړتیا نلري د سرور څخه د معلوماتو غوښتنه وکړي. د غوښتنو لیږلو پرځای، دا په سیسټم کې ځینې پیښو ته د بروکر له لارې ګډون کوي، کوم چې د ټولو راتلونکو پیغامونو فلټر کولو او د خپرونکو او پیرودونکو ترمنځ د روټ کولو مسولیت لري. او خپرونکی، کله چې د یوې ځانګړې موضوع په اړه پیښه رامنځته کیږي، دا بروکر ته خپروي، کوم چې د غوښتل شوي موضوع په اړه معلومات پیرودونکي ته لیږي.
په لازمي ډول ، دا جوړښت د پیښې پراساس دی. او دا د متقابل عمل ماډل په IoT ، بادل ، فوګ کې د غوښتنلیکونو لپاره په زړه پوري دی ځکه چې د دې وړتیا چمتو کوي او د مختلف وسیلو ترمینځ متقابل ارتباط ساده کوي ، متحرک ډیری څخه ډیری مخابراتو او غیر متناسب ارتباط ملاتړ کوي. ځینې خورا مشهور معیاري پیغام رسولو پروتوکولونه چې د خپریدو-سبسکرایب ماډل کاروي MQTT، AMQP، او DDS شامل دي.
په ښکاره ډول، د خپرولو - ګډون ماډل ډیری ګټې لري:
- خپرونکي او پیرودونکي اړتیا نلري چې د یو بل د شتون په اړه پوه شي؛
- یو پیرودونکی کولی شي د ډیری مختلف خپرونو څخه معلومات ترلاسه کړي، او یو خپرونکی کولی شي ډیری مختلف پیرودونکو ته معلومات واستوي (ډیری څخه ډیری اصول)؛
- خپرونکی او پیرودونکي باید په ورته وخت کې د خبرو اترو لپاره فعال نه وي، ځکه چې بروکر (د قطار سیسټم په توګه کار کوي) به د دې وړتیا ولري چې د پیرودونکو لپاره پیغام ذخیره کړي چې اوس مهال له شبکې سره تړلي ندي.
په هرصورت، د غوښتنې ځواب ماډل هم خپل ځواک لري. په هغه حالتونو کې چې د ډیری مراجعینو غوښتنو اداره کولو لپاره د سرور اړخ وړتیا کومه مسله نده، دا د ثابت، باوري حلونو کارولو لپاره معنی لري.
داسې پروتوکولونه هم شتون لري چې دواړه ماډلونه ملاتړ کوي. د مثال په توګه، XMPP او HTTP 2.0، کوم چې د "سرور فشار" اختیار ملاتړ کوي. IETF یو CoAP هم خپور کړ. د پیغام رسولو ستونزې د حل کولو په هڅه کې، ډیری نورې حل لارې رامینځته شوي، لکه د ویب ساکټ پروتوکول یا د QUIC (د چټک UDP انټرنیټ اتصال) په اړه د HTTP پروتوکول کارول.
د WebSockets په قضیه کې، که څه هم دا په ریښتیني وخت کې د سرور څخه ویب پیرودونکي ته د ډیټا لیږدولو لپاره کارول کیږي او په ورته وخت کې د دوه اړخیزو اړیکو سره دوامداره اړیکې چمتو کوي، دا د محدود کمپیوټري سرچینو سره د وسیلو لپاره ندي. QUIC هم د پاملرنې وړ دی، ځکه چې نوی ټرانسپورټ پروتوکول ډیری نوي فرصتونه چمتو کوي. مګر له هغه ځایه چې QUIC لاهم معیاري شوی نه دی ، نو د IoT حلونو باندې د دې احتمالي غوښتنلیک او اغیزې وړاندوینه کول وخت دمخه دی. نو موږ راتلونکي ته په پام سره WebSockets او QUIC په ذهن کې ساتو ، مګر موږ به یې د اوس لپاره په ډیر تفصیل سره مطالعه نه کړو.
په نړۍ کې ترټولو ښکلی څوک دی: د پروتوکولونو پرتله کول
اوس راځئ چې د پروتوکولونو د پیاوړتیا او ضعف په اړه خبرې وکړو. په مخ کې ګورو، راځئ چې سمدلاسه ریزرویشن وکړو چې هیڅ یو روښانه مشر نشته. هر پروتوکول ځینې ګټې / زیانونه لري.
د ځواب وخت
د مخابراتو پروتوکولونو یو له خورا مهم ځانګړتیاو څخه ، په ځانګړي توګه د شیانو انټرنیټ پورې اړوند ، د غبرګون وخت دی. مګر د موجوده پروتوکولونو په مینځ کې ، هیڅ روښانه ګټونکی شتون نلري چې د مختلف شرایطو لاندې کار کولو پرمهال د ځنډ لږترلږه کچه ښیې. مګر د پروتوکول وړتیاو د څیړنې او پرتله کولو ټوله ډله شتون لري.
د مثال په توګه، د HTTP او MQTT د اغیزمنتیا پرتله کول کله چې د IoT سره کار کوي وښودله چې د MQTT لپاره د غوښتنو ځواب وخت د HTTP په پرتله لږ دی. او کله د MQTT او CoAP د دورې سفر وخت (RTT) څرګنده کړه چې د CoAP اوسط RTT د MQTT په پرتله 20٪ کم دی.
نور د MQTT او CoAP پروتوکولونو لپاره د RTT سره په دوه سناریوګانو کې ترسره شوي: محلي شبکه او IoT شبکه. دا معلومه شوه چې اوسط RTT په IoT شبکه کې 2-3 ځله لوړ دی. د QoS0 سره MQTT د CoAP په پرتله ټیټه پایله ښودلې، او د QoS1 سره MQTT په غوښتنلیک او ټرانسپورټ پرتونو کې د ACKs له امله لوړ RTT ښودلی. د مختلفو QoS کچو لپاره، پرته له ګنډلو د شبکې ځنډ د MQTT لپاره ملی ثانیه، او د CoAP لپاره په سلګونو مایکرو ثانیو. په هرصورت، دا د یادولو وړ ده چې کله په لږ باوري شبکو کې کار کوي، د TCP په سر کې د MQTT چلول به په بشپړه توګه مختلف پایلې وښيي.
د تادیاتو په زیاتولو سره د AMQP او MQTT پروتوکولونو لپاره د غبرګون وخت وښودله چې د لږ بار سره د ځنډ کچه نږدې ورته ده. مګر کله چې د ډیټا لوی مقدار لیږدول کیږي، MQTT د ځواب لنډ وخت ښیي. په یو بل کې CoAP د ماشین څخه تر ماشین پورې ارتباطي سناریو کې د HTTP سره پرتله شوی و چې د وسایطو په سر کې د ګاز سینسرونو ، هوا سینسرونو ، موقعیت سینسرونو (GPS) او د ګرځنده شبکې انٹرفیس (GPRS) سره مجهز وسایط نصب شوي. د ګرځنده شبکې له لارې د CoAP پیغام لیږدولو لپاره اړین وخت د HTTP پیغامونو کارولو لپاره اړین وخت څخه نږدې درې چنده کم و.
مطالعات ترسره شوي چې دوه نه بلکه درې پروتوکولونه پرتله کوي. د مثال په ډول، د شبکې ایمولیټر په کارولو سره د طبي غوښتنلیک سناریو کې د IoT پروتوکولونو MQTT, DDS او CoAP فعالیت. DDS د مختلفو ضعیف شبکو شرایطو لاندې د ازمول شوي ټیلی میټري ځنډ په شرایطو کې د MQTT څخه ښه کار وکړ. د UDP-based CoAP د غوښتنلیکونو لپاره ښه کار کړی چې د چټک غبرګون وخت ته اړتیا لري، په هرصورت، د UDP پر بنسټ د پام وړ غیر متوقع پیکټ ضایع شتون درلود.
بانډوید
MQTT او CoAP د بینډ ویت موثریت په شرایطو کې د هر پیغام لیږد شوي ډیټا ټول مقدار محاسبه کولو په توګه ترسره شوي. CoAP د کوچني پیغامونو لیږدولو په وخت کې د MQTT په پرتله ټیټ ټروپټ ښودلی. مګر کله چې د لیږد شوي بایټس ټولټال شمیر ته د ګټورو معلوماتو بایټس شمیر تناسب له مخې د پروتوکولونو موثریت پرتله کول ، CoAP ډیر اغیزمن ثابت شو.
په د MQTT، DDS (د ټرانسپورټ پروتوکول په توګه د TCP سره) او CoAP بینډ ویت په کارولو سره، دا وموندل شوه چې CoAP عموما د نسبتا ټیټ بینډ ویت مصرف ښودلی، کوم چې د شبکې پیکټ ضایع یا د شبکې ځنډ سره زیاتوالی نه کوي، د MQTT او DDS برعکس، چیرته چې شتون درلود. په ذکر شویو سناریوګانو کې د بینډ ویت کارولو زیاتوالی. بله سناریو کې یو لوی شمیر وسایل شامل دي چې په ورته وخت کې ډیټا لیږدوي، کوم چې د IoT چاپیریالونو کې معمول دی. پایلو ښودلې چې د لوړې ګټې اخیستنې لپاره دا غوره ده چې د CoAP کارول.
د سپک بار لاندې، CoAP لږترلږه بینډ ویت کارولی، د MQTT او REST HTTP لخوا تعقیب شوی. په هرصورت، کله چې د تادیاتو اندازه زیاته شوه، REST HTTP غوره پایلې درلودې.
د بریښنا مصرف
د انرژي مصرف مسله تل خورا مهم وي ، او په ځانګړي توګه په IoT سیسټم کې. که پداسې حال کې چې MQTT او HTTP بریښنا مصرفوي، HTTP ډیر څه مصرفوي. او CoAP ډیر دی د MQTT په پرتله، د بریښنا مدیریت ته اجازه ورکوي. په هرصورت، په ساده سناریو کې، MQTT د شیانو په انټرنیټ کې د معلوماتو تبادلې لپاره خورا مناسب دی، په ځانګړې توګه که چیرې د بریښنا محدودیت شتون نلري.
یوه تجربه چې د AMQP او MQTT وړتیاوې په ګرځنده یا بې ثباته بې سیم شبکې ټیسټ بیډ کې پرتله کوي وموندله چې AMQP ډیر امنیتي وړتیاوې وړاندې کوي پداسې حال کې چې MQTT ډیر انرژي موثره ده.
امنیت
امنیت بله مهمه مسله ده چې راپورته کیږي کله چې د شیانو انټرنیټ موضوع مطالعه کوي او فوګ / کلاوډ کمپیوټري. د امنیت میکانیزم عموما په HTTP کې د TLS، MQTT، AMQP او XMPP، یا په CoAP کې DTLS، او د DDS دواړه ډولونو مالتړ کوي.
TLS او DTLS د ملاتړ شوي سایفر سویټونو او کیلي تبادلې لپاره د پیرودونکي او سرور اړخونو ترمینځ د اړیکو رامینځته کولو پروسې سره پیل کیږي. دواړه خواوې خبرې اترې کوي ترڅو ډاډ ترلاسه کړي چې نور اړیکې په خوندي چینل کې پیښیږي. د دواړو ترمنځ توپیر په کوچنیو تعدیلونو کې دی چې د UDP پر بنسټ DTLS ته اجازه ورکوي چې په غیر معتبر ارتباط کار وکړي.
په د TLS او DTLS ډیری مختلف تطبیقونه وموندل چې TLS ښه دنده ترسره کړې. په DTLS باندې بریدونه د هغې د خطا زغم له امله ډیر بریالي وو.
په هرصورت، د دې پروتوکولونو سره لویه ستونزه دا ده چې دوی په اصل کې په IoT کې د کارونې لپاره ندي ډیزاین شوي او په فوګ یا بادل کې د کار کولو لپاره ندي. د لاس وهلو له لارې، دوی د هر ارتباط تاسیس سره اضافي ترافیک اضافه کوي، کوم چې د کمپیوټر سرچینې وچوي. په اوسط ډول، د امنیت پرت پرته د مخابراتو په پرتله په سر کې د TLS لپاره 6,5٪ او د DTLS لپاره 11٪ زیاتوالی شتون لري. د منابعو بډایه چاپیریال کې، کوم چې معمولا په کې موقعیت لري کچه، دا به کومه ستونزه ونلري، مګر د IoT او د فوګ کچې ترمنځ اړیکه کې، دا یو مهم محدودیت کیږي.
څه غوره کول؟ هیڅ روښانه ځواب نشته. MQTT او HTTP خورا ژمن پروتوکولونه ښکاري ځکه چې دوی د نورو پروتوکولونو په پرتله نسبتا ډیر بالغ او ډیر مستحکم IoT حلونه ګڼل کیږي.
د یو متحد ارتباط پروتوکول پر بنسټ حلونه
د یو واحد پروتوکول حل تمرین ډیری زیانونه لري. د مثال په توګه، یو پروتوکول چې د محدود چاپیریال سره سمون لري ممکن په هغه ډومین کې کار ونکړي چې سخت امنیتي اړتیاوې ولري. د دې په پام کې نیولو سره، موږ د MQTT او REST HTTP پرته په IoT کې د Fog-to-Cloud ایکوسیستم کې نږدې ټول ممکن واحد پروتوکول حلونه پریږدو.
REST HTTP د یو واحد پروتوکول حل په توګه
دلته یو ښه مثال شتون لري چې څنګه د REST HTTP غوښتنې او ځوابونه د IoT-to-Fog ځای کې متقابل عمل کوي: . حیوانات د اغوستلو وړ سینسرونو (IoT مراجعینو، C) سره مجهز دي او د کلاوډ کمپیوټري له لارې د سمارټ فارمنګ سیسټم (فګ سرور، S) لخوا کنټرول کیږي.
د POST میتود سرلیک د ترمیم کولو سرچینې مشخصوي (/ فارم/ څاروي) او همدارنګه د HTTP نسخه او د مینځپانګې ډول ، کوم چې پدې حالت کې د JSON څیز دی چې د څارویو فارم استازیتوب کوي چې سیسټم یې اداره کوي (Dulcinea/cow) . د سرور څخه ځواب په ګوته کوي چې غوښتنه د HTTPS حالت کوډ 201 لیږلو سره بریالۍ وه (سرچینه جوړه شوې). د GET میتود باید په URI کې یوازې غوښتل شوي سرچینې مشخص کړي (د مثال په توګه، /farm/animals/1)، کوم چې د سرور څخه د دې ID سره د څارویو JSON نمایندګي بیرته راولي.
د PUT میتود کارول کیږي کله چې ځینې ځانګړي سرچینې ریکارډ نوي کولو ته اړتیا ولري. په دې حالت کې، سرچینه د پیرامیټر بدلولو لپاره URI مشخص کوي او اوسنی ارزښت (د مثال په توګه، دا په ګوته کوي چې غوا اوس مهال روانه ده، /farm/animals/1? state=walking). په نهایت کې ، د DELETE میتود د GET میتود سره مساوي کارول کیږي ، مګر په ساده ډول د عملیاتو په پایله کې سرچینې حذف کوي.
MQTT د یو واحد پروتوکول حل په توګه
راځئ چې ورته سمارټ فارم واخلو، مګر د REST HTTP پرځای موږ د MQTT پروتوکول کاروو. د Mosquitto کتابتون نصب شوی ځایی سرور د بروکر په توګه کار کوي. په دې مثال کې، یو ساده کمپیوټر (د فارم سرور په نوم یادیږي) راسبیري پای د MQTT پیرودونکي په توګه کار کوي، د Paho MQTT کتابتون نصبولو له لارې پلي شوی، کوم چې د Mosquitto بروکر سره په بشپړه توګه مطابقت لري.
دا پیرودونکی د IoT خلاصون پرت سره مطابقت لري چې د سینس کولو او کمپیوټري وړتیاو سره د وسیلې استازیتوب کوي. منځګړیتوب، له بلې خوا، د خلاصې لوړې کچې سره مطابقت لري، د فوګ کمپیوټري نوډ استازیتوب کوي چې د پروسس کولو او ذخیره کولو ظرفیت لخوا مشخص شوی.
په وړاندیز شوي سمارټ فارم سناریو کې، Raspberry Pi د سرعت، GPS، او د تودوخې سینسرونو سره نښلوي او د دې سینسرونو څخه ډاټا د فوګ نوډ ته خپروي. لکه څنګه چې تاسو شاید پوهیږئ، MQTT موضوعات د یو ترتیب په توګه چلند کوي. یو واحد MQTT خپرونکی کولی شي پیغامونه د موضوعاتو ځانګړي سیټ ته خپاره کړي. زموږ په قضیه کې درې یې شتون لري. د یو سینسر لپاره چې د څارویو په ګودام کې د تودوخې اندازه کوي، پیرودونکي یوه موضوع غوره کوي (د څارویو فارم/شیډ/تودوخه). د سینسرونو لپاره چې د اکیلرومیټر له لارې د GPS موقعیت او د څارویو حرکت اندازه کوي، پیرودونکي به (حیوان فارم/حیوان/GPS) او (حیوان فارم/حیوان/حرکت) ته تازه معلومات خپاره کړي.
دا معلومات به بروکر ته واستول شي، څوک چې کولی شي په لنډمهاله توګه په محلي ډیټابیس کې ذخیره کړي که چیرې بل لیواله پیرودونکي وروسته راشي.
د ځایی سرور سربیره ، کوم چې په فوګ کې د MQTT بروکر په توګه کار کوي او کوم چې راسبیري پیس ، د MQTT پیرودونکو په توګه عمل کوي ، د سینسر ډیټا لیږي ، ممکن د بادل په کچه بل MQTT بروکر وي. په دې حالت کې، محلي بروکر ته لیږدول شوي معلومات په لنډمهاله توګه په محلي ډیټابیس کې زیرمه کیدی شي او / یا کلاوډ ته لیږل کیږي. په دې حالت کې د فوګ MQTT بروکر د بادل MQTT بروکر سره د ټولو معلوماتو شریکولو لپاره کارول کیږي. د دې جوړښت سره، د ګرځنده غوښتنلیک کاروونکي کولی شي د دواړو بروکرانو ګډون وکړي.
که چیرې د یو بروکر سره اړیکه (د مثال په توګه، بادل) ناکامه شي، نو وروستی کاروونکي به د بل (فګ) څخه معلومات ترلاسه کړي. دا د ګډ فوګ او کلاوډ کمپیوټري سیسټمونو ځانګړتیا ده. د ډیفالټ په واسطه، ګرځنده اپلیکیشن ترتیب کیدی شي لومړی د فوګ MQTT بروکر سره وصل شي، او که دا ناکام شي، د کلاوډ MQTT بروکر سره وصل شي. دا حل یوازې د IoT-F2C سیسټمونو څخه یو دی.
د څو پروتوکول حلونه
واحد پروتوکول حلونه د دوی د اسانه پلي کولو له امله مشهور دي. مګر دا روښانه ده چې په IoT-F2C سیسټمونو کې دا د مختلف پروتوکولونو سره یوځای کولو معنی لري. نظر دا دی چې مختلف پروتوکولونه په مختلفو کچو کار کولی شي. د مثال په توګه، درې لنډیزونه واخلئ: د IoT پرتونه، فوګ او کلاوډ کمپیوټري. د IoT په کچه وسایل عموما محدود ګڼل کیږي. د دې کتنې لپاره، راځئ چې د IoT ټایرونه په پام کې ونیسو تر ټولو محدود محدود، بادل لږ تر لږه محدودیت، او د فوګ کمپیوټري په توګه "په مینځ کې کوم ځای." بیا دا معلومه شوه چې د IoT او فوګ خلاصونونو ترمینځ ، اوسني پروتوکول حلونو کې MQTT ، CoAP او XMPP شامل دي. د فوګ او بادل ترمینځ ، له بلې خوا ، AMQP یو له اصلي پروتوکولونو څخه دی چې د REST HTTP سره کارول کیږي ، کوم چې د دې انعطاف له امله د IoT او فوګ پرتونو ترمینځ هم کارول کیږي.
دلته اصلي ستونزه د پروتوکولونو مداخله او له یو پروتوکول څخه بل ته د پیغامونو لیږد اسانه کول دي. په عین حال کې، په راتلونکي کې، د بادل او فوګ سرچینو سره د شیانو د انټرنیټ سیسټم جوړښت به د کارول شوي مخابراتي پروتوکول څخه خپلواک وي او د مختلف پروتوکولونو ترمینځ به ښه مداخله تضمین کړي.
څرنګه چې دا اوس مهال قضیه نده، دا د پروتوکولونو سره یوځای کولو لپاره معنی لري چې مهم توپیرونه نلري. د دې پای لپاره، یو احتمالي حل د دوو پروتوکولونو د ترکیب پر بنسټ والړ دی چې ورته معماري سټایل تعقیبوي، REST HTTP او CoAP. بل وړاندیز شوی حل د دوه پروتوکولونو ترکیب پراساس دی چې د خپریدو - سبسکرایب ارتباط وړاندیز کوي ، MQTT او AMQP. د ورته مفاهیمو کارول (د MQTT او AMQP دواړه بروکرز کاروي، CoAP او HTTP REST کاروي) دا ترکیبونه پلي کول اسانه کوي او لږ ادغام هڅو ته اړتیا لري.
شکل (a) د غوښتنې ځواب پر بنسټ دوه ماډلونه ښیې، HTTP او CoAP، او د IoT-F2C حل کې د دوی احتمالي ځای پرځای کول. څرنګه چې HTTP په عصري شبکو کې یو له خورا مشهور او منل شوي پروتوکولونو څخه دی ، نو امکان نلري چې دا به په بشپړ ډول د نورو پیغام رسولو پروتوکولونو لخوا ځای په ځای شي. د نوډونو په مینځ کې چې د قوي وسیلو نمایندګي کوي چې د بادل او فوګ ترمینځ ناست دي ، REST HTTP یو سمارټ حل دی.
له بلې خوا، د محدودو کمپیوټري سرچینو سره د وسیلو لپاره چې د فوګ او IoT پرتونو ترمنځ اړیکه لري، د CoAP کارول خورا اغیزمن دي. د CoAP یوه لویه ګټه په حقیقت کې د HTTP سره مطابقت دی ، ځکه چې دواړه پروتوکولونه د REST اصولو پراساس دي.
شکل (b) په ورته سناریو کې دوه د خپریدو - ګډون کولو ارتباط ماډلونه ښیې، په شمول د MQTT او AMQP. که څه هم دواړه پروتوکولونه په فرضي ډول د هر خلاصون پرت کې د نوډونو ترمینځ د ارتباط لپاره کارول کیدی شي ، د دوی موقعیت باید د فعالیت پراساس وټاکل شي. MQTT د محدود کمپیوټري سرچینو سره د وسیلو لپاره د سپک وزن پروتوکول په توګه ډیزاین شوی ، نو دا د IoT-Fog مخابراتو لپاره کارول کیدی شي. AMQP د ډیرو پیاوړو وسیلو لپاره خورا مناسب دی، کوم چې دا به په مثالي توګه د فوګ او بادل نوډونو ترمنځ موقعیت ولري. د MQTT پرځای، د XMPP پروتوکول په IoT کې کارول کیدی شي ځکه چې دا لږ وزن ګڼل کیږي. مګر دا په داسې سناریوګانو کې دومره پراخه نه کارول کیږي.
موندنو
دا امکان نلري چې د بحث شوي پروتوکولونو څخه یو به په سیسټم کې د ټولو مخابراتو پوښلو لپاره کافي وي ، د وسیلو څخه د محدود کمپیوټري سرچینو سره کلاوډ سرورونو ته. مطالعې وموندله چې دوه خورا ژمن انتخابونه چې پراختیا کونکي یې ډیری کاروي MQTT او RESTful HTTP دي. دا دوه پروتوکولونه نه یوازې خورا بالغ او باثباته دي، بلکې ډیری ښه مستند شوي او بریالي پلي کول او آنلاین سرچینې هم شامل دي.
د دې د ثبات او ساده ترتیب له امله، MQTT یو پروتوکول دی چې د وخت په تیریدو سره یې خپل غوره فعالیت ثابت کړی کله چې د محدودو وسیلو سره د IoT په کچه کارول کیږي. د سیسټم په برخو کې چیرې چې محدود مخابرات او د بیټرۍ مصرف مسله نده ، لکه ځینې فوګ ډومینونه او ډیری کلاوډ کمپیوټري ، RESTful HTTP یو اسانه انتخاب دی. CoAP هم باید په پام کې ونیول شي ځکه چې دا د IoT پیغام رسولو معیار په توګه هم په چټکۍ سره وده کوي او احتمال لري چې دا به په نږدې راتلونکي کې د MQTT او HTTP په څیر د ثبات او پختۍ کچې ته ورسیږي. مګر معیار اوس مهال وده کوي، کوم چې د لنډ مهاله مطابقت مسلو سره راځي.
تاسو په بلاګ کې نور څه لوستلی شئ؟
→
→
→
→
→
زموږ سره ګډون وکړئ - چینل نو تاسو راتلونکی مقاله له لاسه ورنکړئ! موږ په اونۍ کې له دوه ځله څخه ډیر نه لیکو او یوازې په سوداګرۍ کې.
سرچینه: www.habr.com