পোর্ট ফরওয়ার্ডিং ছাড়াই ESP8266 নিয়ন্ত্রণ: MQTT-এর বহির্গামী পথ

ডিভাইসটি ঘরের রাউটারের পেছনে থাকে, কোনো পোর্ট ফরওয়ার্ডিং নেই এবং কোনো পাবলিক ঠিকানা নেই, তবুও তাকে কয়েক সেকেন্ডের মধ্যে কনফিগারেশন পেতে হয়। কৌশলটি ফায়ারওয়ালে কোনো ফুটো নয়। এটি এমন একটি সংযোগ যা ডিভাইসটি বাইরের দিকে খোলে এমন একটি ব্রোকারের দিকে যেখানে সে পৌঁছাতে পারে, আর সেই ব্রোকার একই প্রতিষ্ঠিত পথ দিয়ে বার্তাগুলো ফেরত পাঠায়। এই নকশায় মানুষের পছন্দের প্রতিটি গুণ এবং এর ভেতরের প্রতিটি ফাঁদ ওই উল্টো দিক থেকেই আসে।

NAT-এর ভেতর দিয়ে আসলে কী যায়

যখন ডিভাইসটি ব্রোকারের সাথে একটি TCP সংযোগ খোলে, ঘরের রাউটার একটি ম্যাপিং তৈরি করে এবং প্রবাহের আয়ুষ্কাল পর্যন্ত সেটি সচল রাখে। সেই প্রবাহের উত্তরগুলো ডিভাইসে ফিরে আসে, কারণ ম্যাপিং আগেই আছে। ব্রোকার কখনো ঘরের দিকে কিছু শুরু করে না, তাই রাউটারের প্রত্যাখ্যান করার মতো কোনো অযাচিত ইনবাউন্ড প্যাকেট থাকে না। এটাই পুরো নেটওয়ার্কিং যুক্তি, আর এজন্যই এই পদ্ধতি এমন নেটওয়ার্কে কাজ করে যা আপনি নিয়ন্ত্রণ করেন না।

ডিভাইসটিকে সংযোগটি সচল রাখতে হবে বা আবার প্রতিষ্ঠা করতে হবে, আর স্থাপত্য নির্ধারিত হয়ে গেলে সেটাই নির্ভরযোগ্যতার প্রশ্ন হয়ে ওঠে।

ব্রোকার টপিক রুট করে, HTTP প্রক্সি করে না

MQTT প্রকাশ ও সদস্যতা বিনিময় সংজ্ঞায়িত করে: ডিভাইস এমন একটি টপিক ফিল্টারে সদস্যতা নেয় যা পড়ার অনুমতি তার আছে, আর অনুমোদিত নিয়ন্ত্রক মিলে যাওয়া টপিকে প্রকাশ করে। ব্রোকার প্রকাশনাগুলো সদস্যতার সাথে মেলায় এবং অনুলিপি পৌঁছে দেয়। এটি জানে না ব্রাউজার অনুরোধ কী, এবং এটি ডিভাইসের ওয়েব সার্ভারে কোনো HTTP GET পাঠাবে না। যদি বিদ্যমান ফার্মওয়্যার কেবল HTTP বোঝে, তবে ব্রোকার নকশার জন্য অ্যাপ্লিকেশন পরিবর্তন বা একটি সচেতন অনুবাদ উপাদান দরকার।

টপিকের নামও অনুমোদন নয়। অধিকাংশ ব্রোকার প্রতি-ক্লায়েন্ট অ্যাক্সেস নিয়ন্ত্রণ তালিকা সমর্থন করে, আর ডিভাইসগুলোকে একটি বৈশ্বিক নেমস্পেস ভাগ করার বদলে নিজেদের প্রকাশ ও সদস্যতা গাছের মধ্যে সীমাবদ্ধ রাখা উচিত।

ডিভাইসের সম্পদ TLS-এর রূপ নির্ধারণ করে

