IoT, कोहरा और बादल: आइए प्रौद्योगिकी के बारे में बात करें?

सॉफ्टवेयर और हार्डवेयर के क्षेत्र में प्रौद्योगिकियों के विकास, नए संचार प्रोटोकॉल के उद्भव से इंटरनेट ऑफ थिंग्स (IoT) का विस्तार हुआ है। उपकरणों की संख्या दिन-ब-दिन बढ़ती जा रही है और वे भारी मात्रा में डेटा उत्पन्न कर रहे हैं। इसलिए, इस डेटा को संसाधित करने, संग्रहीत करने और प्रसारित करने में सक्षम एक सुविधाजनक सिस्टम आर्किटेक्चर की आवश्यकता है।

अब इन उद्देश्यों के लिए क्लाउड सेवाओं का उपयोग किया जाता है। हालाँकि, तेजी से लोकप्रिय फॉग कंप्यूटिंग प्रतिमान (फॉग) IoT बुनियादी ढांचे को स्केलिंग और अनुकूलित करके क्लाउड समाधानों को पूरक कर सकता है।

क्लाउड अधिकांश IoT अनुरोधों को कवर करने में सक्षम हैं। उदाहरण के लिए, सेवाओं की निगरानी, ​​उपकरणों द्वारा उत्पन्न किसी भी मात्रा में डेटा का तेज़ प्रसंस्करण, साथ ही उनका विज़ुअलाइज़ेशन प्रदान करना। वास्तविक समय की समस्याओं को हल करते समय कोहरे की गणना अधिक प्रभावी होती है। वे अनुरोधों पर तीव्र प्रतिक्रिया और डेटा प्रोसेसिंग में न्यूनतम विलंबता प्रदान करते हैं। अर्थात्, कोहरा "बादलों" का पूरक है और इसकी क्षमताओं का विस्तार करता है।

हालाँकि, मुख्य प्रश्न अलग है: IoT के संदर्भ में यह सब कैसे परस्पर क्रिया करनी चाहिए? संयुक्त IoT-फॉग-क्लाउड सिस्टम में काम करते समय कौन से संचार प्रोटोकॉल सबसे प्रभावी होंगे?

HTTP के स्पष्ट प्रभुत्व के बावजूद, IoT, फ़ॉग और क्लाउड सिस्टम में बड़ी संख्या में अन्य समाधानों का उपयोग किया जाता है। ऐसा इसलिए है क्योंकि IoT को उपयोगकर्ताओं की सुरक्षा, अनुकूलता और अन्य आवश्यकताओं के साथ विभिन्न डिवाइस सेंसर की कार्यक्षमता को जोड़ना होगा।

लेकिन संदर्भ वास्तुकला और संचार मानक के बारे में कोई एक विचार नहीं है। इसलिए, विशिष्ट IoT कार्यों के लिए एक नया प्रोटोकॉल बनाना या मौजूदा को संशोधित करना आईटी समुदाय के सामने आने वाले सबसे महत्वपूर्ण कार्यों में से एक है।

वर्तमान में कौन से प्रोटोकॉल उपयोग में हैं और वे क्या पेशकश कर सकते हैं? आइए इसका पता लगाएं। लेकिन पहले, आइए पारिस्थितिकी तंत्र के सिद्धांतों पर चर्चा करें जिसमें बादल, कोहरा और इंटरनेट ऑफ थिंग्स परस्पर क्रिया करते हैं।

IoT फॉग-टू-क्लाउड (F2C) आर्किटेक्चर

आपने शायद देखा होगा कि IoT, क्लाउड और फॉग के स्मार्ट और समन्वित प्रबंधन से जुड़े फायदों और लाभों की खोज में कितना प्रयास किया जा रहा है। यदि नहीं, तो यहां तीन मानकीकरण पहल हैं: ओपनफॉग कंसोर्टियम, एज कंप्यूटिंग कंसोर्टियम и mF2C H2020 EU प्रोजेक्ट.

यदि पहले केवल 2 स्तरों पर विचार किया जाता था, क्लाउड और अंतिम डिवाइस, तो प्रस्तावित आर्किटेक्चर एक नया स्तर - फॉग कंप्यूटिंग पेश करता है। इस मामले में, कोहरे के स्तर को संसाधनों की विशिष्टताओं या नीतियों के एक सेट के आधार पर कई उप-स्तरों में विभाजित किया जा सकता है, जो इन उप-स्तरों में विभिन्न उपकरणों के उपयोग को निर्धारित करते हैं।

यह अमूर्तता कैसी दिख सकती है? यहां एक विशिष्ट IoT-फॉग-क्लाउड पारिस्थितिकी तंत्र है। IoT डिवाइस कम विलंबता की आवश्यकता वाली समस्याओं को हल करने के लिए तेज़ सर्वर और कंप्यूटिंग डिवाइसों को डेटा भेजते हैं। उसी प्रणाली में, क्लाउड उन समस्याओं को हल करने के लिए जिम्मेदार होते हैं जिनके लिए बड़ी मात्रा में कंप्यूटिंग संसाधनों या डेटा भंडारण स्थान की आवश्यकता होती है।

