मैं अपने पहले आईओटी पीओसी पर काम करता हूं, डिवाइस आमतौर पर प्रति घंटे/दिन में एक बार सेंसर डेटा उत्पन्न करेगा। मैंने इस तरह की वास्तुकला की योजना बनाई है: - सेंसर डेटा इनपुट के लिए 1 साझा विषय (डिवाइस से बैकएंड दिशा) - प्रत्येक डिवाइस शुरू में अपने स्वयं के विशिष्ट विषय उर्फ ​​​​/डिवाइस/{आईडी}/अधिसूचना की सदस्यता लेगा।

अब, साझा विषय पर सेंसर डेटा सबमिट करने के बाद, मैं डिवाइस को गहरी नींद में डालने की योजना बना रहा हूं (डिवाइस को केवल वाईफाई पैकेट या टाइमर द्वारा जगाया जा सकता है), इस राज्य में ब्रोकर से टीसीपी कनेक्शन खो गया है।

प्रश्न: डिवाइस के बैक-वेक-अप और एमक्यूटीटी ब्रोकर से टीसीपी कनेक्शन फिर से स्थापित होने के बाद, क्या डिवाइस को वे सभी संदेश प्राप्त होंगे जो सर्वर द्वारा आउट-ऑफ-सर्विस अवधि के दौरान उत्पन्न किए गए थे, या ये संदेश उपलब्ध नहीं होंगे?

1
kensai 24 सितंबर 2017, 08:12

2 जवाब

क्लाइंट को ब्रोकर से जोड़ने के दौरान, CleanSession फ्लैग ब्रोकर को QoS 1 या QoS 2 के छूटे हुए संदेशों को कतारबद्ध करने में सक्षम बनाता है (QoS 0 संदेशों को संग्रहीत करना कार्यान्वयन-निर्भर है)।

एमक्यूटीटी 3.1.1 मानक Section 3.1.2.4 निर्दिष्ट करता है कि:

यदि CleanSession 0 पर सेट है, तो सर्वर को वर्तमान सत्र से राज्य के आधार पर क्लाइंट के साथ संचार फिर से शुरू करना होगा (जैसा कि क्लाइंट पहचानकर्ता द्वारा पहचाना गया है)। यदि क्लाइंट पहचानकर्ता से संबद्ध कोई सत्र नहीं है तो सर्वर को एक नया सत्र बनाना होगा। क्लाइंट और सर्वर के डिस्कनेक्ट होने के बाद क्लाइंट और सर्वर को सत्र को स्टोर करना होगा [MQTT-3.1.2-4]। एक सत्र के वियोग के बाद जिसमें CleanSession 0 पर सेट था, सर्वर को आगे QoS 1 और QoS 2 संदेशों को संग्रहीत करना होगा जो किसी भी सदस्यता से मेल खाते हैं जो क्लाइंट के पास सत्र राज्य के हिस्से के रूप में डिस्कनेक्शन के समय था [MQTT-3.1.2- 5]। यह QoS 0 संदेशों को भी संग्रहीत कर सकता है जो समान मानदंडों को पूरा करते हैं

लगातार सत्र के साथ समस्या यह है कि यह बड़ी संख्या में संदेशों को कतारबद्ध कर सकता है, इसलिए पुन: कनेक्शन पर क्लाइंट पर छूटे हुए संदेशों की बौछार हो जाती है। यह वांछनीय हो सकता है यदि आपको रीडिंग के पूर्ण अनुक्रम को जानने की आवश्यकता है, या यदि क्लाइंट कम-शक्ति, बैटरी-आधारित एम्बेडेड डिवाइस पर चल रहा है, तो अत्यधिक अवांछनीय है।

इसे संबोधित करने के लिए, MQTT एक अन्य विशेषता प्रदान करता है: retained प्रकाशन संदेशों में ध्वजांकित करें।

एमक्यूटीटी 3.1.1 मानक खंड 3.3.1.3 निर्दिष्ट करता है कि:

यदि क्लाइंट द्वारा सर्वर को भेजे गए प्रकाशित पैकेट में RETAIN ध्वज 1 पर सेट है, तो सर्वर को एप्लिकेशन संदेश और उसके QoS को संग्रहीत करना होगा, ताकि इसे भविष्य के उन ग्राहकों तक पहुंचाया जा सके जिनकी सदस्यता इसके विषय नाम [MQTT- से मेल खाती है। 3.3.1-5]। जब एक नई सदस्यता स्थापित की जाती है, तो प्रत्येक मिलान विषय के नाम पर अंतिम अनुरक्षित संदेश, यदि कोई हो, ग्राहक को भेजा जाना चाहिए [MQTT-3.3.1-6]। यदि सर्वर को एक QoS 0 संदेश प्राप्त होता है जिसमें RETAIN ध्वज 1 पर सेट होता है, तो उसे उस विषय के लिए पहले से बनाए गए किसी भी संदेश को त्यागना होगा। इसे उस विषय के लिए नए QoS 0 संदेश को नए बनाए रखा संदेश के रूप में संग्रहीत करना चाहिए, लेकिन वह इसे किसी भी समय त्यागना चुन सकता है - यदि ऐसा होता है तो उस विषय के लिए कोई बनाए रखा संदेश नहीं होगा

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

2
Skrino 2 अगस्त 2019, 05:28

बहुत जल्दी मुझे अपने आप में एक उत्तर मिल गया। लगातार सत्र उत्तर है। मैं लगातार सदस्यता की तलाश में था और शुरुआत में सफल नहीं था ...

यहाँ अंत में मेरे मामले के बारे में बहुत अच्छा लेख है: http://www.hivemq.com/ ब्लॉग/mqtt-आवश्यक-भाग-7-लगातार-सत्र-क़तार-संदेश

तो हाँ, लगातार सदस्यता को लगातार सत्र कहा जाता है और हाँ यह संभव है।

0
kensai 10 अक्टूबर 2017, 11:55