પોર્ટ ફોરવર્ડિંગ વિના ESP8266 નિયંત્રણ: MQTT બહાર જતો માર્ગ

ઉપકરણ ઘરના રાઉટર પાછળ છે, કોઈ પોર્ટ ફોરવર્ડિંગ નથી અને જાહેર સરનામું નથી, તેમ છતાં તેને કેટલીક સેકન્ડોમાં રૂપરેખાંકન મળવું જોઈએ. યુક્તિ ફાયરવોલમાં કોઈ છિદ્ર નથી. તે એક જોડાણ છે જે ઉપકરણ બહારની તરફ એવા બ્રોકર તરફ ખોલે છે જ્યાં તે પહોંચી શકે, અને તે બ્રોકર પછી તે જ સ્થાપિત માર્ગ પરથી સંદેશા પાછા મોકલે છે. આ ડિઝાઇનમાં લોકોને ગમતી દરેક લાક્ષણિકતા અને તેમાંની દરેક જાળ આ ઉલટાવટમાંથી જ આવે છે.

NATમાંથી ખરેખર શું પસાર થાય છે

જ્યારે ઉપકરણ બ્રોકર સાથે TCP જોડાણ ખોલે છે, ત્યારે ઘરનું રાઉટર એક મેપિંગ બનાવે છે અને પ્રવાહના આયુષ્ય સુધી તેને જીવંત રાખે છે. તે પ્રવાહ પરના જવાબો ઉપકરણ પર પાછા આવે છે કારણ કે મેપિંગ પહેલેથી હાજર છે. બ્રોકર ક્યારેય ઘર તરફ કંઈ શરૂ કરતું નથી, તેથી રાઉટરને નકારવા જેવું કોઈ વિનંતી વગરનું આવક પેકેટ નથી. આખી નેટવર્કિંગ દલીલ એ જ છે, અને તેથી જ આ અભિગમ એવા નેટવર્ક પર કામ કરે છે જે તમે નિયંત્રિત કરતા નથી.

ઉપકરણે જોડાણ જીવંત રાખવું પડશે અથવા તેને ફરી સ્થાપિત કરવું પડશે, અને આર્કિટેક્ચર નક્કી થયા પછી તે વિશ્વસનીયતાનો પ્રશ્ન બની જાય છે.

બ્રોકર વિષયોનું રૂટિંગ કરે છે, HTTP પ્રોક્સી કરતું નથી

MQTT પ્રકાશન અને સભ્યતાની આપલે વ્યાખ્યાયિત કરે છે: ઉપકરણ એવા વિષય ફિલ્ટરની સભ્યતા લે છે જે વાંચવાની તેને પરવાનગી છે, અને અધિકૃત નિયંત્રક મેળ ખાતા વિષય પર પ્રકાશિત કરે છે. બ્રોકર પ્રકાશનોને સભ્યતાઓ સાથે મેળવે છે અને નકલો પહોંચાડે છે. તે જાણતું નથી કે બ્રાઉઝર વિનંતી શું છે, અને તે ઉપકરણના વેબ સર્વર પર HTTP GET મોકલશે નહીં. જો હાલનું ફર્મવેર ફક્ત HTTP બોલે છે, તો બ્રોકર ડિઝાઇનને એપ્લિકેશન ફેરફાર અથવા ઇરાદાપૂર્વકનો અનુવાદ ઘટક જોઈએ.

વિષયોના નામ પણ અધિકૃતિ નથી. મોટાભાગના બ્રોકર દરેક ક્લાયન્ટ માટે પ્રવેશ નિયંત્રણ યાદીઓને સમર્થન આપે છે, અને ઉપકરણોને એક વૈશ્વિક નામ અવકાશ વહેંચવાને બદલે તેમના પોતાના પ્રકાશન અને સભ્યતા વૃક્ષો સુધી મર્યાદિત રાખવા જોઈએ.

ઉપકરણના સંસાધનો TLSનો આકાર નક્કી કરે છે

