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

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

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

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

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

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

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

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

IoT कोहरे से बादल वास्तुकला (F2C)

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

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

यह अमूर्तता कैसी दिख सकती है? यहां एक विशिष्ट IoT- फॉग-क्लाउड पारिस्थितिकी तंत्र है। कम विलंबता वाले कार्यों को हल करने के लिए 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 प्रोटोकॉल या HTTP प्रोटोकॉल का उपयोग QUIC (क्विक यूडीपी इंटरनेट कनेक्शन) के माध्यम से।

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

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

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

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

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

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

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

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

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

क्षमता

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

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

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

बिजली की खपत

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

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

सुरक्षा

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

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

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

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

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

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

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

एक प्रोटोकॉल प्रोटोकॉल के रूप में REST HTTP

IoT-to-Fog REST HTTP अनुरोध और प्रतिक्रिया सहभागिता: स्मार्ट फ़ार्म का एक अच्छा उदाहरण है। पशु पहनने योग्य सेंसर (IoT क्लाइंट, C) से लैस हैं और स्मार्ट खेती प्रणाली (फॉग सर्वर, एस) द्वारा क्लाउड कंप्यूटिंग के माध्यम से नियंत्रित किया जाता है।

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

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

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



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

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

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

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

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

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

मल्टीप्रोटोकॉल समाधान

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

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



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



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

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

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

निष्कर्ष

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

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

Cloud4Y ब्लॉग पर पढ़ने के लिए और क्या उपयोगी है

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

हमारे टेलीग्राम चैनल को सब्सक्राइब करें ताकि कोई और आर्टिकल याद न हो! हम सप्ताह में दो बार से अधिक और केवल व्यापार पर नहीं लिखते हैं।