स्मार्टफोन, स्मार्ट घड़ियाँ और अन्य गैजेट भी IoT का हिस्सा हो सकते हैं। लेकिन ऐसे उपकरण, एक नियम के रूप में, बड़े डेवलपर्स के मालिकाना संचार प्रोटोकॉल का उपयोग करते हैं। उत्पन्न IoT डेटा को REST HTTP प्रोटोकॉल के माध्यम से फ़ॉग लेयर में स्थानांतरित किया जाता है, जो RESTful सेवाएँ बनाते समय लचीलापन और इंटरऑपरेबिलिटी प्रदान करता है। स्थानीय कंप्यूटर, सर्वर या सर्वर क्लस्टर पर चल रहे मौजूदा कंप्यूटिंग बुनियादी ढांचे के साथ बैकवर्ड संगतता सुनिश्चित करने की आवश्यकता के मद्देनजर यह महत्वपूर्ण है। स्थानीय संसाधन, जिन्हें "फॉग नोड्स" कहा जाता है, प्राप्त डेटा को फ़िल्टर करते हैं और इसे स्थानीय रूप से संसाधित करते हैं या आगे की गणना के लिए क्लाउड पर भेजते हैं।

क्लाउड विभिन्न संचार प्रोटोकॉल का समर्थन करते हैं, जिनमें सबसे आम AMQP और REST HTTP हैं। चूंकि HTTP अच्छी तरह से जाना जाता है और इंटरनेट के लिए तैयार किया गया है, इसलिए यह सवाल उठ सकता है: "क्या हमें इसका उपयोग IoT और फॉग के साथ काम करने के लिए नहीं करना चाहिए?" हालाँकि, इस प्रोटोकॉल में प्रदर्शन संबंधी समस्याएँ हैं। इस पर बाद में और अधिक जानकारी।

सामान्य तौर पर, हमारे लिए आवश्यक सिस्टम के लिए उपयुक्त संचार प्रोटोकॉल के 2 मॉडल हैं। ये हैं अनुरोध-प्रतिक्रिया और प्रकाशित-सदस्यता लें। पहला मॉडल अधिक व्यापक रूप से जाना जाता है, विशेषकर सर्वर-क्लाइंट आर्किटेक्चर में। क्लाइंट सर्वर से जानकारी का अनुरोध करता है, और सर्वर अनुरोध प्राप्त करता है, इसे संसाधित करता है और एक प्रतिक्रिया संदेश देता है। REST HTTP और CoAP प्रोटोकॉल इस मॉडल पर काम करते हैं।

दूसरा मॉडल डेटा उत्पन्न करने वाले स्रोतों और इस डेटा के प्राप्तकर्ताओं के बीच अतुल्यकालिक, वितरित, ढीला युग्मन प्रदान करने की आवश्यकता से उत्पन्न हुआ।

मॉडल तीन प्रतिभागियों को मानता है: एक प्रकाशक (डेटा स्रोत), एक ब्रोकर (प्रेषक) और एक ग्राहक (रिसीवर)। यहां, ग्राहक के रूप में कार्य करने वाले क्लाइंट को सर्वर से जानकारी का अनुरोध करने की आवश्यकता नहीं है। अनुरोध भेजने के बजाय, यह एक ब्रोकर के माध्यम से सिस्टम में कुछ घटनाओं की सदस्यता लेता है, जो आने वाले सभी संदेशों को फ़िल्टर करने और उन्हें प्रकाशकों और ग्राहकों के बीच रूट करने के लिए जिम्मेदार है। और प्रकाशक, जब किसी निश्चित विषय के संबंध में कोई घटना घटती है, तो उसे ब्रोकर को प्रकाशित करता है, जो ग्राहक को अनुरोधित विषय पर डेटा भेजता है।

मूलतः, यह वास्तुकला घटना-आधारित है। और यह इंटरेक्शन मॉडल IoT, क्लाउड, फ़ॉग में अनुप्रयोगों के लिए दिलचस्प है क्योंकि इसकी स्केलेबिलिटी प्रदान करने और विभिन्न उपकरणों के बीच इंटरकनेक्शन को सरल बनाने, गतिशील कई-से-कई संचार और अतुल्यकालिक संचार का समर्थन करने की क्षमता है। प्रकाशन-सदस्यता मॉडल का उपयोग करने वाले कुछ सबसे प्रसिद्ध मानकीकृत मैसेजिंग प्रोटोकॉल में एमक्यूटीटी, एएमक्यूपी और डीडीएस शामिल हैं।

