पोर्ट फर्वार्डिङ बिना ESP8266 नियन्त्रण: MQTT को बाहिर जाने मार्ग

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

NAT बाट वास्तवमा के जान्छ

उपकरणले ब्रोकरसँग TCP जडान खोल्दा घरको राउटरले एउटा म्यापिङ बनाउँछ र प्रवाहको आयुभर त्यसलाई जीवित राख्छ। त्यस प्रवाहका जवाफहरू उपकरणमा फर्केर आउँछन् किनकि म्यापिङ पहिले नै छ। ब्रोकरले कहिल्यै घरतिर केही सुरु गर्दैन, त्यसैले राउटरले अस्वीकार गर्नुपर्ने कुनै नमागिएको आगमन प्याकेट हुँदैन। यही सम्पूर्ण नेटवर्किङ तर्क हो, र यही कारण यो दृष्टिकोण तपाईंले नियन्त्रण नगर्ने नेटवर्कमा काम गर्छ।

उपकरणले जडान जीवित राख्नुपर्छ वा पुनः स्थापित गर्नुपर्छ, र वास्तुकला तय भएपछि यही विश्वसनीयताको प्रश्न बन्छ।

ब्रोकरले विषयहरू रुट गर्छ, HTTP प्रोक्सी गर्दैन

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

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

उपकरणका स्रोतहरूले TLS को आकार निर्धारण गर्छन्

ESP8266 मा सीमित RAM छ, र TLS ह्यान्डसेक यसको सबैभन्दा महँगो काम हो। Arduino कोरले BearSSL ठ्याक्कै यही सीमाका लागि उपलब्ध गराउँछ, र CA प्रमाणित गर्ने वा औंठाछाप पिन गर्ने बीचको छनोटले मेमोरी पदचिह्न र अर्को नामका लागि वैध प्रमाणपत्र भएको आक्रमणकारीले के गर्न सक्छ दुवै बदल्छ। हिपले अनुमति दिँदा ब्रोकरको CA प्रमाणित गर्नु बलियो विकल्प हो। पेलोडको आकार पनि महत्त्वपूर्ण छ: MQTT क्लाइन्टले बफर राख्छ, र त्यसभन्दा ठूला सन्देशहरू बफर जानाजान बढाइएन भने चुपचाप काटिन्छन्।

किपअलाइभ र सकेट समयसीमा एउटै बजेटको भाग हुन्, किनकि मृत जडान कहिल्यै नदेख्ने क्लाइन्टले त्रुटि नजनाउँदै आदेश प्राप्त गर्न छोड्छ।

टोक्ने सन्देश-अर्थशास्त्र

राखिएको सन्देश ब्रोकरले भण्डारण गर्छ र पछिका मिल्ने सदस्यहरूलाई दिन्छ, जुन वर्तमान अवस्थाका लागि उत्कृष्ट र एक-पटकका आदेशका लागि खतरनाक छ: फेरि जोडिने उपकरणले हिजोको आदेश नयाँ जस्तै पाउन सक्छ। QoS 1 ले कम्तीमा एक पटक पुर्याउने ग्यारेन्टी दिन्छ, त्यसैले प्रतिलिपिहरू सामान्य हुन् र अनुप्रयोग पुनरावृत्ति-सुरक्षित हुनुपर्छ, आदर्श रूपमा यसले अस्वीकार गर्न सक्ने पहिचानकर्ता वा समयछापसँग। अन्तिम इच्छाले उपकरण खस्दा तपाईंलाई स्थिति संकेत दिन्छ, तर जडान झुन्डिएर नभई साँच्चै असफल भएमा मात्र।

सफा सत्रको व्यवहारले तपाईं बाहिर हुँदा ब्रोकरले तपाईंका सदस्यताहरू राख्छ कि राख्दैन भन्ने निर्धारण गर्छ, र यसमा गल्ती गर्नु नै केही उपकरणहरूले प्रत्येक पुनःजडानपछि पहिलो सन्देश छुटाउनुको कारण हो।

TLS ले ब्रोकरसम्मको भाग सुरक्षित गर्छ। यो ब्रोकर सञ्चालकविरुद्ध पेलोडको एन्ड-टु-एन्ड इन्क्रिप्शन होइन, जसले तपाईंले यसबाट प्रकाशित गर्ने सबै पढ्न सक्छ।

जीवनचक्र सीमित गर्नुहोस् र यसलाई हानिरहित डाटाले परीक्षण गर्नुहोस्

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

यसरी गर्दा, डिजाइनले एउटा आगमन नेटवर्क आवश्यकता हटाउँछ र उपकरण सफ्टवेयर, ब्रोकर नीति र सन्देश-अर्थशास्त्रलाई लुकेका अनुमानको सट्टा देखिने कामका रूपमा छोड्छ।