ESP8266-এর RAM সীমিত, আর TLS হ্যান্ডশেক তার সবচেয়ে ব্যয়বহুল কাজ। Arduino কোর ঠিক এই সীমাবদ্ধতার জন্যই BearSSL সরবরাহ করে, আর CA যাচাই করা এবং ফিঙ্গারপ্রিন্ট পিন করার মধ্যকার পছন্দ মেমরি ফুটপ্রিন্ট এবং অন্য নামের বৈধ সার্টিফিকেট থাকা আক্রমণকারী কী করতে পারে, দুটোই বদলে দেয়। যখন হিপ অনুমতি দেয় তখন ব্রোকারের CA যাচাই করাই শক্তিশালী বিকল্প। পেলোডের আকারও গুরুত্বপূর্ণ: MQTT ক্লায়েন্ট একটি বাফার ধরে রাখে, আর তার চেয়ে বড় বার্তা নীরবে কেটে যায় যদি বাফার সচেতনভাবে বাড়ানো না হয়।

কিপঅ্যালাইভ ও সকেট টাইমআউট একই বাজেটের অংশ, কারণ যে ক্লায়েন্ট মৃত সংযোগ কখনো লক্ষ্য করে না সে কোনো ত্রুটি না জানিয়েই কমান্ড পাওয়া বন্ধ করে দেয়।

যে বার্তা-অর্থে দাঁত আছে

একটি ধারিত বার্তা ব্রোকার সংরক্ষণ করে এবং পরে মিলে যাওয়া সদস্যদের কাছে পৌঁছে দেয়, যা বর্তমান অবস্থার জন্য চমৎকার এবং এক-বারের কমান্ডের জন্য বিপজ্জনক: যে ডিভাইস আবার সংযোগ করে সে গতকালের কমান্ড নতুন বলে পেতে পারে। QoS 1 অন্তত একবার পৌঁছানোর নিশ্চয়তা দেয়, তাই অনুলিপি স্বাভাবিক এবং অ্যাপ্লিকেশনকে পুনরাবৃত্তি-নিরাপদ হতে হবে, আদর্শভাবে এমন একটি শনাক্তকারী বা টাইমস্ট্যাম্প দিয়ে যা সে প্রত্যাখ্যান করতে পারে। শেষ ইচ্ছা ডিভাইস পড়ে গেলে আপনাকে স্টেটাস সংকেত দেয়, তবে কেবল যদি সংযোগটি ঝুলে না থেকে সত্যিই ব্যর্থ হয়।

ক্লিন সেশনের আচরণ ঠিক করে ব্রোকার আপনার অনুপস্থিতিতে আপনার সদস্যতাগুলো রাখে কি না, আর এখানে ভুল করাই কিছু ডিভাইসের প্রতিটি পুনঃসংযোগের পরে প্রথম বার্তাটি মিস করার কারণ।

TLS ব্রোকার পর্যন্ত অংশটি রক্ষা করে। এটি ব্রোকার অপারেটরের বিরুদ্ধে এন্ড-টু-এন্ড পেলোড এনক্রিপশন নয়, যে অপারেটর আপনার প্রকাশিত সবকিছু পড়তে পারে।

জীবনচক্র সীমাবদ্ধ করুন এবং ক্ষতিহীন ডেটা দিয়ে পরীক্ষা করুন

ঘন পুনঃপ্রচেষ্টা লুপের বদলে ব্যাকঅফসহ পুনঃসংযোগের পরিকল্পনা করুন, সেশন স্থায়ী না হলে স্পষ্টভাবে আবার সদস্যতা নিন, এবং সংযোগের ফলাফল লগ করুন যাতে নীরব অফলাইন ডিভাইস প্রমাণ রেখে যায়। পুনঃসংযোগের পথটি এমন নমুনা পেলোড দিয়ে পরীক্ষা করুন যা কিছুই করে না, কারণ কমান্ড চ্যানেলের প্রথম উৎপাদন পরীক্ষা সত্যিকারের কমান্ড হওয়া উচিত নয়। তারপর পুনঃসংযোগে বাসি ধারিত বার্তা কী করে তা নিশ্চিত করুন, এবং প্রতিটি টপিকের জন্য সেই আচরণ গ্রহণযোগ্য কি না ঠিক করুন।

এভাবে করলে নকশাটি একটি ইনবাউন্ড নেটওয়ার্ক প্রয়োজন সরিয়ে দেয় এবং ডিভাইস সফটওয়্যার, ব্রোকার নীতি ও বার্তা-অর্থকে লুকানো অনুমানের বদলে দৃশ্যমান কাজ হিসেবে রেখে যায়।