जाहिर है, प्रकाशित-सदस्यता मॉडल के बहुत सारे फायदे हैं:

• प्रकाशकों और ग्राहकों को एक-दूसरे के अस्तित्व के बारे में जानने की ज़रूरत नहीं है;
• एक ग्राहक कई अलग-अलग प्रकाशनों से जानकारी प्राप्त कर सकता है, और एक प्रकाशक कई अलग-अलग ग्राहकों को डेटा भेज सकता है (कई-से-कई सिद्धांत);
• प्रकाशक और ग्राहक को संवाद करने के लिए एक ही समय में सक्रिय होने की आवश्यकता नहीं है, क्योंकि ब्रोकर (कतारबद्ध प्रणाली के रूप में काम करते हुए) उन ग्राहकों के लिए संदेश संग्रहीत करने में सक्षम होगा जो वर्तमान में नेटवर्क से जुड़े नहीं हैं।

हालाँकि, अनुरोध-प्रतिक्रिया मॉडल की भी अपनी ताकतें हैं। ऐसे मामलों में जहां सर्वर साइड की कई क्लाइंट अनुरोधों को संभालने की क्षमता कोई समस्या नहीं है, सिद्ध, विश्वसनीय समाधानों का उपयोग करना समझ में आता है।

ऐसे प्रोटोकॉल भी हैं जो दोनों मॉडलों का समर्थन करते हैं। उदाहरण के लिए, एक्सएमपीपी और HTTP 2.0, जो "सर्वर पुश" विकल्प का समर्थन करते हैं। IETF ने एक CoAP भी जारी किया है। मैसेजिंग समस्या को हल करने के प्रयास में, कई अन्य समाधान बनाए गए हैं, जैसे वेबसॉकेट प्रोटोकॉल या QUIC (क्विक यूडीपी इंटरनेट कनेक्शन) पर HTTP प्रोटोकॉल का उपयोग।

वेबसॉकेट के मामले में, हालांकि इसका उपयोग सर्वर से वेब क्लाइंट तक वास्तविक समय में डेटा स्थानांतरित करने के लिए किया जाता है और एक साथ द्विदिश संचार के साथ लगातार कनेक्शन प्रदान करता है, यह सीमित कंप्यूटिंग संसाधनों वाले उपकरणों के लिए नहीं है। QUIC भी ध्यान देने योग्य है, क्योंकि नया परिवहन प्रोटोकॉल कई नए अवसर प्रदान करता है। लेकिन चूंकि QUIC अभी तक मानकीकृत नहीं हुआ है, इसलिए IoT समाधानों पर इसके संभावित अनुप्रयोग और प्रभाव की भविष्यवाणी करना जल्दबाजी होगी। इसलिए हम भविष्य को ध्यान में रखते हुए WebSockets और QUIC को ध्यान में रखते हैं, लेकिन हम अभी इसका अधिक विस्तार से अध्ययन नहीं करेंगे।

दुनिया में सबसे प्यारा कौन है: प्रोटोकॉल की तुलना

अब बात करते हैं प्रोटोकॉल की ताकत और कमजोरियों के बारे में। आगे देखते हुए, आइए हम तुरंत एक आरक्षण कर दें कि कोई भी स्पष्ट नेता नहीं है। प्रत्येक प्रोटोकॉल के कुछ फायदे/नुकसान होते हैं।

प्रतिक्रिया समय

संचार प्रोटोकॉल की सबसे महत्वपूर्ण विशेषताओं में से एक, विशेष रूप से इंटरनेट ऑफ थिंग्स के संबंध में, प्रतिक्रिया समय है। लेकिन मौजूदा प्रोटोकॉल के बीच, कोई स्पष्ट विजेता नहीं है जो विभिन्न परिस्थितियों में काम करते समय विलंबता के न्यूनतम स्तर को प्रदर्शित करता हो। लेकिन प्रोटोकॉल क्षमताओं पर शोध और तुलनाओं का एक पूरा समूह मौजूद है।

उदाहरण के लिए, निष्कर्ष IoT के साथ काम करते समय HTTP और MQTT की प्रभावशीलता की तुलना से पता चला कि MQTT के अनुरोधों के लिए प्रतिक्रिया समय HTTP की तुलना में कम है। और जब पढ़ते पढ़ते एमक्यूटीटी और सीओएपी के राउंड ट्रिप टाइम (आरटीटी) से पता चला कि सीओएपी का औसत आरटीटी एमक्यूटीटी की तुलना में 20% कम है।