ESP8266માં મર્યાદિત RAM છે, અને TLS હેન્ડશેક તેનું સૌથી ખર્ચાળ કામ છે. Arduino કોર બરાબર આ મર્યાદા માટે BearSSL પૂરું પાડે છે, અને CA ચકાસવા અને ફિંગરપ્રિન્ટ પિન કરવા વચ્ચેની પસંદગી મેમરી ફૂટપ્રિન્ટ અને બીજા નામ માટે માન્ય પ્રમાણપત્ર ધરાવતો હુમલાખોર શું કરી શકે તે બંને બદલે છે. જ્યારે હીપ પરવાનગી આપે ત્યારે બ્રોકરનું CA ચકાસવું એ વધુ મજબૂત વિકલ્પ છે. પેલોડનું કદ પણ મહત્વનું છે: MQTT ક્લાયન્ટ બફર રાખે છે, અને તેના કરતાં મોટા સંદેશા ચૂપચાપ કપાઈ જાય છે જ્યાં સુધી બફર ઇરાદાપૂર્વક વધારવામાં ન આવે.

કીપઅલાઇવ અને સોકેટ સમયમર્યાદા એક જ બજેટનો ભાગ છે, કારણ કે જે ક્લાયન્ટ મૃત જોડાણ ક્યારેય નોંધતું નથી તે કોઈ ભૂલ જણાવ્યા વિના આદેશો મેળવવાનું બંધ કરી દે છે.

જે સંદેશ-અર્થ કરડે છે

જાળવેલો સંદેશ બ્રોકર સંગ્રહે છે અને પછીના મેળ ખાતા સભ્યોને પહોંચાડે છે, જે વર્તમાન સ્થિતિ માટે ઉત્તમ છે અને એક-વખતના આદેશો માટે જોખમી છે: ફરી જોડાતું ઉપકરણ ગઈકાલનો આદેશ નવો હોય તેમ મેળવી શકે છે. QoS 1 ઓછામાં ઓછું એક વખત પહોંચાડવાની ખાતરી આપે છે, તેથી નકલો સામાન્ય છે અને એપ્લિકેશનને પુનરાવૃત્તિ-સુરક્ષિત હોવું જોઈએ, આદર્શ રીતે એવા ઓળખકર્તા કે સમયછાપ સાથે જેને તે નકારી શકે. છેલ્લી ઇચ્છા ઉપકરણ પડી જાય ત્યારે તમને સ્થિતિ સંકેત આપે છે, પરંતુ તે ત્યારે જ જ્યારે જોડાણ ખરેખર નિષ્ફળ જાય, અટકી ન જાય.

સ્વચ્છ સત્રનું વર્તન નક્કી કરે છે કે બ્રોકર તમે ગેરહાજર હો ત્યારે તમારી સભ્યતાઓ રાખે છે કે નહીં, અને આમાં ભૂલ કરવી એ જ કારણ છે કે કેટલાક ઉપકરણો દરેક ફરી જોડાણ પછી પહેલો સંદેશ ચૂકી જાય છે.

TLS બ્રોકર સુધીના ભાગને સુરક્ષિત કરે છે. તે બ્રોકર ઓપરેટર સામે પેલોડનું એન્ડ-ટુ-એન્ડ એન્ક્રિપ્શન નથી, જે તમે તેના દ્વારા પ્રકાશિત કરો છો તે બધું વાંચી શકે છે.

જીવનચક્ર મર્યાદિત કરો અને નિરુપદ્રવી માહિતીથી પરીક્ષણ કરો

ચુસ્ત પુનઃપ્રયાસ લૂપને બદલે બેકઓફ સાથે ફરી જોડાણનું આયોજન કરો, જો સત્ર ચાલુ ન હોય તો સ્પષ્ટ રીતે ફરી સભ્યતા લો, અને જોડાણનું પરિણામ લોગ કરો જેથી શાંત ઑફલાઇન ઉપકરણ પુરાવો છોડે. ફરી જોડાણનો માર્ગ એવા નમૂના પેલોડથી ચકાસો જે કંઈ કરતા નથી, કારણ કે આદેશ ચેનલની પહેલી ઉત્પાદન કસોટી સાચો આદેશ ન હોવો જોઈએ. પછી ફરી જોડાણ વખતે જૂનો જાળવેલો સંદેશ શું કરે છે તેની પુષ્ટિ કરો, અને દરેક વિષય માટે તે વર્તન સ્વીકાર્ય છે કે નહીં તે નક્કી કરો.

આ રીતે કરવાથી ડિઝાઇન એક આવક નેટવર્ક જરૂરિયાત દૂર કરે છે અને ઉપકરણ સોફ્ટવેર, બ્રોકર નીતિ અને સંદેશ-અર્થને છુપાયેલી ધારણાઓને બદલે દૃશ્યમાન કામ તરીકે છોડે છે.