MQTT की तुलना में आसान है? एमक्यूटीटी / यूडीपी

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

क्यों

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

इस समय के दौरान, मुझे पता चला (हाँ, वैसे, मैं पहले से ही यह समझ गया था) कि यूडी सिस्टम की मुख्य संपत्ति विश्वसनीयता है।

एक केंद्रीय नोड के साथ सभी प्रणालियां परिभाषा के अनुसार अविश्वसनीय हैं। इसलिए किसी भी केंद्रीय हब का उपयोग किए बिना सिस्टम घटकों के इंटरकनेक्ट को प्राप्त करने की इच्छा (और वास्तविक स्मार्ट होम में उनमें से बहुत कुछ हैं)।

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

तार्किक निष्कर्ष यह है कि यूडीपी ब्रॉडकास्ट एक आदर्श उपकरण है।

(हां, मैं मानता हूं कि अपार्टमेंट का आंतरिक नेटवर्क एक फ़ायरवॉल द्वारा बंद है।)

पेशेवरों में क्या है:

अविश्वसनीय रूप से सरल कार्यान्वयन। छोटी मेमोरी के साथ एक न्यूनतम माइक्रोकंट्रोलर एक यूडीपी पैकेट भेज सकता है। सेंसर के लिए, यहां तक ​​कि यूडीपी रिसेप्शन की भी आवश्यकता नहीं है।

बहुत कम विलंबता। केंद्रीय हब में कोई आगे नहीं है, यूडीपी पैकेट वितरण समय व्यावहारिक रूप से एक आधुनिक प्रणाली में न्यूनतम समय स्लॉट है।

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

कम नेटवर्क यातायात। नीचे कहीं नहीं। टीसीपी और पावती केवल यातायात जोड़ते हैं, लेकिन विश्वसनीयता नहीं जोड़ते हैं। एक असफल सेंसर टीसीपी एसीके प्राप्त करने पर काम नहीं करेगा। और हम अपडेट की अनुपस्थिति से विफलता की पहचान करते हैं।

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

कोई सिस्टम कॉन्फ़िगरेशन की आवश्यकता नहीं है। दलाल, हब, आदि का पता दर्ज करने के लिए किसी की जरूरत नहीं है। हालांकि, सेंसर कॉन्फ़िगरेशन अभी भी आवश्यक है - आपको सेंसर आईडी को पंजीकृत करने की आवश्यकता है। लेकिन जब सिस्टम के अन्य हिस्सों को अन्य सर्वरों में स्थानांतरित किया जाता है, तो प्रतिक्रिया घटकों के पुनर्गठन की आवश्यकता नहीं होती है।

यह विशेष रूप से दिलचस्प है कि डेटा एक्सचेंज का यह मॉडल स्वाभाविक रूप से प्रसारित मीडिया जैसे कि एक रेडियो चैनल या आरएस / 485 पर अच्छी तरह से फिट बैठता है। मैंने इसके साथ प्रयोग नहीं किया है, और ऐसे वातावरण में प्रोटोकॉल को नियंत्रित करने की आवश्यकता है। यहाँ modbus से CRC16 को लागू करना तर्कसंगत है।

Minuses भी स्पष्ट हैं: वितरण की विश्वसनीयता केवल हार्डवेयर और नेटवर्क पर ट्रैफ़िक द्वारा निर्धारित की जाती है, ठीक है, अगर दुश्मन नेटवर्क में मिला, तो प्रोटोकॉल तुरंत पराजित हो जाता है। सच है, हम फ्रैंक होंगे, अन्य विशिष्ट स्मार्ट होम प्रोटोकॉल हैक करना सेकंड का मामला है, इसलिए यह MQTT / UDP का विवादास्पद दोष है। एक और गैर-स्पष्ट माइनस प्रति आईपी पते पर अधिकतम एक रिसीवर है।

क्या किया गया है और स्रोत कोड भंडार में निहित है:

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

अगर मेरे पास अधिक समय हो तो मैं क्या करूंगा:

• मैं ओपनहब के लिए एक मॉड्यूल लिखूंगा।
• JSON पर एक प्रोटोकॉल वैरिएंट को अन्य पोर्ट पर और मुख्य प्रारूप और पोर्ट के लिए एक कनवर्टर बना देगा। या दोनों दिशाओं में एक द्वार।
• मैं मुख्य प्लेटफार्मों के लिए कार्यान्वयन ब्लैंक बनाऊंगा। Arduino के लिए, मैंने वजन के लिए एक दृष्टिकोण बनाया और वास्तव में कोड का परीक्षण किया, लेकिन सब कुछ ठीक से डिजाइन नहीं किया। रास्पबेरी के लिए, पायथन में परीक्षण के मामले उपयुक्त हैं।
• डिजिटल रूप से हस्ताक्षर और एन्क्रिप्ट करेगा, लेकिन यह स्पष्ट नहीं है कि कैसे।
• मल्टीकास्ट।

उस पर धन्यवाद, रिपॉजिटरी में आपका स्वागत है

पुनश्च: एक समान दृष्टिकोण, लेकिन एक मल्टीकास्ट के साथ, इस लेख में वर्णित है।