अन्य प्रयोग MQTT और CoAP प्रोटोकॉल के लिए RTT के साथ दो परिदृश्यों में कार्य किया गया: स्थानीय नेटवर्क और IoT नेटवर्क। यह पता चला कि IoT नेटवर्क में औसत RTT 2-3 गुना अधिक है। QoS0 के साथ MQTT ने CoAP की तुलना में कम परिणाम दिखाया, और QoS1 के साथ MQTT ने एप्लिकेशन और ट्रांसपोर्ट परतों पर ACK के कारण उच्च RTT दिखाया। विभिन्न क्यूओएस स्तरों के लिए, बिना भीड़भाड़ के नेटवर्क विलंबता एमक्यूटीटी के लिए मिलीसेकंड और सीओएपी के लिए सैकड़ों माइक्रोसेकंड थी। हालाँकि, यह याद रखने योग्य है कि कम विश्वसनीय नेटवर्क पर काम करते समय, टीसीपी के शीर्ष पर चलने वाला एमक्यूटीटी पूरी तरह से अलग परिणाम दिखाएगा।

तुलना पेलोड बढ़ाकर एएमक्यूपी और एमक्यूटीटी प्रोटोकॉल के लिए प्रतिक्रिया समय से पता चला कि हल्के लोड के साथ विलंबता स्तर लगभग समान है। लेकिन बड़ी मात्रा में डेटा स्थानांतरित करते समय, एमक्यूटीटी कम प्रतिक्रिया समय प्रदर्शित करता है। एक और में अध्ययन गैस सेंसर, मौसम सेंसर, लोकेशन सेंसर (जीपीएस) और एक मोबाइल नेटवर्क इंटरफेस (जीपीआरएस) से लैस वाहनों के शीर्ष पर तैनात उपकरणों के साथ मशीन-टू-मशीन संचार परिदृश्य में सीओएपी की तुलना HTTP से की गई थी। मोबाइल नेटवर्क पर सीओएपी संदेश प्रसारित करने के लिए आवश्यक समय HTTP संदेशों का उपयोग करने के लिए आवश्यक समय से लगभग तीन गुना कम था।

ऐसे अध्ययन किए गए हैं जिनमें दो नहीं, बल्कि तीन प्रोटोकॉल की तुलना की गई है। उदाहरण के लिए, तुलना एक नेटवर्क एमुलेटर का उपयोग करके चिकित्सा अनुप्रयोग परिदृश्य में IoT प्रोटोकॉल MQTT, DDS और CoAP का प्रदर्शन। विभिन्न प्रकार की खराब नेटवर्क स्थितियों के तहत परीक्षणित टेलीमेट्री विलंबता के मामले में डीडीएस ने एमक्यूटीटी से बेहतर प्रदर्शन किया। यूडीपी-आधारित सीओएपी उन अनुप्रयोगों के लिए अच्छा काम करता है जिनके लिए तेज़ प्रतिक्रिया समय की आवश्यकता होती है, हालांकि, यूडीपी-आधारित होने के कारण, महत्वपूर्ण अप्रत्याशित पैकेट हानि हुई थी।

क्षमता

तुलना बैंडविड्थ दक्षता के संदर्भ में एमक्यूटीटी और सीओएपी प्रति संदेश प्रसारित डेटा की कुल मात्रा की गणना के रूप में किया गया था। छोटे संदेश प्रसारित करते समय CoAP ने MQTT की तुलना में कम थ्रूपुट दिखाया है। लेकिन जब उपयोगी सूचना बाइट्स की संख्या और हस्तांतरित बाइट्स की कुल संख्या के अनुपात के संदर्भ में प्रोटोकॉल की दक्षता की तुलना की गई, तो सीओएपी अधिक प्रभावी निकला।

में विश्लेषण एमक्यूटीटी, डीडीएस (ट्रांसपोर्ट प्रोटोकॉल के रूप में टीसीपी के साथ) और सीओएपी बैंडविड्थ का उपयोग करते हुए, यह पाया गया कि सीओएपी आम तौर पर तुलनात्मक रूप से कम बैंडविड्थ खपत दिखाता है, जो कि एमक्यूटीटी और डीडीएस के विपरीत, नेटवर्क पैकेट हानि में वृद्धि या नेटवर्क विलंबता में वृद्धि के साथ नहीं बढ़ता है, जहां था उल्लिखित परिदृश्यों में बैंडविड्थ उपयोग में वृद्धि। एक अन्य परिदृश्य में एक साथ बड़ी संख्या में डेटा संचारित करने वाले उपकरण शामिल थे, जो IoT वातावरण में विशिष्ट है। परिणामों से पता चला कि अधिक उपयोग के लिए CoAP का उपयोग करना बेहतर है।

हल्के लोड के तहत, CoAP ने सबसे कम बैंडविड्थ का उपयोग किया, इसके बाद MQTT और REST HTTP का उपयोग किया गया। हालाँकि, जब पेलोड का आकार बढ़ा, तो REST HTTP के परिणाम सबसे अच्छे थे।

बिजली की खपत

