IoT, कुहिरो र बादल: प्रविधिको बारेमा कुरा गरौं?

सफ्टवेयर र हार्डवेयरको क्षेत्रमा टेक्नोलोजीहरूको विकास, नयाँ सञ्चार प्रोटोकलहरूको उदयले इन्टरनेट अफ थिंग्स (IoT) को विस्तारको नेतृत्व गरेको छ। यन्त्रहरूको संख्या दिन प्रतिदिन बढ्दै छ र तिनीहरूले ठूलो मात्रामा डाटा उत्पन्न गरिरहेका छन्। तसर्थ, यस डाटालाई प्रशोधन, भण्डारण र प्रसारण गर्न सक्षम सुविधाजनक प्रणाली वास्तुकलाको आवश्यकता छ।

अब क्लाउड सेवाहरू यी उद्देश्यका लागि प्रयोग गरिन्छ। जे होस्, बढ्दो लोकप्रिय फोग कम्प्युटिङ प्रतिमान (फोग) ले क्लाउड समाधानहरूलाई स्केलिंग र IoT पूर्वाधारलाई अनुकूलन गरेर पूरक बनाउन सक्छ।

क्लाउडहरू अधिकांश IoT अनुरोधहरू कभर गर्न सक्षम छन्। उदाहरण को लागी, सेवाहरु को अनुगमन प्रदान गर्न को लागी, यन्त्रहरु द्वारा उत्पन्न डाटा को कुनै पनि मात्रा को छिटो प्रशोधन, साथै तिनीहरुको भिजुअलाइजेशन। वास्तविक-समय समस्याहरू समाधान गर्दा फग कम्प्युटिङ अधिक प्रभावकारी हुन्छ। तिनीहरूले अनुरोधहरूलाई छिटो प्रतिक्रिया र डाटा प्रोसेसिङमा न्यूनतम विलम्बता प्रदान गर्छन्। त्यो हो, कुहिरोले "बादल" लाई पूरक बनाउँछ र यसको क्षमताहरू विस्तार गर्दछ।

यद्यपि, मुख्य प्रश्न फरक छ: कसरी यी सबैले IoT को सन्दर्भमा अन्तरक्रिया गर्नुपर्छ? संयुक्त IoT-Fog-Cloud प्रणालीमा काम गर्दा कुन सञ्चार प्रोटोकलहरू सबैभन्दा प्रभावकारी हुनेछन्?

HTTP को स्पष्ट प्रभुत्वको बावजुद, त्यहाँ IoT, फग र क्लाउड प्रणालीहरूमा प्रयोग गरिएका अन्य समाधानहरूको ठूलो संख्या छन्। यो किनभने IoT ले सुरक्षा, अनुकूलता र प्रयोगकर्ताहरूको अन्य आवश्यकताहरूसँग विभिन्न उपकरण सेन्सरहरूको कार्यक्षमता संयोजन गर्नुपर्छ।

तर सन्दर्भ वास्तुकला र सञ्चार मानकको बारेमा कुनै एकल विचार मात्र छैन। त्यसकारण, नयाँ प्रोटोकल सिर्जना गर्नु वा विशिष्ट IoT कार्यहरूको लागि अवस्थित एक परिमार्जन गर्नु IT समुदायको सामना गर्ने सबैभन्दा महत्त्वपूर्ण कार्यहरू मध्ये एक हो।

कुन प्रोटोकलहरू हाल प्रयोगमा छन् र तिनीहरूले के प्रस्ताव गर्न सक्छन्? यसलाई बाहिर निकालौं। तर पहिले, बादल, कुहिरो र चीजहरूको इन्टरनेट अन्तरक्रिया गर्ने इकोसिस्टमका सिद्धान्तहरू छलफल गरौं।

IoT फोग-टू-क्लाउड (F2C) वास्तुकला

तपाईंले IoT, क्लाउड र फगको स्मार्ट र समन्वयित व्यवस्थापनसँग सम्बन्धित फाइदाहरू र फाइदाहरू अन्वेषण गर्न कत्तिको प्रयास भइरहेको छ भनेर सायद याद गर्नुभएको छ। यदि होइन भने, यहाँ तीन मानकीकरण पहलहरू छन्: ओपनफोग कन्सोर्टियम, एज कम्प्युटिङ कन्सोर्टियम и mF2C H2020 EU परियोजना.

