पोर्ट फॉरवर्डिंगशिवाय ESP8266 नियंत्रण: MQTT चा बाहेर जाणारा मार्ग

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

NAT मधून प्रत्यक्षात काय जाते

उपकरण ब्रोकरशी TCP कनेक्शन उघडते तेव्हा घरातील राउटर एक मॅपिंग तयार करतो आणि प्रवाहाच्या आयुष्यभर ते जिवंत ठेवतो. त्या प्रवाहावरील उत्तरे उपकरणाकडे परत येतात कारण मॅपिंग आधीपासून आहे. ब्रोकर कधीही घराच्या दिशेने काही सुरू करत नाही, त्यामुळे राउटरने नाकारायचे असे कोणतेही न मागितलेले आवक पॅकेट नसते. हा संपूर्ण नेटवर्किंग युक्तिवाद आहे, आणि म्हणूनच हा दृष्टिकोन तुम्ही नियंत्रित न करता त्या नेटवर्कवर चालतो.

उपकरणाने कनेक्शन जिवंत ठेवावे किंवा ते पुन्हा स्थापित करावे, आणि स्थापत्य निश्चित झाल्यावर हाच विश्वासार्हतेचा प्रश्न होतो.

ब्रोकर विषय राउट करतो, HTTP प्रॉक्सी करत नाही

MQTT प्रकाशन आणि सदस्यत्वाच्या देवघेवी परिभाषित करते: उपकरण अशा विषय गाळणीचे सदस्य होते जी वाचण्याची त्याला परवानगी आहे, आणि अधिकृत नियंत्रक जुळणाऱ्या विषयावर प्रकाशित करतो. ब्रोकर प्रकाशने सदस्यत्वांशी जुळवतो आणि प्रती पोहोचवतो. ब्राउझर विनंती काय आहे हे त्याला माहीत नाही, आणि तो उपकरणाच्या वेब सर्व्हरवर HTTP GET पाठवणार नाही. जर विद्यमान फर्मवेअर फक्त HTTP बोलत असेल, तर ब्रोकर रचनेला अनुप्रयोग बदल किंवा जाणीवपूर्वक भाषांतर घटक लागतो.

विषयांची नावेही अधिकृतता नाहीत. बहुतेक ब्रोकर प्रत्येक क्लायंटसाठी प्रवेश नियंत्रण याद्या पुरवतात, आणि उपकरणे एक जागतिक नावांची जागा सामायिक करण्याऐवजी स्वतःच्या प्रकाशन व सदस्यत्व वृक्षांपुरती मर्यादित ठेवावीत.

उपकरणाची साधने TLS चा आकार ठरवतात

ESP8266 मध्ये मर्यादित RAM आहे, आणि TLS हस्तांदोलन हे त्याचे सर्वात महाग काम आहे. Arduino कोर BearSSL नेमके याच मर्यादेसाठी पुरवतो, आणि CA ची पडताळणी करणे व बोटांचा ठसा पिन करणे यातील निवड मेमरीचा ठसा आणि दुसऱ्या नावासाठी वैध प्रमाणपत्र असलेला हल्लेखोर काय करू शकतो दोन्ही बदलते. हीप परवानगी देतो तेव्हा ब्रोकरच्या CA ची पडताळणी हा अधिक मजबूत पर्याय आहे. पेलोडचा आकारही महत्त्वाचा: MQTT क्लायंट बफर ठेवतो, आणि त्यापेक्षा मोठे संदेश बफर जाणीवपूर्वक वाढवल्याशिवाय गुपचूप कापले जातात.

कीपअलाइव्ह आणि सॉकेट कालमर्यादा त्याच अर्थसंकल्पाचा भाग आहेत, कारण मृत कनेक्शन कधीच न ओळखणारा क्लायंट त्रुटी न कळवता आदेश मिळवणे थांबवतो.

चावणारी संदेश-अर्थशास्त्र

ठेवलेला संदेश ब्रोकर साठवतो आणि नंतरच्या जुळणाऱ्या सदस्यांना देतो, जे सध्याच्या स्थितीसाठी उत्तम आणि एकदाच्या आदेशांसाठी धोकादायक आहे: पुन्हा जोडणारे उपकरण कालचा आदेश नवीन असल्यासारखा घेऊ शकते. QoS 1 किमान एकदा पोहोचवण्याची हमी देतो, त्यामुळे प्रती सामान्य आहेत आणि अनुप्रयोगाला पुनरावृत्ती-सुरक्षित असावे लागते, आदर्शपणे अशा ओळखणीने किंवा वेळमुद्रेने जी तो नाकारू शकतो. शेवटची इच्छा उपकरण पडल्यावर तुम्हाला स्थिती संकेत देते, पण तो केवळ तेव्हाच जेव्हा कनेक्शन खरोखर अपयशी होते, लटकत नाही.

स्वच्छ सत्राचे वर्तन ठरवते की तुम्ही बाहेर असताना ब्रोकर तुमची सदस्यत्वे ठेवतो का, आणि यात चूक करणे हेच काही उपकरणे प्रत्येक पुनर्जोडणीनंतर पहिला संदेश चुकवण्याचे कारण आहे.

TLS ब्रोकरपर्यंतचा भाग संरक्षित करते. हे ब्रोकर चालकाविरुद्ध पेलोडचे टोकापासून टोकापर्यंत कूटबद्धीकरण नाही, जो तुम्ही त्यातून प्रकाशित करता ते सर्व वाचू शकतो.

जीवनचक्र मर्यादित करा आणि ते हानिकारक नसलेल्या माहितीने तपासा

घट्ट पुनःप्रयत्न लूपऐवजी बॅकऑफसह पुनर्जोडणीची योजना करा, सत्र टिकाऊ नसल्यास स्पष्टपणे पुन्हा सदस्य व्हा, आणि कनेक्शनचा निकाल नोंदवा जेणेकरून शांत ऑफलाइन उपकरण पुरावा ठेवेल. पुनर्जोडणीचा मार्ग असे नमुना पेलोड वापरून तपासा जे काहीच करत नाहीत, कारण आदेश वाहिनीची पहिली उत्पादन चाचणी खरा आदेश नसावा. मग जुना ठेवलेला संदेश पुनर्जोडणीत काय करतो याची खात्री करा, आणि ते वर्तन प्रत्येक विषयासाठी स्वीकारार्ह आहे का ते ठरवा.

असे केल्यास, रचना एक आवक नेटवर्क आवश्यकता काढून टाकते आणि उपकरण सॉफ्टवेअर, ब्रोकर धोरण आणि संदेश-अर्थशास्त्र हे लपलेल्या गृहीतांऐवजी दिसणारे काम म्हणून ठेवते.