IoT, धुके आणि ढग: चला तंत्रज्ञानाबद्दल बोलूया?

सॉफ्टवेअर आणि हार्डवेअरच्या क्षेत्रात तंत्रज्ञानाचा विकास, नवीन संप्रेषण प्रोटोकॉलचा उदय यामुळे इंटरनेट ऑफ थिंग्ज (IoT) चा विस्तार झाला आहे. उपकरणांची संख्या दिवसेंदिवस वाढत आहे आणि ते मोठ्या प्रमाणात डेटा तयार करत आहेत. म्हणून, या डेटावर प्रक्रिया, संचयित आणि प्रसारित करण्यास सक्षम असलेल्या सोयीस्कर सिस्टम आर्किटेक्चरची आवश्यकता आहे.

आता या उद्देशांसाठी क्लाउड सेवा वापरल्या जातात. तथापि, वाढत्या प्रमाणात लोकप्रिय फॉग कॉम्प्युटिंग पॅराडाइम (फॉग) हे IoT पायाभूत सुविधांना स्केलिंग आणि ऑप्टिमाइझ करून क्लाउड सोल्यूशन्सला पूरक ठरू शकते.

ढग बहुतेक IoT विनंत्या कव्हर करण्यास सक्षम आहेत. उदाहरणार्थ, सेवांचे निरीक्षण प्रदान करण्यासाठी, उपकरणांद्वारे व्युत्पन्न केलेल्या डेटाची जलद प्रक्रिया तसेच त्यांचे व्हिज्युअलायझेशन. रिअल-टाइम समस्या सोडवताना फॉग कॉम्प्युटिंग अधिक प्रभावी आहे. ते विनंत्यांना जलद प्रतिसाद देतात आणि डेटा प्रोसेसिंगमध्ये कमीत कमी लेटन्सी देतात. म्हणजेच, धुके "ढगांना" पूरक आहे आणि त्याची क्षमता वाढवते.

तथापि, मुख्य प्रश्न वेगळा आहे: हे सर्व IoT च्या संदर्भात कसे संवाद साधले पाहिजे? एकत्रित IoT-Fog-Cloud प्रणालीमध्ये काम करताना कोणते संप्रेषण प्रोटोकॉल सर्वात प्रभावी असतील?

एचटीटीपीचे स्पष्ट वर्चस्व असूनही, आयओटी, फॉग आणि क्लाउड सिस्टममध्ये मोठ्या प्रमाणात इतर उपाय वापरले जातात. याचे कारण म्हणजे IoT ने वापरकर्त्यांच्या सुरक्षा, सुसंगतता आणि इतर आवश्यकतांसह विविध डिव्हाइस सेन्सरची कार्यक्षमता एकत्र करणे आवश्यक आहे.

परंतु संदर्भ आर्किटेक्चर आणि संप्रेषण मानकांबद्दल कोणतीही कल्पना नाही. म्हणून, विशिष्ट IoT कार्यांसाठी नवीन प्रोटोकॉल तयार करणे किंवा विद्यमान एक सुधारित करणे हे IT समुदायासमोरील सर्वात महत्वाचे कार्य आहे.

सध्या कोणते प्रोटोकॉल वापरात आहेत आणि ते काय देऊ शकतात? चला ते बाहेर काढूया. परंतु प्रथम, ज्या परिसंस्थेमध्ये ढग, धुके आणि इंटरनेट ऑफ थिंग्ज परस्परसंवाद करतात त्या परिसंस्थेच्या तत्त्वांची चर्चा करूया.

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

IoT, क्लाउड आणि फॉगच्या स्मार्ट आणि समन्वित व्यवस्थापनाशी संबंधित फायदे आणि फायद्यांचा शोध घेण्यासाठी किती प्रयत्न केले जात आहेत हे तुमच्या लक्षात आले असेल. नसल्यास, येथे तीन मानकीकरण उपक्रम आहेत: ओपनफॉग कन्सोर्टियम, एज कॉम्प्युटिंग कंसोर्टियम и mF2C H2020 EU प्रकल्प.

जर पूर्वी फक्त 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 देखील जारी केला आहे. मेसेजिंग समस्येचे निराकरण करण्याच्या प्रयत्नात, वेबसॉकेट प्रोटोकॉल किंवा QUIC (क्विक UDP इंटरनेट कनेक्शन) वर HTTP प्रोटोकॉलचा वापर यासारखे इतर अनेक उपाय तयार केले गेले आहेत.

WebSockets च्या बाबतीत, जरी त्याचा वापर सर्व्हरवरून वेब क्लायंटमध्ये रिअल टाइममध्ये डेटा हस्तांतरित करण्यासाठी केला जातो आणि एकाचवेळी द्विदिशात्मक संप्रेषणासह सतत कनेक्शन प्रदान करतो, तरीही ते मर्यादित संगणकीय संसाधनांसह डिव्हाइसेससाठी हेतू नाही. QUIC देखील लक्ष देण्यास पात्र आहे, कारण नवीन वाहतूक प्रोटोकॉल अनेक नवीन संधी प्रदान करतो. परंतु QUIC अद्याप प्रमाणित नसल्यामुळे, त्याचा संभाव्य वापर आणि IoT सोल्यूशन्सवरील परिणामाचा अंदाज लावणे अकाली आहे. म्हणून आम्ही वेबसॉकेट्स आणि QUIC भविष्याकडे लक्ष देऊन ठेवतो, परंतु आत्ता आम्ही त्याचा अधिक तपशीलवार अभ्यास करणार नाही.