ऊर्जा खपत का मुद्दा हमेशा बहुत महत्वपूर्ण होता है, और विशेष रूप से IoT प्रणाली में। अगर तुलना जबकि MQTT और HTTP बिजली की खपत करते हैं, HTTP कहीं अधिक बिजली की खपत करता है। और CoAP अधिक है कुशल ऊर्जा एमक्यूटीटी की तुलना में, बिजली प्रबंधन की अनुमति मिलती है। हालाँकि, सरल परिदृश्यों में, एमक्यूटीटी इंटरनेट ऑफ थिंग्स नेटवर्क में सूचनाओं के आदान-प्रदान के लिए अधिक उपयुक्त है, खासकर अगर कोई बिजली प्रतिबंध नहीं है।

अन्य मोबाइल या अस्थिर वायरलेस नेटवर्क परीक्षण पर एएमक्यूपी और एमक्यूटीटी की क्षमताओं की तुलना करने वाले एक प्रयोग में पाया गया कि एएमक्यूपी अधिक सुरक्षा क्षमताएं प्रदान करता है जबकि एमक्यूटीटी अधिक ऊर्जा कुशल है।

सुरक्षा

इंटरनेट ऑफ थिंग्स और फॉग/क्लाउड कंप्यूटिंग के विषय का अध्ययन करते समय सुरक्षा एक और महत्वपूर्ण मुद्दा उठाया जाता है। सुरक्षा तंत्र आमतौर पर HTTP, MQTT, AMQP और XMPP में TLS या CoAP में DTLS पर आधारित है, और दोनों DDS वेरिएंट का समर्थन करता है।

टीएलएस और डीटीएलएस समर्थित सिफर सुइट्स और कुंजियों के आदान-प्रदान के लिए क्लाइंट और सर्वर पक्षों के बीच संचार स्थापित करने की प्रक्रिया से शुरू होते हैं। दोनों पक्ष यह सुनिश्चित करने के लिए सेट पर बातचीत करते हैं कि आगे का संचार एक सुरक्षित चैनल पर हो। दोनों के बीच अंतर छोटे संशोधनों में निहित है जो यूडीपी-आधारित डीटीएलएस को अविश्वसनीय कनेक्शन पर काम करने की अनुमति देता है।

में परीक्षण आक्रमण टीएलएस और डीटीएलएस के कई अलग-अलग कार्यान्वयनों से पता चला कि टीएलएस ने बेहतर काम किया है। त्रुटि सहनशीलता के कारण DTLS पर हमले अधिक सफल रहे।

हालाँकि, इन प्रोटोकॉल के साथ सबसे बड़ी समस्या यह है कि इन्हें मूल रूप से IoT में उपयोग के लिए डिज़ाइन नहीं किया गया था और इनका उद्देश्य कोहरे या बादल में काम करना नहीं था। हाथ मिलाने के माध्यम से, वे प्रत्येक कनेक्शन प्रतिष्ठान के साथ अतिरिक्त ट्रैफ़िक जोड़ते हैं, जिससे कंप्यूटिंग संसाधन ख़त्म हो जाते हैं। सुरक्षा परत के बिना संचार की तुलना में ओवरहेड में टीएलएस के लिए औसतन 6,5% और डीटीएलएस के लिए 11% की वृद्धि हुई है। संसाधन-समृद्ध वातावरण में, जो आम तौर पर स्थित होते हैं बादलों से घिरा स्तर, यह कोई समस्या नहीं होगी, लेकिन IoT और कोहरे के स्तर के बीच संबंध में, यह एक महत्वपूर्ण सीमा बन जाती है।

क्या चुनें? कोई स्पष्ट उत्तर नहीं है. MQTT और HTTP सबसे आशाजनक प्रोटोकॉल प्रतीत होते हैं क्योंकि उन्हें अन्य प्रोटोकॉल की तुलना में तुलनात्मक रूप से अधिक परिपक्व और अधिक स्थिर IoT समाधान माना जाता है।

एकीकृत संचार प्रोटोकॉल पर आधारित समाधान

एकल-प्रोटोकॉल समाधान के अभ्यास के कई नुकसान हैं। उदाहरण के लिए, एक प्रोटोकॉल जो प्रतिबंधित वातावरण के लिए उपयुक्त है, वह उस डोमेन में काम नहीं कर सकता है जिसमें सख्त सुरक्षा आवश्यकताएं हैं। इसे ध्यान में रखते हुए, हमें MQTT और REST HTTP को छोड़कर, IoT में फॉग-टू-क्लाउड पारिस्थितिकी तंत्र में लगभग सभी संभावित एकल-प्रोटोकॉल समाधानों को त्यागना होगा।

एकल-प्रोटोकॉल समाधान के रूप में REST HTTP