यदि पहिले मात्र 2 स्तरहरू विचार गरिन्थ्यो, क्लाउडहरू र अन्तिम उपकरणहरू, त्यसपछि प्रस्तावित वास्तुकलाले नयाँ स्तर - फग कम्प्युटिङ परिचय गर्दछ। यस अवस्थामा, कुहिरो स्तरलाई धेरै उप-स्तरहरूमा विभाजन गर्न सकिन्छ, स्रोतहरूको विशिष्टता वा यी सब-लेभलहरूमा विभिन्न यन्त्रहरूको प्रयोग निर्धारण गर्ने नीतिहरूको सेटको आधारमा।

यो अमूर्तता कस्तो देखिन सक्छ? यहाँ एक विशिष्ट IoT-Fog-Cloud पारिस्थितिकी तंत्र छ। IoT यन्त्रहरूले छिटो सर्भरहरू र कम विलम्बता चाहिने समस्याहरू समाधान गर्न कम्प्युटिङ उपकरणहरूमा डेटा पठाउँछन्। एउटै प्रणालीमा, क्लाउडहरू समस्याहरू समाधान गर्न जिम्मेवार छन् जसलाई ठूलो मात्रामा कम्प्युटिङ स्रोतहरू वा डाटा भण्डारण ठाउँ चाहिन्छ।

स्मार्टफोन, स्मार्ट घडी र अन्य ग्याजेटहरू पनि IoT को हिस्सा हुन सक्छन्। तर त्यस्ता यन्त्रहरू, नियमको रूपमा, ठूला विकासकर्ताहरूबाट स्वामित्व संचार प्रोटोकलहरू प्रयोग गर्छन्। उत्पन्न IoT डाटा REST HTTP प्रोटोकल मार्फत कुहिरो तहमा स्थानान्तरण गरिन्छ, जसले RESTful सेवाहरू सिर्जना गर्दा लचिलोपन र अन्तरसञ्चालन प्रदान गर्दछ। स्थानीय कम्प्युटर, सर्भर वा सर्भर क्लस्टरमा चलिरहेको अवस्थित कम्प्युटिङ पूर्वाधारसँग ब्याकवर्ड कम्प्याटिबिलिटी सुनिश्चित गर्नको लागि यो महत्त्वपूर्ण छ। स्थानीय स्रोतहरू, "फग नोडहरू" भनिन्छ, प्राप्त डाटा फिल्टर गर्नुहोस् र यसलाई स्थानीय रूपमा प्रशोधन गर्नुहोस् वा थप गणनाहरूको लागि क्लाउडमा पठाउनुहोस्।

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

सामान्यतया, हामीले आवश्यक पर्ने प्रणालीका लागि उपयुक्त सञ्चार प्रोटोकलका २ मोडेलहरू छन्। यी अनुरोध-प्रतिक्रिया र प्रकाशन-सदस्यता हुन्। पहिलो मोडेल अधिक व्यापक रूपमा परिचित छ, विशेष गरी सर्भर-क्लायन्ट वास्तुकलामा। ग्राहकले सर्भरबाट जानकारी अनुरोध गर्दछ, र सर्भरले अनुरोध प्राप्त गर्दछ, यसलाई प्रशोधन गर्दछ र प्रतिक्रिया सन्देश फर्काउँछ। REST HTTP र CoAP प्रोटोकलहरू यस मोडेलमा काम गर्छन्।

दोस्रो मोडेल डाटा उत्पादन गर्ने स्रोतहरू र यस डाटाका प्राप्तकर्ताहरू बीच एसिन्क्रोनस, वितरित, ढीला युग्मन प्रदान गर्ने आवश्यकताबाट उत्पन्न भयो।

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

अनिवार्य रूपमा, यो वास्तुकला घटनामा आधारित छ। र यो अन्तरक्रिया मोडेल IoT, क्लाउड, फगमा अनुप्रयोगहरूका लागि रोचक छ किनभने यसको स्केलेबिलिटी प्रदान गर्ने र विभिन्न यन्त्रहरू बीचको अन्तरसम्बन्धलाई सरल बनाउने क्षमता, गतिशील धेरै-देखि-धेरै सञ्चार र एसिन्क्रोनस सञ्चारलाई समर्थन गर्दछ। प्रकाशन-सदस्यता मोडेल प्रयोग गर्ने सबैभन्दा प्रसिद्ध मानकीकृत सन्देश प्रोटोकलहरू मध्ये केही MQTT, AMQP, र DDS समावेश छन्।

जाहिर छ, प्रकाशन-सदस्यता मोडेलमा धेरै फाइदाहरू छन्:

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

