टीसीपी, यूडीपी और एमक्यूटीटी के साथ मेरे अनुभव पर कुछ विचार और साथ ही समीक्षा करने के लिए कुछ अतिरिक्त संसाधन।
यूडीपी के साथ मैं मूक विफलता समस्या में चला गया हूं जिसमें एक नेटवर्क नोड पर एक क्लाइंट, क्लाइंट केवल कुछ यूडीपी संदेशों को देख रहा है जो भेजे गए थे। नेटवर्क ट्रैफ़िक के खराब होने के कई कारण हो सकते हैं। यूडीपी के साथ समस्या यह है कि पैकेट के निर्माता और पैकेट वारंट के उपभोक्ता के बीच नेटवर्क मार्ग के किसी भी नोड में पैकेट को बहुत अधिक मात्रा में छोड़ा जा सकता है। विकिपीडिया विषय पैकेट हानि देखें ।
सवाल यह है कि वर्तमान नेटवर्क के संदर्भ में आपकी हानि दर क्या है। तो अगर यह एक लैन या उप-नेटवर्क के भीतर संचार है तो आपकी हानि दर कम हो सकती है। WAN या इंटरनेट पर आपकी हानि दर काफी अधिक हो सकती है। यूडीपी पैकेट को कई कारणों से छोड़ दिया जाता है और रूट किया जाता है लेकिन नेटवर्क की स्थिति उस हॉप की संख्या में कमी के साथ अनुमति देती है। बिना किसी जवाबदेही के पत्तों के साथ महान शून्य में पैकेट भेजना मौन विफलताओं की संभावना को खोल देता है।
ऐसा लगता है कि आपके मामले में सिर्फ एक साधारण बिल्ली के बच्चे के साथ एक समय पर वापसी के बाद एक बिल्ली को प्राप्त करने के बिना पर्याप्त होगा।
मैंने XML संदेशों को बनाए टीसीपी कनेक्शन पर किया है और इसने बहुत अच्छा काम किया है। मेरे पास एक परत थी जो एक बफर में प्रत्येक संदेश को संभालने के लिए आवेदन परत में पूरा संदेश देती थी। मैंने संदेश की शुरुआत के लिए एक्सएमएल शुरुआती टैग के साथ संदेश को पैकेज करने के लिए एक्सएमएल का उपयोग किया और संपूर्ण संदेश प्राप्त होने पर एक्सएमएल समाप्त होने वाला टैग पता करने के लिए।
टीसीपी में कुछ विशेषताएं हैं जैसे कि पैकेट के अनुक्रमिक क्रम, कोई दोहराता नहीं है, और एक जुड़ा हुआ परिवहन तंत्र होने का मतलब है कि आप जानते हैं कि दूसरा छोर गायब हो जाता है या नहीं, हालांकि यह पता लगाने में थोड़ा समय लग सकता है। कनेक्ट करना और डिस्कनेक्ट करना देरी का परिचय दे सकता है लेकिन सामान्य परिस्थितियों में बोझ नहीं है हालांकि नेटवर्क की स्थिति टीसीपी थ्रूपुट को धीमा कर सकती है।
MQTT एक प्रोटोकॉल है जो एक नेटवर्क ट्रांसपोर्ट लेयर द्वारा ट्रांसपोर्ट किया जाता है, सामान्य रूप से टीसीपी। MQTT एक प्रकाशित / सदस्यता मॉडल का उपयोग करता है ताकि कोई संदेश संग्रह न हो। इसलिए जब एक प्रकाशक एक संदेश प्रकाशित करता है यदि ग्राहक उस समय कनेक्ट नहीं होता है तो जब वह कनेक्ट होता है, तो वह संदेश नहीं देखेगा। MQTT बहुत अधिक वास्तविक समय है, मुझे लगता है कि जो कुछ भी है वह सब कुछ है। मैं छोटे संदेशों के लिए MQTT पसंद करता हूं और JSON पेलोड के साथ MQTT के माध्यम से कुछ प्रयोग कर रहा हूं। इस लेख को देखें एमक्यूटीटी के अवलोकन और सेवा की गुणवत्ता के साथ मॉस्किटो (एमक्यूटीटी) के साथ विश्वसनीय संदेश वितरण । और एक नमूना आवेदन IoT - MQTT पब्लिश और सब्सक्राइबर सी कोड सहित संसाधनों के लिंक के साथ इस संक्षिप्त लेख को देखें ।
संदेश को स्टोर करने के लिए सब्सक्राइबर में JSON टेक्स्ट और SQLite3 डेटाबेस का उपयोग करके MQTT के साथ मेरे प्रयोग https://github.com/RichardChambers/raspberrypi/tree/master/mqtt पर है, हालांकि स्रोत C में है और काफी गड़बड़ है।
यहाँ एक 13 मिनट का वीडियो # 144 इंटरनेट प्रोटोकॉल है: CoAP बनाम MQTT, नेटवर्क सूँघना और IKEA ट्रेडगर्ल हैकिंग की तैयारी । यह CoAP, विवश अनुप्रयोग प्रोटोकॉल के बारे में एक दिलचस्प लेख है : CoAP IoT का 'आधुनिक' प्रोटोकॉल है । CoAP का यह योग है:
शुरुआती अपनाने वाले सहमत हैं कि विवश नेटवर्क और उपकरणों के लिए विवश अनुप्रयोग प्रोटोकॉल बहुत अच्छी तरह से काम करता है। जैसा कि कुछ भी ज्ञात नहीं है: "एक बहुत भीड़भाड़ वाले वायरलेस नेटवर्क पर - वाई-फाई या सेलुलर - सीओएपी काम करना जारी रख सकता है जहां एक ट्रांसमिशन कंट्रोल प्रोटोकॉल-आधारित (टीसीपी) प्रोटोकॉल जैसे एमक्यूटीटी भी एक हैंडशेक को पूरा करने का प्रबंधन नहीं कर सकता है, ”वर्मिलार्ड ने कहा।
ऐसा इसलिए है क्योंकि अधिकांश अन्य IoT प्रोटोकॉल के विपरीत, CoAP UDP पर बनाया गया है। दूसरे शब्दों में, इसका मतलब यह है कि टीसीपी के साथ कोई प्रोटोकॉल हैंडशेक या त्रुटि सुधार नहीं हुआ है। "CoAP HTTP के रूप में विश्वसनीय या MQTT जैसे संदेशों की डिलीवरी की गारंटी नहीं हो सकता है, लेकिन यह बहुत तेज़ है," मैथ्यू ने नोट किया। "यदि आप कुछ संदेश प्राप्त नहीं होने के साथ ठीक हैं, तो आप एक ही समय सीमा के भीतर कई और संदेश भेज सकते हैं।"
एएमक्यूपी, एसटीओएमपी और सीबीओआर जैसे कुछ अन्य हैं जिन्हें आप भी देख सकते हैं। देखें CBOR मानक वेबसाइट के साथ ही इस शोध, कार्यान्वयन और CBOR प्रोटोकॉल के मूल्यांकन । इस लेख को देखें, अपना मैसेजिंग प्रोटोकॉल चुनना: AMQP, MQTT, या STOMP जो AMQP, MQTT और STOMP की तुलना और विरोध करता है और RabitMQ ब्रोकर के बारे में एक नोट के साथ समाप्त होता है:
उम्मीद है, यह आपके उपयोग मामलों में से प्रत्येक के लिए प्रोटोकॉल सूप को नेविगेट करने में कई को शुरू करने में मदद कर सकता है। चूंकि कंपनियों के लिए विभिन्न आवश्यकताओं के साथ कई एप्लिकेशन होना आम बात है, यह निश्चित रूप से संभव है कि आपको विभिन्न अनुप्रयोगों में सभी तीन दलालों की आवश्यकता हो सकती है। जहां एक ठोस मल्टीप्रोटोकॉल, पॉलीग्लॉट ब्रोकर जैसे रैबिटएमक्यू आता है - क्योंकि यह एसटीओएमपी, एमक्यूटीटी, या एएमक्यूपी को भेज सकता है और अन्य लोगों में से एक को बाहर निकाल सकता है। आपको इन प्रोटोकॉलों में से एक द्वारा लॉक-इन करने की आवश्यकता नहीं है - सभी तीनों को RabbitMQ ब्रोकर द्वारा समर्थित है, जिससे यह अनुप्रयोगों के बीच अंतर के लिए एक आदर्श विकल्प है। प्लगइन वास्तुकला भी RabbitMQ को भविष्य में इन प्रोटोकॉल के अतिरिक्त या अपडेट किए गए संस्करणों का समर्थन करने के लिए विकसित करने में सक्षम बनाता है।
कुछ 60 स्लाइड्स का यह स्लाइड शेयर पैकेज दो अलग-अलग IoT समूहों, उपभोक्ताओं और औद्योगिक की जरूरतों को देखते हुए चार अलग-अलग IoT प्रोटोकॉल के बीच तुलना और विपरीत करता है, जिनकी विश्वसनीयता और मजबूती के लिए अलग-अलग आवश्यकताएं होती हैं। IoT के लिए सही मैसेजिंग मानक क्या है? ।
Ackआईएनजी आवश्यक नहीं है। मुझे लगता है कि यूडीपी के शीर्ष पर विश्वसनीयता पर काम करना बहुत अधिक मायने नहीं रखता है, यही टीसीपी के लिए है।