سافٽ ويئر ۽ هارڊويئر جي شعبي ۾ ٽيڪنالاجيز جي ترقي، نئين ڪميونيڪيشن پروٽوڪول جي اڀرڻ سبب انٽرنيٽ جي شين (IoT) جي توسيع ٿي آهي. ڊوائيسز جو تعداد ڏينهون ڏينهن وڌي رهيو آهي ۽ اهي ڊيٽا جي وڏي مقدار ٺاهي رهيا آهن. تنهن ڪري، هن ڊيٽا کي پروسيسنگ، اسٽوريج ۽ منتقل ڪرڻ جي قابل هڪ آسان سسٽم فن تعمير جي ضرورت آهي.
ھاڻي ڪلائوڊ سروسز انھن مقصدن لاءِ استعمال ٿينديون آھن. بهرحال، وڌندڙ مقبول فوگ ڪمپيوٽنگ پيراڊم (Fog) ڪلائوڊ حل کي مڪمل ڪري سگھي ٿو IoT انفراسٽرڪچر کي اسڪيلنگ ۽ بهتر ڪرڻ سان.
بادل سڀ کان وڌيڪ IoT درخواستن کي ڍڪڻ جي قابل آهن. مثال طور، خدمتن جي نگراني مهيا ڪرڻ لاء، ڊوائيسز پاران ٺاهيل ڊيٽا جي ڪنهن به مقدار جي تيز پروسيسنگ، ۽ انهي سان گڏ انهن جي بصريت. فوگ ڪمپيوٽنگ وڌيڪ اثرائتو آهي جڏهن حقيقي وقت جي مسئلن کي حل ڪرڻ. اهي درخواستن تي تيز جواب ۽ ڊيٽا پروسيسنگ ۾ گهٽ ۾ گهٽ ويڪرائي فراهم ڪن ٿا. اهو آهي، فوگ "بادل" کي پورو ڪري ٿو ۽ ان جي صلاحيتن کي وڌائي ٿو.
بهرحال، بنيادي سوال مختلف آهي: اهو سڀ ڪجهه IoT جي حوالي سان ڪيئن مداخلت ڪرڻ گهرجي؟ گڏيل IoT-Fog-Cloud سسٽم ۾ ڪم ڪرڻ دوران ڪهڙن ڪميونيڪيشن پروٽوڪول تمام گهڻو اثرائتو ٿيندو؟
HTTP جي ظاهري تسلط جي باوجود، IoT، Fog ۽ Cloud سسٽم ۾ استعمال ٿيل ٻيا حل موجود آهن. اهو ئي سبب آهي ته IoT کي لازمي طور تي مختلف ڊوائيس سينسر جي ڪارڪردگي کي گڏ ڪرڻ گهرجي سيڪيورٽي، مطابقت، ۽ صارفين جي ٻين گهرجن سان.
پر حوالن جي فن تعمير ۽ مواصلاتي معيار جي باري ۾ صرف ڪو به خيال ناهي. تنهن ڪري، هڪ نئون پروٽوڪول ٺاهڻ يا مخصوص IoT ڪمن لاءِ موجوده هڪ کي تبديل ڪرڻ IT ڪميونٽي کي منهن ڏيڻ وارو سڀ کان اهم ڪم آهي.
ڪهڙا پروٽوڪول هن وقت استعمال ۾ آهن ۽ اهي ڇا پيش ڪري سگهن ٿا؟ اچو ته ان جو اندازو لڳايو. پر پهرين، اچو ته ماحوليات جي اصولن تي بحث ڪريون جنهن ۾ ڪڪر، ڪوهيڙو ۽ شين جو انٽرنيٽ پاڻ ۾ ملن ٿا.
IoT Fog-to-Cloud (F2C) آرڪيٽيڪچر
توهان شايد محسوس ڪيو آهي ته IoT، ڪلائوڊ ۽ فوگ جي سمارٽ ۽ مربوط انتظام سان لاڳاپيل فائدن ۽ فائدن کي ڳولڻ ۾ ڪيتري ڪوشش ڪئي پئي وڃي. جيڪڏهن نه، پوء هتي ٽي معيار جي شروعات آهن: , и .
جيڪڏهن اڳ ۾ صرف 2 سطح تي غور ڪيو ويو، بادل ۽ آخر ڊوائيسز، پوء تجويز ڪيل فن تعمير هڪ نئين سطح متعارف ڪرايو - fog computing. انهي صورت ۾، فوگ جي سطح کي ڪيترن ئي ذيلي سطحن ۾ ورهائي سگهجي ٿو، وسيلن جي خاصيتن يا پاليسين جي هڪ سيٽ تي منحصر ڪري ٿو جيڪي انهن ذيلي سطحن ۾ مختلف ڊوائيسز جي استعمال کي طئي ڪن ٿا.
هي خلاصو ڇا ٿي سگهي ٿو؟ هتي هڪ عام IoT-Fog-Cloud ecosystem آهي. IoT ڊوائيسز ڊيٽا موڪلين ٿيون تيز سرورز ۽ ڪمپيوٽنگ ڊوائيسز کي مسئلا حل ڪرڻ لاءِ جيڪي گھٽ ويڪرائي جي ضرورت هونديون آهن. ساڳئي سسٽم ۾، بادل انهن مسئلن کي حل ڪرڻ جا ذميوار آهن جيڪي وڏي مقدار ۾ ڪمپيوٽنگ وسيلن يا ڊيٽا اسٽوريج جي جڳهه جي ضرورت هونديون آهن.
اسمارٽ فونز، سمارٽ واچون ۽ ٻيا گيجٽ به IoT جو حصو ٿي سگھن ٿا. پر اهڙيون ڊوائيسز، ضابطي جي طور تي، وڏي ڊولپرز کان ملڪيت جي مواصلاتي پروٽوڪول استعمال ڪن ٿا. ٺاهيل IoT ڊيٽا REST HTTP پروٽوڪول ذريعي فوگ پرت ڏانهن منتقل ڪيو ويندو آهي، جيڪو RESTful خدمتون ٺاهڻ وقت لچڪدار ۽ باضابطه ڪارڪردگي فراهم ڪري ٿو. اهو ضروري آهي ته مقامي ڪمپيوٽرن، سرورز يا سرور ڪلسٽر تي هلندڙ موجوده ڪمپيوٽنگ انفراسٽرڪچر سان پسمانده مطابقت کي يقيني بڻائڻ جي ضرورت جي روشني ۾. مقامي وسيلا، جن کي "فگ نوڊس" سڏيو ويندو آهي، وصول ڪيل ڊيٽا کي فلٽر ڪريو ۽ ان کي مقامي طور تي پروسيس ڪريو يا وڌيڪ حسابن لاءِ بادل ڏانهن موڪليو.
بادل مختلف ڪميونيڪيشن پروٽوڪولن جي حمايت ڪن ٿا، سڀ کان عام AMQP ۽ REST HTTP. جيئن ته HTTP مشهور آهي ۽ انٽرنيٽ لاءِ ٺهيل آهي، اهو سوال پيدا ٿي سگهي ٿو: "ڇا اسان ان کي IoT ۽ fog سان ڪم ڪرڻ لاءِ استعمال نٿا ڪريون؟" بهرحال، هن پروٽوڪول ۾ ڪارڪردگي مسئلا آهن. انهي تي وڌيڪ بعد ۾.
عام طور تي، ڪميونيڪيشن پروٽوڪول جا 2 ماڊل آھن موزون سسٽم لاءِ جنھن جي اسان کي ضرورت آھي. اهي آهن درخواست-جواب ۽ شايع ڪرڻ-سبسڪرائب. پهريون ماڊل وڌيڪ وڏي پيماني تي سڃاتل آهي، خاص طور تي سرور ڪلائنٽ فن تعمير ۾. ڪلائنٽ سرور کان معلومات جي درخواست ڪري ٿو، ۽ سرور درخواست وصول ڪري ٿو، ان کي پروسيس ڪري ٿو ۽ جوابي پيغام واپس ڪري ٿو. REST HTTP ۽ CoAP پروٽوڪول هن ماڊل تي هلن ٿا.
ٻيو ماڊل ڊيٽا پيدا ڪندڙ ذريعن ۽ هن ڊيٽا جي وصول ڪندڙن جي وچ ۾ غير مطابقت، ورهايل، لوز جوڙيل مهيا ڪرڻ جي ضرورت مان پيدا ٿيو.
ماڊل ٽن شرڪت ڪندڙن کي فرض ڪري ٿو: هڪ پبلشر (ڊيٽا جو ذريعو)، هڪ بروکر (ڊسپيچر) ۽ هڪ سبسڪرائبر (وصول ڪندڙ). هتي، صارف جي طور تي ڪم ڪندڙ ڪلائنٽ کي سرور کان معلومات جي درخواست ڪرڻ جي ضرورت ناهي. درخواستون موڪلڻ جي بدران، اهو هڪ بروکر ذريعي سسٽم ۾ ڪجهه واقعن جي رڪنيت حاصل ڪري ٿو، جيڪو سڀني ايندڙ پيغامن کي فلٽر ڪرڻ ۽ پبلشرز ۽ سبسڪرائبرن جي وچ ۾ روٽ ڪرڻ جو ذميوار آهي. ۽ پبلشر، جڏهن ڪو واقعو ڪنهن خاص موضوع جي حوالي سان ٿئي ٿو، اهو بروکر ڏانهن شايع ڪري ٿو، جيڪو درخواست ڪيل موضوع تي ڊيٽا موڪلي ٿو سبسڪرائبر ڏانهن.
لازمي طور تي، هي فن تعمير واقعي تي ٻڌل آهي. ۽ هي رابطي وارو ماڊل IoT، ڪلائوڊ، فوگ ۾ ايپليڪيشنن لاءِ دلچسپ آهي ڇاڪاڻ ته ان جي قابليت جي گنجائش مهيا ڪرڻ ۽ مختلف ڊوائيسز جي وچ ۾ ڪنيڪشن کي آسان ڪرڻ، متحرڪ گھڻن کان گھڻن ڪميونيڪيشن ۽ هم وقت سازي ڪميونيڪيشن کي سپورٽ ڪري ٿو. ڪجھ سڀ کان وڌيڪ معروف معياري پيغام رسائيندڙ پروٽوڪول جيڪي استعمال ڪن ٿا پبلش-سبسڪرائب ماڊل شامل آھن MQTT، AMQP، ۽ DDS.
ظاهر آهي، شايع ڪرڻ-سبسڪرائب ماڊل جا ڪيترائي فائدا آهن:
- پبلشرز ۽ رڪنن کي هڪ ٻئي جي وجود بابت ڄاڻڻ جي ضرورت ناهي؛
- ھڪڙو سبسڪرائبر ڪيترن ئي مختلف اشاعتن کان معلومات حاصل ڪري سگھي ٿو، ۽ ھڪڙو پبلشر ڪيترن ئي مختلف رڪنن کي ڊيٽا موڪلي سگھي ٿو (گھڻن کان گھڻن اصولن)؛
- پبلشر ۽ سبسڪرائبر کي رابطي لاءِ هڪ ئي وقت سرگرم ٿيڻ جي ضرورت ناهي، ڇو ته بروکر (قطار واري نظام جي طور تي ڪم ڪري رهيو آهي) انهن ڪلائنٽ لاءِ پيغام محفوظ ڪري سگهندو جيڪي هن وقت نيٽ ورڪ سان جڙيل نه آهن.
بهرحال، درخواست-جواب ماڊل پڻ ان جي طاقت آهي. ڪيسن ۾ جتي سرور طرف جي صلاحيت ڪيترن ئي ڪلائنٽ جي درخواستن کي سنڀالڻ جو مسئلو ناهي، اهو ثابت، قابل اعتماد حل استعمال ڪرڻ جو احساس آهي.
اهڙا پروٽوڪول پڻ آهن جيڪي ٻنهي ماڊل جي حمايت ڪن ٿيون. مثال طور، XMPP ۽ HTTP 2.0، جيڪو "سرور پش" اختيار کي سپورٽ ڪري ٿو. IETF پڻ هڪ CoAP جاري ڪيو آهي. پيغامن جي مسئلي کي حل ڪرڻ جي ڪوشش ۾، ٻيا ڪيترائي حل ٺاھيا ويا آھن، جھڙوڪ WebSockets پروٽوڪول يا HTTP پروٽوڪول جو استعمال QUIC (Quick UDP انٽرنيٽ ڪنيڪشن).
WebSockets جي صورت ۾، جيتوڻيڪ اهو حقيقي وقت ۾ ڊيٽا کي سرور کان ويب ڪلائنٽ ڏانهن منتقل ڪرڻ لاء استعمال ڪيو ويندو آهي ۽ مسلسل ڪنيڪشن فراهم ڪري ٿو هڪ ئي وقت ۾ ٻه طرفي رابطي سان، اهو مقصد نه آهي ڊوائيسز لاء محدود ڪمپيوٽنگ وسيلن سان. QUIC پڻ توجه جو مستحق آهي، ڇو ته نئون ٽرانسپورٽ پروٽوڪول ڪيترائي نوان موقعا فراهم ڪري ٿو. پر جيئن ته QUIC اڃا معياري نه آهي، ان جي ممڪن ايپليڪيشن ۽ IoT حلن تي اثر جي اڳڪٿي ڪرڻ وقت کان اڳ آهي. تنهن ڪري اسان WebSockets ۽ QUIC کي ذهن ۾ رکون ٿا مستقبل کي نظر ۾ رکندي، پر اسان ان کي في الحال وڌيڪ تفصيل سان مطالعو نه ڪنداسين.
دنيا ۾ سڀ کان پيارو ڪير آهي: پروٽوڪول جي مقابلي ۾
هاڻي اچو ته پروٽوڪول جي طاقت ۽ ڪمزورين بابت ڳالهايون. اڳتي ڏسي، اچو ته فوري طور تي هڪ رزرويشن ڪريون ته ڪو به واضح اڳواڻ ناهي. هر پروٽوڪول جا ڪي فائدا/نقصان آهن.
جواب ڏيڻ جو وقت
مواصلاتي پروٽوڪول جي سڀ کان اهم خاصيتن مان هڪ، خاص طور تي شين جي انٽرنيٽ جي حوالي سان، جوابي وقت آهي. پر موجوده پروٽوڪول ۾، ڪو به واضح فاتح نه آهي جيڪو ظاهر ڪري ٿو گهٽ ۾ گهٽ ويڪرائي جي سطح جڏهن مختلف حالتن ۾ ڪم ڪندي. پر تحقيق جو هڪ سڄو گروپ آهي ۽ پروٽوڪول جي صلاحيتن جي مقابلي ۾.
مثال طور، ايڇ ٽي ٽي پي ۽ ايم ڪيو ٽي ٽي جي تاثير جي مقابلي ۾ جڏهن IoT سان ڪم ڪندي اهو ظاهر ڪيو ته MQTT لاءِ درخواستن جو جواب وقت HTTP کان گهٽ آهي. ۽ ڪڏهن MQTT ۽ CoAP جي گول ٽرپ ٽائيم (RTT) ظاهر ڪيو ته CoAP جو سراسري RTT MQTT جي ڀيٽ ۾ 20٪ گهٽ آهي.
ٻيا MQTT ۽ CoAP پروٽوڪول لاءِ RTT سان ٻن منظرنامي ۾ ڪيو ويو: مقامي نيٽ ورڪ ۽ IoT نيٽ ورڪ. اهو ظاهر ٿيو ته اوسط RTT هڪ IoT نيٽ ورڪ ۾ 2-3 ڀيرا وڌيڪ آهي. QoS0 سان MQTT CoAP جي مقابلي ۾ گهٽ نتيجو ڏيکاريو، ۽ QoS1 سان MQTT هڪ اعلي RTT ڏيکاريو ACKs جي ڪري ايپليڪيشن ۽ ٽرانسپورٽ پرت تي. مختلف 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 بجلي استعمال ڪن ٿا، ايڇ ٽي ٽي پي تمام گهڻو استعمال ڪري ٿو. ۽ CoAP وڌيڪ آهي MQTT جي مقابلي ۾، طاقت جي انتظام جي اجازت ڏئي ٿي. بهرحال، سادي حالتن ۾، MQTT وڌيڪ موزون آهي معلومات جي مٽاسٽا لاءِ انٽرنيٽ آف ٿنگس نيٽ ورڪن ۾، خاص طور تي جيڪڏهن پاور پابنديون نه آهن.
هڪ تجربو جيڪو موبائيل يا غير مستحڪم وائرليس نيٽ ورڪ ٽيسٽ بيڊ تي AMQP ۽ MQTT جي صلاحيتن جو مقابلو ڪيو اهو معلوم ٿيو ته AMQP وڌيڪ حفاظتي صلاحيتون پيش ڪري ٿو جڏهن ته MQTT وڌيڪ توانائي وارو آهي.
حفاظت
سيڪيورٽي هڪ ٻيو نازڪ مسئلو اٿاريو ويو آهي جڏهن انٽرنيٽ جي شين ۽ فوگ / ڪلائوڊ ڪمپيوٽنگ جي موضوع جو مطالعو ڪيو وڃي. سيڪيورٽي ميڪانيزم عام طور تي TLS تي HTTP، MQTT، AMQP ۽ XMPP، يا CoAP ۾ DTLS تي ٻڌل آهي، ۽ ٻنهي DDS مختلف قسمن کي سپورٽ ڪري ٿو.
TLS ۽ DTLS ڪلائنٽ ۽ سرور جي طرفن جي وچ ۾ رابطي کي قائم ڪرڻ جي عمل سان شروع ٿئي ٿو مدد ڪيل سائفر سوٽ ۽ چابين کي مٽائڻ لاء. ٻئي پارٽيون سيٽن تي ڳالهين کي يقيني بڻائين ٿيون ته وڌيڪ مواصلات هڪ محفوظ چينل تي ٿئي ٿي. ٻنھي جي وچ ۾ فرق ننڍين ترميمن ۾ آھي جيڪي UDP-based DTLS کي غير معتبر ڪنيڪشن تي ڪم ڪرڻ جي اجازت ڏين ٿا.
تي TLS ۽ DTLS جا ڪيترائي مختلف عمل مليا ته TLS هڪ بهتر ڪم ڪيو. DTLS تي حملا وڌيڪ ڪامياب هئا ان جي غلطي برداشت جي ڪري.
جڏهن ته، انهن پروٽوڪول سان گڏ سڀ کان وڏو مسئلو اهو آهي ته اهي اصل ۾ IoT ۾ استعمال لاء ٺهيل نه هئا ۽ ڪوهي يا ڪڪر ۾ ڪم ڪرڻ جو ارادو نه هئا. هٿ ملائڻ جي ذريعي، اهي هر ڪنيڪشن اسٽيبلشمينٽ سان اضافي ٽرئفڪ شامل ڪن ٿا، جيڪي ڪمپيوٽنگ جا وسيلا ختم ڪن ٿا. سراسري طور تي، TLS لاءِ 6,5٪ جو اضافو آهي ۽ DTLS لاءِ 11٪ اوور هيڊ ۾ ڪميونيڪيشن جي مقابلي ۾ سيڪيورٽي پرت کان سواءِ. وسيلن سان مالا مال ماحول ۾، جيڪي عام طور تي واقع آهن سطح تي، اهو ڪو مسئلو نه ٿيندو، پر IoT ۽ فوگ ليول جي وچ ۾ رابطي ۾، هي هڪ اهم حد بڻجي ويندو آهي.
ڇا چونڊڻ لاء؟ ڪو به واضح جواب نه آهي. MQTT ۽ HTTP نظر اچن ٿا سڀ کان وڌيڪ پروموشنل پروٽوڪول آهن جيئن اهي سمجهي رهيا آهن نسبتا وڌيڪ پختو ۽ وڌيڪ مستحڪم IoT حل ٻين پروٽوڪول جي مقابلي ۾.
حل هڪ متحد مواصلاتي پروٽوڪول جي بنياد تي
ھڪڙي پروٽوڪول حل جي مشق ۾ ڪيترائي نقصان آھن. مثال طور، هڪ پروٽوڪول جيڪو هڪ محدود ماحول کي مناسب ڪري ٿو اهو ڊومين ۾ ڪم نٿو ڪري سگهي جنهن ۾ سخت حفاظتي گهرجون آهن. انهي کي ذهن ۾ رکڻ سان، اسان IoT ۾ Fog-to-Cloud ecosystem ۾ تقريبن سڀني ممڪن واحد پروٽوڪول حلن کي رد ڪرڻ ڇڏي ڏنو آهي، سواء MQTT ۽ REST HTTP.
REST HTTP هڪ واحد پروٽوڪول حل جي طور تي
هتي هڪ سٺو مثال آهي ته ڪيئن REST HTTP درخواستون ۽ ردعمل IoT-to-Fog اسپيس ۾ لهه وچڙ ۾ اچن ٿا: . جانورن کي wearable sensors (IoT ڪلائنٽ، C) سان ليس آهي ۽ ڪلائوڊ ڪمپيوٽنگ ذريعي سمارٽ فارمنگ سسٽم (Fog server, S) ذريعي ڪنٽرول ڪيو ويندو آهي.
پوسٽ جي طريقي جو هيڊر وضاحت ڪري ٿو وسيلا تبديل ڪرڻ لاءِ (/فارم/جانور) سان گڏو گڏ 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 لائبريري سان گڏ هڪ بروکر طور ڪم ڪري ٿو. هن مثال ۾، هڪ سادو ڪمپيوٽر (جنهن کي فارم سرور جو حوالو ڏنو ويو آهي) Raspberry Pi هڪ MQTT ڪلائنٽ جي طور تي ڪم ڪري ٿو، Paho MQTT لائبريري جي انسٽاليشن ذريعي لاڳو ڪيو ويو آهي، جيڪو مڪمل طور تي Mosquitto بروکر سان مطابقت رکي ٿو.
هي ڪلائنٽ هڪ IoT تجريدي پرت سان ملندو آهي جيڪو هڪ ڊوائيس جي نمائندگي ڪري ٿو سينسنگ ۽ ڪمپيوٽنگ جي صلاحيتن سان. ثالث، ٻئي طرف، هڪ اعلي سطحي تجريد سان ملندو آهي، هڪ فوگ ڪمپيوٽنگ نوڊ جي نمائندگي ڪري ٿو جيڪو وڌيڪ پروسيسنگ ۽ اسٽوريج جي صلاحيت سان منسوب ڪيو ويو آهي.
تجويز ڪيل سمارٽ فارم جي منظرنامي ۾، Raspberry Pi accelerometer، GPS، ۽ گرمي پد جي سينسر سان ڳنڍي ٿي ۽ انهن سينسرز مان ڊيٽا کي فوگ نوڊ تائين شايع ڪري ٿي. جئين توهان شايد ڄاڻو ٿا، MQTT عنوانن کي هڪ درجي جي حيثيت سان علاج ڪري ٿو. هڪ واحد MQTT پبلشر پيغامن کي شايع ڪري سگھي ٿو مخصوص سيٽن تي. اسان جي صورت ۾ اتي انھن مان ٽي آهن. هڪ سينسر لاءِ جيڪو جانورن جي بارن ۾ درجه حرارت کي ماپيندو آهي، ڪلائنٽ هڪ موضوع چونڊيندو آهي (جانور فارم/شيڊ/درجه حرارت). سينسرز لاءِ جيڪي GPS جي جڳھ ۽ جانورن جي حرڪت کي ايڪليروميٽر ذريعي ماپيندا آھن، ڪلائنٽ (جانور فارم/جانور/GPS) ۽ (جانور فارم/جانور/حرکت) تي تازه ڪاريون شايع ڪندو.
اها معلومات بروکر ڏانهن منتقل ڪئي ويندي، جيڪو ان کي عارضي طور تي مقامي ڊيٽابيس ۾ محفوظ ڪري سگهي ٿو جيڪڏهن ٻيو دلچسپي رکندڙ رڪن بعد ۾ اچي.
مقامي سرور کان علاوه، جيڪو فوگ ۾ هڪ MQTT بروکر جي طور تي ڪم ڪري ٿو ۽ جنهن تي Raspberry Pis، MQTT ڪلائنٽ طور ڪم ڪري ٿو، سينسر ڊيٽا موڪلي ٿو، اتي بادل سطح تي هڪ ٻيو MQTT بروکر ٿي سگهي ٿو. انهي صورت ۾، مقامي بروکر ڏانهن منتقل ڪيل معلومات کي عارضي طور تي مقامي ڊيٽابيس ۾ محفوظ ڪري سگهجي ٿو ۽ / يا بادل ڏانهن موڪليو ويو. هن صورتحال ۾ فوگ MQTT بروکر استعمال ڪيو ويندو آهي سڀني ڊيٽا کي ڪلائوڊ MQTT بروکر سان لاڳاپيل ڪرڻ لاءِ. هن فن تعمير سان، هڪ موبائل ايپليڪيشن صارف ٻنهي بروکرز جي رڪنيت حاصل ڪري سگهي ٿي.
جيڪڏهن بروکرز مان هڪ سان ڪنيڪشن (مثال طور، ڪلائوڊ) ناڪام ٿئي ٿو، آخري صارف ٻئي کان معلومات حاصل ڪندو (فگ). هي گڏيل فوگ ۽ ڪلائوڊ ڪمپيوٽنگ سسٽم جي هڪ خاص خصوصيت آهي. ڊفالٽ طور، موبائيل ايپ کي ترتيب ڏئي سگھجي ٿو ڳنڍڻ لاءِ پھريائين فوگ MQTT بروکر سان، ۽ جيڪڏھن اھو ناڪام ٿئي ٿو، بادل MQTT بروکر سان ڳنڍڻ لاءِ. اهو حل صرف IoT-F2C سسٽم ۾ ڪيترن ئي مان هڪ آهي.
ملٽي پروٽوڪول حل
سنگل پروٽوڪول حل مقبول آهن انهن جي آسان عمل جي ڪري. پر اهو واضح آهي ته IoT-F2C سسٽم ۾ مختلف پروٽوڪول کي گڏ ڪرڻ جو احساس آهي. خيال اهو آهي ته مختلف پروٽوڪول مختلف سطحن تي ڪم ڪري سگهن ٿا. وٺو، مثال طور، ٽي خلاصيون: IoT جي تہه، فوگ ۽ ڪلائوڊ ڪمپيوٽنگ. IoT سطح تي ڊوائيسز عام طور تي محدود سمجهيا وڃن ٿا. هن جائزي لاءِ، اچو ته غور ڪريون IoT ٽائرز کي سڀ کان وڌيڪ محدود، ڪلائوڊ سڀ کان گهٽ محدود، ۽ فوگ ڪمپيوٽنگ کي ”ڪٿي ڪٿي وچ ۾“. ان کان پوء اهو ظاهر ٿئي ٿو ته IoT ۽ fog abstractions جي وچ ۾، موجوده پروٽوڪول حل شامل آهن MQTT، CoAP ۽ XMPP. دھند ۽ بادل جي وچ ۾، ٻئي طرف، AMQP استعمال ٿيل مکيه پروٽوڪول مان ھڪڙو آھي، REST HTTP سان گڏ، جنھن جي لچڪ جي ڪري IoT ۽ fog تہن جي وچ ۾ پڻ استعمال ڪيو ويندو آھي.
هتي بنيادي مسئلو پروٽوڪول جي مداخلت ۽ هڪ پروٽوڪول کان ٻئي ڏانهن پيغامن جي منتقلي جي آسانيء جو آهي. مثالي طور تي، مستقبل ۾، ڪلائوڊ ۽ فوگ وسيلن سان گڏ هڪ انٽرنيٽ آف شين سسٽم جو فن تعمير استعمال ٿيل ڪميونيڪيشن پروٽوڪول کان آزاد هوندو ۽ مختلف پروٽوڪولن جي وچ ۾ سٺي مداخلت کي يقيني بڻائيندو.
جيئن ته في الحال اهو معاملو ناهي، اهو پروٽوڪول کي گڏ ڪرڻ جو احساس آهي جنهن ۾ اهم اختلاف نه آهن. انهي جي پڇاڙيء ۾، هڪ امڪاني حل ٻن پروٽوڪول جي ميلاپ تي ٻڌل آهي جيڪي ساڳئي تعميراتي انداز جي پيروي ڪندا آهن، 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