यद्यपि, अनुरोध-प्रतिक्रिया मोडेलको पनि यसको बलहरू छन्। धेरै क्लाइन्ट अनुरोधहरू ह्यान्डल गर्न सर्भर साइडको क्षमता एक मुद्दा होइन, यो प्रमाणित, भरपर्दो समाधानहरू प्रयोग गर्न अर्थ बनाउँछ।

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

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

संसारमा सबैभन्दा प्यारो को हो: प्रोटोकल तुलना गर्दै

अब प्रोटोकल को बल र कमजोरी को बारे मा कुरा गरौं। अगाडि हेर्दै, हामी तुरुन्तै आरक्षण गरौं कि त्यहाँ कुनै स्पष्ट नेता छैन। प्रत्येक प्रोटोकलका केही फाइदा/बेफाइदाहरू हुन्छन्।

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

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

उदाहरणका लागि, परिणामहरू आईओटीसँग काम गर्दा HTTP र MQTT को प्रभावकारिताको तुलनाले MQTT को लागि अनुरोधहरूको लागि प्रतिक्रिया समय HTTP को लागि कम छ भनेर देखाएको छ। र कहिले अध्ययन गर्दै MQTT र CoAP को राउन्ड ट्रिप टाइम (RTT) ले पत्ता लगायो कि CoAP को औसत RTT MQTT को भन्दा 20% कम छ।

Другой एक प्रयोग MQTT र CoAP प्रोटोकलहरूको लागि RTT को साथ दुई परिदृश्यहरूमा गरिएको थियो: स्थानीय नेटवर्क र IoT नेटवर्क। यो आयोटी नेटवर्कमा औसत RTT 2-3 गुणा बढी भएको देखियो। QoS0 सँग MQTT ले CoAP को तुलनामा कम नतिजा देखायो, र QoS1 सँग MQTT ले अनुप्रयोग र यातायात तहहरूमा ACKs को कारणले उच्च RTT देखायो। विभिन्न QoS स्तरहरूको लागि, भीड बिना नेटवर्क विलम्बता MQTT को लागि मिलिसेकेन्ड थियो, र CoAP को लागि सयौं माइक्रोसेकेन्ड। यद्यपि, यो सम्झना लायक छ कि कम भरपर्दो नेटवर्कहरूमा काम गर्दा, TCP को शीर्षमा चलिरहेको MQTT ले पूर्ण रूपमा फरक परिणाम देखाउनेछ।

तुलना पेलोड बढाएर AMQP र MQTT प्रोटोकलहरूको लागि प्रतिक्रिया समयले हल्का लोडको साथ विलम्बता स्तर लगभग समान छ भनेर देखाएको छ। तर ठूलो मात्रामा डाटा स्थानान्तरण गर्दा, MQTT ले छोटो प्रतिक्रिया समय देखाउँछ। थप एक मा अनुसन्धान CoAP लाई ग्यास सेन्सर, मौसम सेन्सर, स्थान सेन्सर (GPS) र मोबाइल नेटवर्क इन्टरफेस (GPRS) ले सुसज्जित सवारी साधनहरूको शीर्षमा तैनाथ गरिएका यन्त्रहरूसँग मेसिन-टु-मेसिन संचार परिदृश्यमा 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 मा TLS, MQTT, AMQP र XMPP, वा CoAP मा DTLS मा आधारित छ, र दुबै DDS भेरियन्टहरूलाई समर्थन गर्दछ।

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

मा परीक्षण आक्रमणहरू TLS र DTLS को धेरै फरक कार्यान्वयनहरूले TLS ले राम्रो काम गरेको फेला पार्यो। DTLS मा आक्रमणहरू यसको त्रुटि सहिष्णुताको कारण बढी सफल थिए।

यद्यपि, यी प्रोटोकलहरूसँग सबैभन्दा ठूलो समस्या यो हो कि तिनीहरू मूल रूपमा IoT मा प्रयोगको लागि डिजाइन गरिएको थिएन र कुहिरो वा क्लाउडमा काम गर्ने उद्देश्य थिएन। ह्यान्डशेकिङको माध्यमबाट, तिनीहरूले प्रत्येक जडान स्थापनाको साथ अतिरिक्त ट्राफिक थप्छन्, जसले कम्प्युटिङ स्रोतहरू निकाल्छ। औसतमा, सुरक्षा तह बिना सञ्चारको तुलनामा TLS का लागि 6,5% र ओभरहेडमा DTLS का लागि 11% वृद्धि भएको छ। स्रोत-धनी वातावरणमा, जुन सामान्यतया अवस्थित हुन्छ बादल छ स्तर, यो एक समस्या हुनेछैन, तर IoT र कुहिरो स्तर बीचको सम्बन्धमा, यो एक महत्त्वपूर्ण सीमा हुन्छ।