इसका एक अच्छा उदाहरण है कि REST HTTP अनुरोध और प्रतिक्रियाएँ IoT-टू-फॉग स्पेस में कैसे इंटरैक्ट करती हैं: स्मार्ट फार्म. जानवर पहनने योग्य सेंसर (आईओटी क्लाइंट, सी) से लैस हैं और स्मार्ट फार्मिंग सिस्टम (फॉग सर्वर, एस) द्वारा क्लाउड कंप्यूटिंग के माध्यम से नियंत्रित होते हैं।

POST विधि का हेडर संशोधित करने के लिए संसाधन (/फार्म/जानवरों) के साथ-साथ HTTP संस्करण और सामग्री प्रकार को निर्दिष्ट करता है, जो इस मामले में एक JSON ऑब्जेक्ट है जो पशु फार्म का प्रतिनिधित्व करता है जिसे सिस्टम को प्रबंधित करना है (डुलसीनिया/गाय) . सर्वर से प्रतिक्रिया इंगित करती है कि HTTPS स्थिति कोड 201 (संसाधन निर्मित) भेजकर अनुरोध सफल था। GET विधि को URI में केवल अनुरोधित संसाधन निर्दिष्ट करना होगा (उदाहरण के लिए, /farm/animals/1), जो सर्वर से उस आईडी के साथ जानवर का JSON प्रतिनिधित्व लौटाता है।

PUT विधि का उपयोग तब किया जाता है जब कुछ विशिष्ट संसाधन रिकॉर्ड को अद्यतन करने की आवश्यकता होती है। इस मामले में, संसाधन बदले जाने वाले पैरामीटर और वर्तमान मान के लिए यूआरआई निर्दिष्ट करता है (उदाहरण के लिए, यह दर्शाता है कि गाय वर्तमान में चल रही है, /फार्म/जानवर/1? राज्य=चल रही है)। अंत में, DELETE विधि का उपयोग GET विधि के समान ही किया जाता है, लेकिन ऑपरेशन के परिणामस्वरूप संसाधन को हटा दिया जाता है।

एकल-प्रोटोकॉल समाधान के रूप में MQTT

आइए वही स्मार्ट फ़ार्म लें, लेकिन REST HTTP के बजाय हम MQTT प्रोटोकॉल का उपयोग करते हैं। मॉस्किटो लाइब्रेरी स्थापित एक स्थानीय सर्वर ब्रोकर के रूप में कार्य करता है। इस उदाहरण में, एक साधारण कंप्यूटर (जिसे फार्म सर्वर कहा जाता है) रास्पबेरी पाई एक एमक्यूटीटी क्लाइंट के रूप में कार्य करता है, जिसे पाहो एमक्यूटीटी लाइब्रेरी की स्थापना के माध्यम से कार्यान्वित किया जाता है, जो मॉस्किटो ब्रोकर के साथ पूरी तरह से संगत है।

यह क्लाइंट एक IoT एब्स्ट्रैक्शन लेयर से मेल खाता है जो सेंसिंग और कंप्यूटिंग क्षमताओं वाले डिवाइस का प्रतिनिधित्व करता है। दूसरी ओर, मध्यस्थ, अमूर्तता के उच्च स्तर से मेल खाता है, जो अधिक प्रसंस्करण और भंडारण क्षमता की विशेषता वाले फॉग कंप्यूटिंग नोड का प्रतिनिधित्व करता है।

प्रस्तावित स्मार्ट फार्म परिदृश्य में, रास्पबेरी पाई एक्सेलेरोमीटर, जीपीएस और तापमान सेंसर से जुड़ता है और इन सेंसर से डेटा को फॉग नोड पर प्रकाशित करता है। जैसा कि आप शायद जानते हैं, एमक्यूटीटी विषयों को एक पदानुक्रम के रूप में मानता है। एक एकल MQTT प्रकाशक विषयों के एक विशिष्ट समूह के लिए संदेश प्रकाशित कर सकता है। हमारे मामले में उनमें से तीन हैं। एक सेंसर के लिए जो पशु खलिहान में तापमान मापता है, ग्राहक एक थीम (पशु फार्म/शेड/तापमान) का चयन करता है। एक्सेलेरोमीटर के माध्यम से जीपीएस स्थान और पशु आंदोलन को मापने वाले सेंसर के लिए, क्लाइंट (एनिमलफार्म/एनिमल/जीपीएस) और (एनिमलफार्म/एनिमल/मूवमेंट) पर अपडेट प्रकाशित करेगा।

यह जानकारी ब्रोकर को दे दी जाएगी, जो बाद में किसी अन्य इच्छुक ग्राहक के आने की स्थिति में इसे अस्थायी रूप से स्थानीय डेटाबेस में संग्रहीत कर सकता है।

