سافٹ ویئر اور ہارڈ ویئر کے میدان میں ٹیکنالوجیز کی ترقی، نئے کمیونیکیشن پروٹوکولز کا ابھرنا انٹرنیٹ آف تھنگز (IoT) کی توسیع کا باعث بنا ہے۔ ڈیوائسز کی تعداد روز بروز بڑھ رہی ہے اور وہ بہت زیادہ ڈیٹا تیار کر رہے ہیں۔ لہذا، اس ڈیٹا کو پروسیسنگ، اسٹور کرنے اور منتقل کرنے کے قابل ایک آسان سسٹم فن تعمیر کی ضرورت ہے۔
اب کلاؤڈ سروسز کو ان مقاصد کے لیے استعمال کیا جاتا ہے۔ تاہم، تیزی سے مقبول فوگ کمپیوٹنگ پیراڈیم (Fog) IoT انفراسٹرکچر کو اسکیلنگ اور بہتر بنا کر کلاؤڈ حل کی تکمیل کر سکتا ہے۔
بادل زیادہ تر IoT درخواستوں کو پورا کرنے کے قابل ہیں۔ مثال کے طور پر، خدمات کی نگرانی فراہم کرنے کے لیے، آلات کے ذریعے تیار کردہ ڈیٹا کی کسی بھی مقدار کی تیز رفتار پروسیسنگ کے ساتھ ساتھ ان کا تصور۔ ریئل ٹائم مسائل کو حل کرتے وقت فوگ کمپیوٹنگ زیادہ موثر ہوتی ہے۔ وہ درخواستوں کا تیز جواب اور ڈیٹا پروسیسنگ میں کم سے کم تاخیر فراہم کرتے ہیں۔ یعنی، دھند "بادلوں" کی تکمیل کرتی ہے اور اپنی صلاحیتوں کو وسعت دیتی ہے۔
تاہم، بنیادی سوال مختلف ہے: یہ سب IoT کے تناظر میں کیسے تعامل کرے؟ مشترکہ IoT-Fog-Cloud سسٹم میں کام کرتے وقت کون سے مواصلاتی پروٹوکول سب سے زیادہ موثر ہوں گے؟
HTTP کے واضح غلبے کے باوجود، IoT، Fog اور Cloud کے نظاموں میں استعمال ہونے والے دیگر حلوں کی ایک بڑی تعداد موجود ہے۔ اس کی وجہ یہ ہے کہ IoT کو صارفین کی سیکیورٹی، مطابقت اور دیگر ضروریات کے ساتھ متعدد ڈیوائس سینسرز کی فعالیت کو یکجا کرنا چاہیے۔
لیکن حوالہ فن تعمیر اور مواصلات کے معیار کے بارے میں کوئی واحد خیال نہیں ہے۔ لہذا، مخصوص IoT کاموں کے لیے ایک نیا پروٹوکول بنانا یا موجودہ میں ترمیم کرنا IT کمیونٹی کو درپیش سب سے اہم کاموں میں سے ایک ہے۔
اس وقت کون سے پروٹوکول استعمال میں ہیں اور وہ کیا پیش کر سکتے ہیں؟ آئیے اس کا پتہ لگائیں۔ لیکن پہلے، آئیے ماحولیاتی نظام کے اصولوں پر بات کرتے ہیں جس میں بادل، دھند اور چیزوں کا انٹرنیٹ آپس میں بات چیت کرتے ہیں۔
IoT فوگ ٹو کلاؤڈ (F2C) فن تعمیر
آپ نے شاید دیکھا ہو گا کہ IoT، کلاؤڈ اور فوگ کے سمارٹ اور مربوط انتظام سے وابستہ فوائد اور فوائد کو تلاش کرنے میں کتنی محنت کی جا رہی ہے۔ اگر نہیں، تو یہاں تین معیاری اقدامات ہیں: , и .
اگر پہلے صرف 2 سطحوں پر غور کیا جاتا تھا، بادل اور اختتامی آلات، تو مجوزہ فن تعمیر ایک نئی سطح - فوگ کمپیوٹنگ متعارف کراتا ہے۔ اس صورت میں، دھند کی سطح کو وسائل کی تفصیلات یا ان ذیلی سطحوں میں مختلف آلات کے استعمال کا تعین کرنے والی پالیسیوں کے سیٹ پر منحصر ہے، کئی ذیلی سطحوں میں تقسیم کیا جا سکتا ہے۔
یہ تجرید کیسا نظر آ سکتا ہے؟ یہاں ایک عام 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 بھی جاری کیا ہے۔ پیغام رسانی کے مسئلے کو حل کرنے کی کوشش میں، کئی دوسرے حل بنائے گئے ہیں، جیسے WebSockets پروٹوکول یا QUIC (کوئیک UDP انٹرنیٹ کنیکشنز) پر HTTP پروٹوکول کا استعمال۔
WebSockets کے معاملے میں، اگرچہ یہ ایک سرور سے ویب کلائنٹ کو حقیقی وقت میں ڈیٹا کی منتقلی کے لیے استعمال ہوتا ہے اور بیک وقت دو طرفہ مواصلات کے ساتھ مستقل کنکشن فراہم کرتا ہے، لیکن یہ محدود کمپیوٹنگ وسائل والے آلات کے لیے نہیں ہے۔ QUIC بھی توجہ کا مستحق ہے، کیونکہ نیا ٹرانسپورٹ پروٹوکول بہت سے نئے مواقع فراہم کرتا ہے۔ لیکن چونکہ QUIC ابھی تک معیاری نہیں ہے، اس لیے اس کے ممکنہ اطلاق اور IoT حل پر اثرات کی پیشین گوئی کرنا قبل از وقت ہے۔ لہذا ہم مستقبل پر نظر رکھتے ہوئے WebSockets اور QUIC کو ذہن میں رکھتے ہیں، لیکن ہم ابھی اس کا مزید تفصیل سے مطالعہ نہیں کریں گے۔
دنیا میں سب سے پیارا کون ہے: پروٹوکول کا موازنہ
اب بات کرتے ہیں پروٹوکول کی خوبیوں اور کمزوریوں پر۔ آگے دیکھتے ہوئے، آئیے فوری طور پر ایک ریزرویشن کریں کہ کوئی واضح لیڈر نہیں ہے۔ ہر پروٹوکول کے کچھ فوائد/نقصانات ہوتے ہیں۔
رسپانس کا وقت
مواصلاتی پروٹوکول کی سب سے اہم خصوصیات میں سے ایک، خاص طور پر چیزوں کے انٹرنیٹ کے سلسلے میں، ردعمل کا وقت ہے۔ لیکن موجودہ پروٹوکولز میں، کوئی واضح فاتح نہیں ہے جو مختلف حالات میں کام کرتے وقت تاخیر کی کم از کم سطح کو ظاہر کرتا ہو۔ لیکن پروٹوکول کی صلاحیتوں کی تحقیق اور موازنہ کا ایک پورا گروپ ہے۔
مثال کے طور پر، IoT کے ساتھ کام کرتے وقت HTTP اور MQTT کی تاثیر کا موازنہ ظاہر کرتا ہے کہ MQTT کی درخواستوں کے جواب کا وقت HTTP سے کم ہے۔ اور کب MQTT اور CoAP کے راؤنڈ ٹرپ ٹائم (RTT) نے انکشاف کیا کہ CoAP کا اوسط RTT MQTT سے 20% کم ہے۔
دیگر MQTT اور CoAP پروٹوکول کے لئے RTT کے ساتھ دو منظرناموں میں انجام دیا گیا تھا: مقامی نیٹ ورک اور IoT نیٹ ورک۔ یہ پتہ چلا کہ ایک IoT نیٹ ورک میں اوسط RTT 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 پر مبنی 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، MQTT، AMQP اور XMPP میں TLS، یا CoAP میں DTLS پر مبنی ہوتا ہے، اور DDS دونوں قسموں کو سپورٹ کرتا ہے۔
TLS اور DTLS کا آغاز کلائنٹ اور سرور سائیڈز کے درمیان تعاون یافتہ سائفر سویٹس اور کیز کے تبادلے کے لیے رابطہ قائم کرنے کے عمل سے ہوتا ہے۔ دونوں فریق اس بات کو یقینی بنانے کے لیے سیٹ پر گفت و شنید کرتے ہیں کہ محفوظ چینل پر مزید مواصلت ہو۔ دونوں کے درمیان فرق چھوٹی چھوٹی تبدیلیوں میں ہے جو UDP پر مبنی DTLS کو غیر معتبر کنکشن پر کام کرنے کی اجازت دیتی ہے۔
میں TLS اور DTLS کے متعدد مختلف نفاذ سے پتہ چلا کہ TLS نے بہتر کام کیا ہے۔ ڈی ٹی ایل ایس پر حملے اس کی غلطی کو برداشت کرنے کی وجہ سے زیادہ کامیاب تھے۔
تاہم، ان پروٹوکول کے ساتھ سب سے بڑا مسئلہ یہ ہے کہ وہ اصل میں IoT میں استعمال کے لیے نہیں بنائے گئے تھے اور ان کا مقصد دھند یا بادل میں کام کرنا نہیں تھا۔ مصافحہ کے ذریعے، وہ ہر کنکشن اسٹیبلشمنٹ کے ساتھ اضافی ٹریفک شامل کرتے ہیں، جس سے کمپیوٹنگ کے وسائل ختم ہوجاتے ہیں۔ اوسطاً، بغیر کسی حفاظتی پرت کے مواصلات کے مقابلے TLS کے لیے 6,5% اور اوور ہیڈ میں DTLS کے لیے 11% کا اضافہ ہے۔ وسائل سے بھرپور ماحول میں، جو عام طور پر واقع ہوتے ہیں۔ سطح، یہ کوئی مسئلہ نہیں ہوگا، لیکن IoT اور دھند کی سطح کے درمیان تعلق میں، یہ ایک اہم حد بن جاتا ہے۔
کیا انتخاب کرنا ہے؟ کوئی واضح جواب نہیں ہے۔ MQTT اور HTTP سب سے زیادہ امید افزا پروٹوکول لگتے ہیں کیونکہ انہیں دوسرے پروٹوکولز کے مقابلے نسبتاً زیادہ پختہ اور زیادہ مستحکم IoT حل سمجھا جاتا ہے۔
ایک متحد مواصلاتی پروٹوکول پر مبنی حل
سنگل پروٹوکول حل کی مشق کے بہت سے نقصانات ہیں۔ مثال کے طور پر، ایک پروٹوکول جو ایک محدود ماحول کے مطابق ہوتا ہے وہ ایسے ڈومین میں کام نہیں کر سکتا جس میں سخت حفاظتی تقاضے ہوں۔ اس بات کو ذہن میں رکھتے ہوئے، ہمیں MQTT اور REST HTTP کے علاوہ، IoT میں فوگ ٹو کلاؤڈ ایکو سسٹم میں تقریباً تمام ممکنہ سنگل پروٹوکول حل کو ضائع کرنے کے لیے چھوڑ دیا گیا ہے۔
REST HTTP ایک واحد پروٹوکول حل کے طور پر
اس کی ایک اچھی مثال ہے کہ کس طرح REST HTTP درخواستیں اور جوابات IoT-to-Fog جگہ میں تعامل کرتے ہیں: . جانور پہننے کے قابل سینسر (IoT کلائنٹ، C) سے لیس ہیں اور انہیں کلاؤڈ کمپیوٹنگ کے ذریعے سمارٹ فارمنگ سسٹم (فوگ سرور، ایس) کے ذریعے کنٹرول کیا جاتا ہے۔
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 لائبریری کے ساتھ ایک مقامی سرور ایک بروکر کے طور پر کام کرتا ہے۔ اس مثال میں، ایک سادہ کمپیوٹر (جسے فارم سرور کہا جاتا ہے) Raspberry Pi ایک MQTT کلائنٹ کے طور پر کام کرتا ہے، جسے Paho MQTT لائبریری کی تنصیب کے ذریعے لاگو کیا جاتا ہے، جو Mosquitto بروکر کے ساتھ پوری طرح مطابقت رکھتا ہے۔
یہ کلائنٹ ایک IoT تجریدی پرت سے مطابقت رکھتا ہے جو سینسنگ اور کمپیوٹنگ کی صلاحیتوں کے ساتھ ایک ڈیوائس کی نمائندگی کرتا ہے۔ دوسری طرف، ثالث، تجرید کی اعلی سطح کے مساوی ہے، جو ایک فوگ کمپیوٹنگ نوڈ کی نمائندگی کرتا ہے جس کی خصوصیت زیادہ پروسیسنگ اور اسٹوریج کی گنجائش ہوتی ہے۔
مجوزہ سمارٹ فارم کے منظر نامے میں، Raspberry Pi ایکسلرومیٹر، GPS، اور درجہ حرارت کے سینسرز سے جوڑتا ہے اور ان سینسرز سے ڈیٹا کو فوگ نوڈ پر شائع کرتا ہے۔ جیسا کہ آپ شاید جانتے ہوں گے، MQTT موضوعات کو ایک درجہ بندی کے طور پر دیکھتا ہے۔ ایک واحد MQTT پبلشر موضوعات کے مخصوص سیٹ پر پیغامات شائع کر سکتا ہے۔ ہمارے معاملے میں ان میں سے تین ہیں۔ ایک سینسر کے لیے جو جانوروں کے گودام میں درجہ حرارت کی پیمائش کرتا ہے، کلائنٹ ایک تھیم (جانوروں کا فارم/شیڈ/درجہ حرارت) منتخب کرتا ہے۔ ان سینسروں کے لیے جو ایکسلرومیٹر کے ذریعے GPS کے مقام اور جانوروں کی نقل و حرکت کی پیمائش کرتے ہیں، کلائنٹ (جانور فارم/جانور/جی پی ایس) اور (جانور فارم/جانور/حرکت) پر اپ ڈیٹ شائع کرے گا۔
یہ معلومات بروکر کو بھیج دی جائیں گی، جو بعد میں کوئی اور دلچسپی رکھنے والے سبسکرائبر کے آنے کی صورت میں اسے عارضی طور پر مقامی ڈیٹا بیس میں محفوظ کر سکتا ہے۔
مقامی سرور کے علاوہ، جو کہ دھند میں ایک MQTT بروکر کے طور پر کام کرتا ہے اور جس پر Raspberry Pis، MQTT کلائنٹس کے طور پر کام کرتا ہے، سینسر ڈیٹا بھیجتا ہے، بادل کی سطح پر ایک اور MQTT بروکر ہو سکتا ہے۔ اس صورت میں، مقامی بروکر کو بھیجی جانے والی معلومات کو عارضی طور پر مقامی ڈیٹا بیس میں محفوظ کیا جا سکتا ہے اور/یا کلاؤڈ کو بھیجا جا سکتا ہے۔ اس صورتحال میں فوگ MQTT بروکر کا استعمال تمام ڈیٹا کو کلاؤڈ MQTT بروکر کے ساتھ منسلک کرنے کے لیے کیا جاتا ہے۔ اس فن تعمیر کے ساتھ، ایک موبائل ایپلیکیشن صارف دونوں بروکرز کو سبسکرائب کیا جا سکتا ہے۔
اگر بروکرز (مثال کے طور پر، کلاؤڈ) میں سے کسی ایک سے رابطہ ناکام ہو جاتا ہے، تو آخری صارف دوسرے (دھند) سے معلومات حاصل کرے گا۔ یہ مشترکہ دھند اور کلاؤڈ کمپیوٹنگ سسٹم کی ایک خصوصیت ہے۔ پہلے سے طے شدہ طور پر، موبائل ایپ کو پہلے فوگ MQTT بروکر سے منسلک کرنے کے لیے کنفیگر کیا جا سکتا ہے، اور اگر یہ ناکام ہو جاتا ہے تو، کلاؤڈ MQTT بروکر سے منسلک ہونے کے لیے۔ یہ حل IoT-F2C سسٹمز میں بہت سے میں سے ایک ہے۔
ملٹی پروٹوکول حل
سنگل پروٹوکول حل ان کے آسان نفاذ کی وجہ سے مقبول ہیں۔ لیکن یہ واضح ہے کہ IoT-F2C سسٹمز میں مختلف پروٹوکولز کو یکجا کرنا سمجھ میں آتا ہے۔ خیال یہ ہے کہ مختلف پروٹوکول مختلف سطحوں پر کام کر سکتے ہیں۔ مثال کے طور پر، تین تجرید کو لیں: 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