के छनौट गर्ने? त्यहाँ कुनै स्पष्ट जवाफ छैन। MQTT र HTTP सबैभन्दा आशाजनक प्रोटोकलहरू जस्तो देखिन्छ किनकि तिनीहरू अन्य प्रोटोकलहरूको तुलनामा तुलनात्मक रूपमा अधिक परिपक्व र अधिक स्थिर IoT समाधानहरू मानिन्छन्।

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

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

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

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

POST विधिको हेडरले (/farm/animals) परिमार्जन गर्नका लागि स्रोत र HTTP संस्करण र सामग्री प्रकार निर्दिष्ट गर्दछ, जुन यस अवस्थामा प्रणालीले व्यवस्थापन गर्ने पशु फार्मको प्रतिनिधित्व गर्ने JSON वस्तु हो (Dulcinea/गाई)। । सर्भरबाट प्रतिक्रियाले 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 स्थान र जनावरको आन्दोलन मापन गर्ने सेन्सरहरूका लागि, ग्राहकले (animalfarm/animal/GPS) र (animalfarm/animal/movement) मा अद्यावधिकहरू प्रकाशित गर्नेछ।

यो जानकारी ब्रोकरलाई पठाइनेछ, जसले यसलाई अस्थायी रूपमा स्थानीय डाटाबेसमा भण्डारण गर्न सक्छ यदि अर्को इच्छुक ग्राहक पछि आएमा।

स्थानीय सर्भरको अतिरिक्त, जसले कुहिरोमा MQTT ब्रोकरको रूपमा काम गर्दछ र जसमा MQTT ग्राहकहरूको रूपमा काम गर्ने Raspberry Pis ले सेन्सर डेटा पठाउँछ, क्लाउड स्तरमा अर्को MQTT ब्रोकर हुन सक्छ। यस अवस्थामा, स्थानीय ब्रोकरलाई पठाइएको जानकारी अस्थायी रूपमा स्थानीय डाटाबेसमा भण्डारण गर्न सकिन्छ र/वा क्लाउडमा पठाइन्छ। यस अवस्थामा फोग MQTT ब्रोकर क्लाउड MQTT ब्रोकरसँग सबै डेटा सम्बद्ध गर्न प्रयोग गरिन्छ। यस वास्तुकलाको साथ, एक मोबाइल अनुप्रयोग प्रयोगकर्ता दुवै दलालहरूको सदस्यता लिन सकिन्छ।

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

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

एकल प्रोटोकल समाधानहरू तिनीहरूको सजिलो कार्यान्वयनको कारण लोकप्रिय छन्। तर यो स्पष्ट छ कि IoT-F2C प्रणालीहरूमा यसले विभिन्न प्रोटोकलहरू संयोजन गर्न अर्थ दिन्छ। विचार यो हो कि विभिन्न प्रोटोकलहरू विभिन्न स्तरहरूमा काम गर्न सक्छन्। उदाहरणका लागि, तीन सारहरू लिनुहोस्: IoT, कुहिरो र क्लाउड कम्प्युटिङको तहहरू। IoT स्तरमा यन्त्रहरूलाई सामान्यतया सीमित मानिन्छ। यस सिंहावलोकनको लागि, IoT टियरहरूलाई सबैभन्दा सीमित, सबैभन्दा कम सीमित क्लाउड, र फग कम्प्युटिङलाई "कहीँ बीचमा" भनेर विचार गरौं। त्यसपछि यो बाहिर जान्छ कि IoT र कुहिरो abstractions बीच, हालको प्रोटोकल समाधान 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 ले अफ्रिकाका जनावरहरूको अध्ययन गर्न मद्दत गर्छ
→ गर्मी लगभग सकिएको छ। त्यहाँ लगभग कुनै अनलिक डाटा बाँकी छैन
→ क्लाउड ब्याकअपमा बचत गर्ने ४ तरिकाहरू
→ जनसंख्याको बारेमा जानकारी समावेश गर्ने एकीकृत संघीय सूचना स्रोतमा

हाम्रो सदस्यता लिनुहोस् तार- च्यानल, ताकि अर्को लेख नछुटाउन! हामी हप्तामा दुई पटक भन्दा बढी र केवल व्यापार मा लेख्छौं।

स्रोत: www.habr.com