जगातील सर्वात गोंडस कोण आहे: प्रोटोकॉलची तुलना करणे

आता प्रोटोकॉलची ताकद आणि कमकुवतपणाबद्दल बोलूया. पुढे पाहता, आपण ताबडतोब आरक्षण करूया की कोणीही स्पष्ट नेता नाही. प्रत्येक प्रोटोकॉलचे काही फायदे/तोटे असतात.

प्रतिसाद वेळ

संप्रेषण प्रोटोकॉलचे सर्वात महत्त्वाचे वैशिष्ट्य, विशेषत: इंटरनेट ऑफ थिंग्जच्या संबंधात, प्रतिसाद वेळ आहे. परंतु विद्यमान प्रोटोकॉलमध्ये, भिन्न परिस्थितींमध्ये काम करताना विलंबाची किमान पातळी दर्शविणारा कोणताही स्पष्ट विजेता नाही. परंतु प्रोटोकॉल क्षमतांच्या संशोधन आणि तुलनांचा संपूर्ण समूह आहे.

उदाहरणार्थ, परिणाम IoT सोबत काम करताना HTTP आणि MQTT च्या परिणामकारकतेच्या तुलनेत MQTT च्या विनंत्यांना प्रतिसाद वेळ HTTP पेक्षा कमी आहे. आणि कधी अभ्यास करत आहे MQTT आणि CoAP च्या राउंड ट्रिप टाइम (RTT) वरून असे दिसून आले की CoAP चा सरासरी RTT MQTT पेक्षा 20% कमी आहे.

इतर प्रयोग MQTT आणि CoAP प्रोटोकॉलसाठी RTT सह दोन परिस्थितींमध्ये पार पाडले गेले: स्थानिक नेटवर्क आणि IoT नेटवर्क. असे दिसून आले की आयओटी नेटवर्कमध्ये सरासरी आरटीटी 2-3 पट जास्त आहे. QoS0 सह MQTT ने CoAP च्या तुलनेत कमी परिणाम दर्शविला आणि QoS1 सह MQTT ने अनुप्रयोग आणि वाहतूक स्तरांवर ACKs मुळे उच्च RTT दर्शविला. वेगवेगळ्या QoS स्तरांसाठी, गर्दीशिवाय नेटवर्क लेटन्सी MQTT साठी मिलीसेकंद आणि CoAP साठी शेकडो मायक्रोसेकंद होती. तथापि, हे लक्षात ठेवण्यासारखे आहे की कमी विश्वासार्ह नेटवर्कवर काम करताना, TCP च्या वर चालणारे MQTT पूर्णपणे भिन्न परिणाम दर्शवेल.

तुलना पेलोड वाढवून एएमक्यूपी आणि एमक्यूटीटी प्रोटोकॉलसाठी प्रतिसाद वेळ दर्शवितो की हलक्या लोडसह विलंब पातळी जवळजवळ समान आहे. परंतु मोठ्या प्रमाणात डेटा हस्तांतरित करताना, MQTT कमी प्रतिसाद वेळा दाखवते. आणखी एका मध्ये संशोधन गॅस सेन्सर्स, वेदर सेन्सर्स, लोकेशन सेन्सर्स (GPS) आणि मोबाईल नेटवर्क इंटरफेस (GPRS) ने सुसज्ज असलेल्या वाहनांच्या शीर्षस्थानी तैनात केलेल्या उपकरणांसह मशीन-टू-मशीन संप्रेषण परिस्थितीमध्ये CoAP ची तुलना HTTP शी केली गेली. मोबाइल नेटवर्कवर 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 क्लायंट, C) ने सुसज्ज आहेत आणि स्मार्ट फार्मिंग सिस्टम (फॉग सर्व्हर, एस) द्वारे क्लाउड कंप्युटिंगद्वारे नियंत्रित केले जातात.

POST पद्धतीचे शीर्षलेख सुधारित करण्यासाठी संसाधन (/फार्म/प्राणी) तसेच HTTP आवृत्ती आणि सामग्री प्रकार निर्दिष्ट करते, जे या प्रकरणात जेएसओएन ऑब्जेक्ट आहे जे प्राणी फार्मचे प्रतिनिधित्व करते जी प्रणाली व्यवस्थापित करणार आहे (डुलसीनिया/गाय) . सर्व्हरचा प्रतिसाद सूचित करतो की HTTPS स्थिती कोड 201 (संसाधन तयार) पाठवून विनंती यशस्वी झाली. GET पद्धतीने URI मध्ये फक्त विनंती केलेले संसाधन निर्दिष्ट करणे आवश्यक आहे (उदाहरणार्थ, /farm/animals/1), जे सर्व्हरवरून त्या आयडीसह प्राण्याचे JSON प्रतिनिधित्व परत करते.