स्थानीय सर्वर के अलावा, जो कोहरे में एमक्यूटीटी ब्रोकर के रूप में कार्य करता है और जिसमें रास्पबेरी पीआईएस, एमक्यूटीटी क्लाइंट के रूप में कार्य करता है, सेंसर डेटा भेजता है, क्लाउड स्तर पर एक और एमक्यूटीटी ब्रोकर हो सकता है। इस मामले में, स्थानीय ब्रोकर को प्रेषित जानकारी अस्थायी रूप से स्थानीय डेटाबेस में संग्रहीत की जा सकती है और/या क्लाउड पर भेजी जा सकती है। इस स्थिति में फ़ॉग एमक्यूटीटी ब्रोकर का उपयोग सभी डेटा को क्लाउड एमक्यूटीटी ब्रोकर के साथ जोड़ने के लिए किया जाता है। इस आर्किटेक्चर के साथ, एक मोबाइल एप्लिकेशन उपयोगकर्ता दोनों ब्रोकरों की सदस्यता ले सकता है।

यदि किसी ब्रोकर (उदाहरण के लिए, क्लाउड) से कनेक्शन विफल हो जाता है, तो अंतिम उपयोगकर्ता को दूसरे (फॉग) से जानकारी प्राप्त होगी। यह संयुक्त कोहरे और क्लाउड कंप्यूटिंग सिस्टम की एक विशिष्ट विशेषता है। डिफ़ॉल्ट रूप से, मोबाइल ऐप को पहले फ़ॉग एमक्यूटीटी ब्रोकर से कनेक्ट करने के लिए कॉन्फ़िगर किया जा सकता है, और यदि वह विफल रहता है, तो क्लाउड एमक्यूटीटी ब्रोकर से कनेक्ट करने के लिए। यह समाधान IoT-F2C प्रणालियों में से कई में से एक है।

बहु-प्रोटोकॉल समाधान

एकल प्रोटोकॉल समाधान अपने आसान कार्यान्वयन के कारण लोकप्रिय हैं। लेकिन यह स्पष्ट है कि IoT-F2C सिस्टम में विभिन्न प्रोटोकॉल को संयोजित करना समझ में आता है। विचार यह है कि विभिन्न प्रोटोकॉल विभिन्न स्तरों पर काम कर सकते हैं। उदाहरण के लिए, तीन अमूर्तताएं लें: IoT, कोहरे और क्लाउड कंप्यूटिंग की परतें। IoT स्तर पर उपकरणों को आम तौर पर सीमित माना जाता है। इस अवलोकन के लिए, आइए IoT स्तरों को सबसे अधिक बाधित, क्लाउड को सबसे कम बाधित और फॉग कंप्यूटिंग को "कहीं बीच में" मानें। तब यह पता चलता है कि IoT और फ़ॉग एब्स्ट्रैक्शन के बीच, वर्तमान प्रोटोकॉल समाधानों में MQTT, CoAP और XMPP शामिल हैं। दूसरी ओर, कोहरे और बादल के बीच, AMQP REST HTTP के साथ उपयोग किए जाने वाले मुख्य प्रोटोकॉल में से एक है, जो अपने लचीलेपन के कारण IoT और कोहरे परतों के बीच भी उपयोग किया जाता है।

यहां मुख्य समस्या प्रोटोकॉल की अंतरसंचालनीयता और संदेशों को एक प्रोटोकॉल से दूसरे प्रोटोकॉल में स्थानांतरित करने में आसानी है। आदर्श रूप से, भविष्य में, क्लाउड और फ़ॉग संसाधनों के साथ इंटरनेट ऑफ़ थिंग्स सिस्टम की वास्तुकला उपयोग किए गए संचार प्रोटोकॉल से स्वतंत्र होगी और विभिन्न प्रोटोकॉल के बीच अच्छी अंतरसंचालनीयता सुनिश्चित करेगी।

चूंकि वर्तमान में ऐसा नहीं है, इसलिए उन प्रोटोकॉल को संयोजित करना समझ में आता है जिनमें महत्वपूर्ण अंतर नहीं हैं। इस प्रयोजन के लिए, एक संभावित समाधान दो प्रोटोकॉल के संयोजन पर आधारित है जो समान वास्तुशिल्प शैली, REST HTTP और CoAP का पालन करते हैं। एक अन्य प्रस्तावित समाधान दो प्रोटोकॉल के संयोजन पर आधारित है जो प्रकाशन-सदस्यता संचार, एमक्यूटीटी और एएमक्यूपी की पेशकश करते हैं। समान अवधारणाओं का उपयोग करना (एमक्यूटीटी और एएमक्यूपी दोनों दलालों का उपयोग करते हैं, सीओएपी और HTTP आरईएसटी का उपयोग करते हैं) इन संयोजनों को लागू करना आसान बनाता है और कम एकीकरण प्रयास की आवश्यकता होती है।

चित्र (ए) दो अनुरोध-प्रतिक्रिया आधारित मॉडल, HTTP और CoAP और IoT-F2C समाधान में उनके संभावित प्लेसमेंट को दर्शाता है। चूंकि HTTP आधुनिक नेटवर्क पर सबसे प्रसिद्ध और अपनाए गए प्रोटोकॉल में से एक है, इसलिए यह संभावना नहीं है कि इसे अन्य मैसेजिंग प्रोटोकॉल द्वारा पूरी तरह से बदल दिया जाएगा। क्लाउड और कोहरे के बीच स्थित शक्तिशाली उपकरणों का प्रतिनिधित्व करने वाले नोड्स में, REST HTTP एक स्मार्ट समाधान है।

दूसरी ओर, सीमित कंप्यूटिंग संसाधनों वाले उपकरणों के लिए जो फॉग और IoT परतों के बीच संचार करते हैं, CoAP का उपयोग करना अधिक कुशल है। CoAP का एक बड़ा लाभ वास्तव में HTTP के साथ इसकी अनुकूलता है, क्योंकि दोनों प्रोटोकॉल REST सिद्धांतों पर आधारित हैं।

चित्र (बी) एक ही परिदृश्य में दो प्रकाशन-सदस्यता संचार मॉडल दिखाता है, जिसमें एमक्यूटीटी और एएमक्यूपी शामिल हैं। यद्यपि दोनों प्रोटोकॉल का उपयोग काल्पनिक रूप से प्रत्येक अमूर्त परत पर नोड्स के बीच संचार के लिए किया जा सकता है, उनकी स्थिति प्रदर्शन के आधार पर निर्धारित की जानी चाहिए। MQTT को सीमित कंप्यूटिंग संसाधनों वाले उपकरणों के लिए एक हल्के प्रोटोकॉल के रूप में डिज़ाइन किया गया था, इसलिए इसका उपयोग IoT-Fog संचार के लिए किया जा सकता है। एएमक्यूपी अधिक शक्तिशाली उपकरणों के लिए अधिक उपयुक्त है, जो इसे आदर्श रूप से कोहरे और बादल नोड्स के बीच स्थित करेगा। MQTT के बजाय, XMPP प्रोटोकॉल का उपयोग IoT में किया जा सकता है क्योंकि इसे हल्का माना जाता है। लेकिन ऐसे परिदृश्यों में इसका व्यापक रूप से उपयोग नहीं किया जाता है।

निष्कर्ष

यह संभावना नहीं है कि चर्चा किए गए प्रोटोकॉल में से एक सिस्टम में सभी संचार को कवर करने के लिए पर्याप्त होगा, सीमित कंप्यूटिंग संसाधनों वाले उपकरणों से लेकर क्लाउड सर्वर तक। अध्ययन में पाया गया कि डेवलपर्स द्वारा सबसे अधिक उपयोग किए जाने वाले दो सबसे आशाजनक विकल्प MQTT और RESTful HTTP हैं। ये दो प्रोटोकॉल न केवल सबसे परिपक्व और स्थिर हैं, बल्कि इसमें कई अच्छी तरह से प्रलेखित और सफल कार्यान्वयन और ऑनलाइन संसाधन भी शामिल हैं।

अपनी स्थिरता और सरल कॉन्फ़िगरेशन के कारण, MQTT एक प्रोटोकॉल है जिसने सीमित उपकरणों के साथ IoT स्तर पर उपयोग किए जाने पर समय के साथ अपना बेहतर प्रदर्शन साबित किया है। सिस्टम के उन हिस्सों में जहां सीमित संचार और बैटरी खपत कोई समस्या नहीं है, जैसे कि कुछ फ़ॉग डोमेन और अधिकांश क्लाउड कंप्यूटिंग, RESTful HTTP एक आसान विकल्प है। CoAP को भी ध्यान में रखा जाना चाहिए क्योंकि यह IoT मैसेजिंग मानक के रूप में भी तेजी से विकसित हो रहा है और संभावना है कि यह निकट भविष्य में MQTT और HTTP के समान स्थिरता और परिपक्वता के स्तर तक पहुंच जाएगा। लेकिन मानक वर्तमान में विकसित हो रहा है, जो अल्पकालिक अनुकूलता समस्याओं के साथ आता है।

आप ब्लॉग पर और क्या पढ़ सकते हैं? Cloud4Y

→ कंप्यूटर आपको स्वादिष्ट बना देगा
→ एआई अफ़्रीका में जानवरों का अध्ययन करने में मदद करता है
→ गर्मी लगभग खत्म हो चुकी है। लगभग कोई खुला डेटा नहीं बचा है
→ क्लाउड बैकअप पर बचत करने के 4 तरीके
→ एक एकीकृत संघीय सूचना संसाधन पर जिसमें जनसंख्या के बारे में जानकारी शामिल है

हमारी सदस्यता लें Telegram-चैनल, ताकि अगला लेख छूट न जाए! हम सप्ताह में दो बार से अधिक नहीं लिखते हैं और केवल व्यवसाय पर लिखते हैं।

स्रोत: www.habr.com