जेव्हा काही विशिष्ट संसाधन रेकॉर्ड अद्यतनित करणे आवश्यक असते तेव्हा PUT पद्धत वापरली जाते. या प्रकरणात, संसाधन बदलण्यासाठी पॅरामीटर आणि वर्तमान मूल्यासाठी URI निर्दिष्ट करते (उदाहरणार्थ, गाय सध्या चालत आहे, /farm/animals/1? state=walking). शेवटी, DELETE पद्धत GET पद्धती प्रमाणेच वापरली जाते, परंतु ऑपरेशनच्या परिणामी संसाधन हटवते.

MQTT सिंगल-प्रोटोकॉल सोल्यूशन म्हणून

चला तेच स्मार्ट फार्म घेऊ, परंतु REST HTTP ऐवजी आपण MQTT प्रोटोकॉल वापरतो. Mosquitto लायब्ररी स्थापित असलेला स्थानिक सर्व्हर दलाल म्हणून काम करतो. या उदाहरणात, एक साधा संगणक (फार्म सर्व्हर म्हणून संदर्भित) रास्पबेरी पाई MQTT क्लायंट म्हणून काम करते, Paho MQTT लायब्ररीच्या स्थापनेद्वारे लागू केले जाते, जे Mosquitto ब्रोकरशी पूर्णपणे सुसंगत आहे.

हा क्लायंट एका IoT अ‍ॅब्स्ट्रॅक्शन लेयरशी संबंधित आहे जो सेन्सिंग आणि संगणन क्षमता असलेल्या डिव्हाइसचे प्रतिनिधित्व करतो. मध्यस्थ, दुसरीकडे, अमूर्ततेच्या उच्च पातळीशी संबंधित आहे, जो अधिक प्रक्रिया आणि संचयन क्षमतेद्वारे वैशिष्ट्यीकृत फॉग कंप्युटिंग नोडचे प्रतिनिधित्व करतो.

प्रस्तावित स्मार्ट फार्म परिस्थितीमध्ये, रास्पबेरी पाई एक्सेलेरोमीटर, GPS आणि तापमान सेन्सर्सना जोडते आणि या सेन्सर्समधील डेटा फॉग नोडवर प्रकाशित करते. तुम्हाला माहीत असेलच की, MQTT विषयांना पदानुक्रम म्हणून हाताळते. एकल MQTT प्रकाशक विशिष्ट विषयांवर संदेश प्रकाशित करू शकतो. आमच्या बाबतीत त्यापैकी तीन आहेत. प्राण्यांच्या कोठारातील तापमान मोजणार्‍या सेन्सरसाठी, क्लायंट एक थीम निवडतो (अ‍ॅनिमलफार्म/शेड/तापमान). एक्सीलरोमीटरद्वारे जीपीएस स्थान आणि प्राण्यांची हालचाल मोजणाऱ्या सेन्सर्ससाठी, क्लायंट (अ‍ॅनिमलफार्म/प्राणी/जीपीएस) आणि (अ‍ॅनिमलफार्म/प्राणी/हालचाल) अद्यतने प्रकाशित करेल.

ही माहिती ब्रोकरला दिली जाईल, जो नंतर दुसरा इच्छुक सदस्य आल्यास ती स्थानिक डेटाबेसमध्ये तात्पुरती साठवू शकतो.

धुक्यात MQTT ब्रोकर म्हणून काम करणार्‍या आणि MQTT क्लायंट म्हणून काम करणारा Raspberry Pis, सेन्सर डेटा पाठवणार्‍या स्थानिक सर्व्हरच्या व्यतिरिक्त, क्लाउड स्तरावर आणखी एक 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 प्रमाणेच स्थिरता आणि परिपक्वतेच्या पातळीवर पोहोचण्याची शक्यता आहे. परंतु मानक सध्या विकसित होत आहे, जे अल्पकालीन अनुकूलता समस्यांसह येते.

आपण ब्लॉगवर आणखी काय वाचू शकता? Cloud4Y

→ संगणक तुम्हाला स्वादिष्ट बनवेल
→ AI आफ्रिकेतील प्राण्यांचा अभ्यास करण्यास मदत करते
→ उन्हाळा जवळपास संपत आला आहे. जवळजवळ कोणताही अनलीक डेटा शिल्लक नाही
→ क्लाउड बॅकअपवर बचत करण्याचे 4 मार्ग
→ लोकसंख्येबद्दल माहिती असलेल्या युनिफाइड फेडरल माहिती संसाधनावर

आमच्या सदस्यता घ्या तार-चॅनेल, पुढील लेख चुकवू नये म्हणून! आम्ही आठवड्यातून दोनदा आणि फक्त व्यवसायावर लिहित नाही.

स्त्रोत: www.habr.com