আইওটি, কুয়াশা এবং মেঘ: প্রযুক্তির কথা বলি?

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

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

মেঘ অধিকাংশ IoT অনুরোধ কভার করতে সক্ষম. উদাহরণস্বরূপ, পরিষেবাগুলির নিরীক্ষণ প্রদানের জন্য, ডিভাইসগুলির দ্বারা উত্পন্ন যে কোনও পরিমাণ ডেটার দ্রুত প্রক্রিয়াকরণ, সেইসাথে তাদের ভিজ্যুয়ালাইজেশন। রিয়েল-টাইম সমস্যা সমাধান করার সময় কুয়াশা কম্পিউটিং আরও কার্যকর। তারা অনুরোধের দ্রুত প্রতিক্রিয়া এবং ডেটা প্রক্রিয়াকরণে ন্যূনতম বিলম্ব প্রদান করে। অর্থাৎ, কুয়াশা "মেঘ" পরিপূরক এবং এর ক্ষমতা প্রসারিত করে।

যাইহোক, প্রধান প্রশ্ন ভিন্ন: IoT এর প্রসঙ্গে এই সমস্ত কীভাবে ইন্টারঅ্যাক্ট করা উচিত? একটি সম্মিলিত IoT-Fog-Cloud সিস্টেমে কাজ করার সময় কোন যোগাযোগ প্রোটোকলগুলি সবচেয়ে কার্যকর হবে?

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

কিন্তু রেফারেন্স আর্কিটেকচার এবং যোগাযোগের মান সম্পর্কে কোন একক ধারণা নেই। অতএব, একটি নতুন প্রোটোকল তৈরি করা বা নির্দিষ্ট IoT কাজের জন্য বিদ্যমান একটি সংশোধন করা আইটি সম্প্রদায়ের মুখোমুখি সবচেয়ে গুরুত্বপূর্ণ কাজগুলির মধ্যে একটি।

কোন প্রোটোকল বর্তমানে ব্যবহার করা হচ্ছে এবং তারা কি অফার করতে পারে? আসুন এটা বের করা যাক। তবে প্রথমে, আসুন বাস্তুতন্ত্রের নীতিগুলি নিয়ে আলোচনা করা যাক যেখানে মেঘ, কুয়াশা এবং জিনিসগুলির ইন্টারনেট যোগাযোগ করে৷

IoT ফগ-টু-ক্লাউড (F2C) আর্কিটেকচার

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

যদি পূর্বে শুধুমাত্র 2 স্তর বিবেচনা করা হয়, মেঘ এবং শেষ ডিভাইস, তারপর প্রস্তাবিত আর্কিটেকচার একটি নতুন স্তর প্রবর্তন করে - কুয়াশা কম্পিউটিং। এই ক্ষেত্রে, কুয়াশার স্তরটিকে কয়েকটি উপস্তরে বিভক্ত করা যেতে পারে, সংস্থানগুলির নির্দিষ্টকরণের উপর নির্ভর করে বা নীতিগুলির একটি সেট যা এই উপস্তরগুলিতে বিভিন্ন ডিভাইসের ব্যবহার নির্ধারণ করে।

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

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

ক্লাউড বিভিন্ন যোগাযোগ প্রোটোকল সমর্থন করে, সবচেয়ে সাধারণ হল AMQP এবং REST HTTP। যেহেতু HTTP সুপরিচিত এবং ইন্টারনেটের জন্য উপযুক্ত, প্রশ্ন উঠতে পারে: "আমাদের কি এটি আইওটি এবং কুয়াশার সাথে কাজ করার জন্য ব্যবহার করা উচিত নয়?" যাইহোক, এই প্রোটোকল কর্মক্ষমতা সমস্যা আছে. এই বিষয়ে পরে আরো.

সাধারণভাবে, আমাদের প্রয়োজনীয় সিস্টেমের জন্য উপযুক্ত যোগাযোগ প্রোটোকলের 2টি মডেল রয়েছে৷ এই অনুরোধ-প্রতিক্রিয়া এবং প্রকাশ-সাবস্ক্রাইব. প্রথম মডেলটি আরও ব্যাপকভাবে পরিচিত, বিশেষ করে সার্ভার-ক্লায়েন্ট আর্কিটেকচারে। ক্লায়েন্ট সার্ভার থেকে তথ্যের অনুরোধ করে, এবং সার্ভার অনুরোধটি গ্রহণ করে, এটি প্রক্রিয়া করে এবং একটি প্রতিক্রিয়া বার্তা ফেরত দেয়। REST HTTP এবং CoAP প্রোটোকল এই মডেলে কাজ করে।

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

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

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

স্পষ্টতই, প্রকাশ-সাবস্ক্রাইব মডেলের অনেক সুবিধা রয়েছে:

• প্রকাশক এবং গ্রাহকদের একে অপরের অস্তিত্ব সম্পর্কে জানার প্রয়োজন নেই;
• একজন গ্রাহক বিভিন্ন প্রকাশনা থেকে তথ্য পেতে পারেন, এবং একজন প্রকাশক বিভিন্ন গ্রাহকের কাছে ডেটা পাঠাতে পারেন (অনেক-থেকে-অনেক নীতি);
• প্রকাশক এবং গ্রাহককে যোগাযোগের জন্য একই সময়ে সক্রিয় হতে হবে না, কারণ ব্রোকার (একটি সারিবদ্ধ সিস্টেম হিসাবে কাজ করে) ক্লায়েন্টদের জন্য বার্তা সংরক্ষণ করতে সক্ষম হবে যারা বর্তমানে নেটওয়ার্কের সাথে সংযুক্ত নয়।

যাইহোক, অনুরোধ-প্রতিক্রিয়া মডেলেরও তার শক্তি রয়েছে। যে ক্ষেত্রে সার্ভার সাইডের একাধিক ক্লায়েন্ট অনুরোধগুলি পরিচালনা করার ক্ষমতা কোন সমস্যা নয়, এটি প্রমাণিত, নির্ভরযোগ্য সমাধান ব্যবহার করা বোধগম্য।

এছাড়াও প্রোটোকল রয়েছে যা উভয় মডেলকে সমর্থন করে। উদাহরণস্বরূপ, XMPP এবং HTTP 2.0, যা "সার্ভার পুশ" বিকল্পকে সমর্থন করে। IETF একটি CoAPও প্রকাশ করেছে৷ মেসেজিং সমস্যা সমাধানের প্রয়াসে, অন্যান্য বেশ কয়েকটি সমাধান তৈরি করা হয়েছে, যেমন WebSockets প্রোটোকল বা QUIC (দ্রুত UDP ইন্টারনেট সংযোগ) এর উপর HTTP প্রোটোকলের ব্যবহার।

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

বিশ্বের সবচেয়ে সুন্দর কে: প্রোটোকল তুলনা করা

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

প্রতিক্রিয়া সময়

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

উদাহরণস্বরূপ, ফলাফল IoT-এর সাথে কাজ করার সময় HTTP এবং MQTT-এর কার্যকারিতার তুলনা দেখায় যে MQTT-এর অনুরোধের প্রতিক্রিয়া সময় HTTP-এর চেয়ে কম। এবং কখন অধ্যয়নরত MQTT এবং CoAP-এর রাউন্ড ট্রিপ টাইম (RTT) প্রকাশ করেছে যে CoAP-এর গড় RTT MQTT-এর থেকে 20% কম৷

অন্যান্য পরীক্ষা MQTT এবং CoAP প্রোটোকলের জন্য RTT সহ দুটি পরিস্থিতিতে পরিচালিত হয়েছিল: স্থানীয় নেটওয়ার্ক এবং IoT নেটওয়ার্ক। দেখা গেল যে একটি IoT নেটওয়ার্কে গড় RTT 2-3 গুণ বেশি। QoS0-এর সাথে MQTT CoAP-এর তুলনায় কম ফলাফল দেখিয়েছে, এবং QoS1-এর সাথে MQTT অ্যাপ্লিকেশান এবং পরিবহন স্তরগুলিতে ACK-এর কারণে উচ্চতর RTT দেখিয়েছে। বিভিন্ন QoS স্তরের জন্য, ভিড় ছাড়াই নেটওয়ার্ক লেটেন্সি MQTT-এর জন্য মিলিসেকেন্ড এবং CoAP-এর জন্য শত শত মাইক্রোসেকেন্ড। যাইহোক, এটা মনে রাখা দরকার যে কম নির্ভরযোগ্য নেটওয়ার্কে কাজ করার সময়, TCP-এর উপরে চলমান MQTT সম্পূর্ণ ভিন্ন ফলাফল দেখাবে।

তুলনা পেলোড বাড়িয়ে AMQP এবং MQTT প্রোটোকলের প্রতিক্রিয়া সময় দেখায় যে হালকা লোডের সাথে লেটেন্সি লেভেল প্রায় একই। কিন্তু প্রচুর পরিমাণে ডেটা স্থানান্তর করার সময়, MQTT কম প্রতিক্রিয়া সময় দেখায়। আরও একটিতে অধ্যয়ন গ্যাস সেন্সর, আবহাওয়া সেন্সর, লোকেশন সেন্সর (GPS) এবং একটি মোবাইল নেটওয়ার্ক ইন্টারফেস (GPRS) দিয়ে সজ্জিত যানবাহনের উপরে স্থাপন করা ডিভাইসগুলির সাথে মেশিন-টু-মেশিন যোগাযোগের দৃশ্যে CoAP-কে HTTP-র সাথে তুলনা করা হয়েছিল। মোবাইল নেটওয়ার্কে একটি CoAP বার্তা প্রেরণের জন্য প্রয়োজনীয় সময় HTTP বার্তাগুলি ব্যবহার করার জন্য প্রয়োজনীয় সময়ের চেয়ে প্রায় তিনগুণ কম ছিল।

অধ্যয়ন পরিচালিত হয়েছে যে দুটি নয়, তিনটি প্রোটোকলের তুলনা করা হয়েছে। উদাহরণ স্বরূপ, তুলনা একটি নেটওয়ার্ক এমুলেটর ব্যবহার করে একটি মেডিকেল অ্যাপ্লিকেশন পরিস্থিতিতে IoT প্রোটোকল MQTT, DDS এবং CoAP এর কার্যকারিতা। DDS বিভিন্ন দুর্বল নেটওয়ার্ক অবস্থার অধীনে পরীক্ষিত টেলিমেট্রি লেটেন্সির পরিপ্রেক্ষিতে MQTT কে ছাড়িয়ে গেছে। UDP-ভিত্তিক CoAP অ্যাপ্লিকেশনগুলির জন্য ভাল কাজ করেছে যেগুলির জন্য দ্রুত প্রতিক্রিয়ার সময় প্রয়োজন, তবে, এটি UDP-ভিত্তিক হওয়ার কারণে, উল্লেখযোগ্য অপ্রত্যাশিত প্যাকেটের ক্ষতি হয়েছে।

ব্যান্ডউইথ

তুলনা ব্যান্ডউইথ দক্ষতার পরিপ্রেক্ষিতে MQTT এবং CoAP প্রতি বার্তায় প্রেরিত ডেটার মোট পরিমাণের গণনা হিসাবে পরিচালিত হয়েছিল। CoAP ছোট বার্তা প্রেরণ করার সময় MQTT থেকে কম থ্রুপুট দেখিয়েছে। কিন্তু স্থানান্তরিত মোট বাইট সংখ্যার সাথে দরকারী তথ্য বাইটের সংখ্যার অনুপাতের পরিপ্রেক্ষিতে প্রোটোকলের দক্ষতার তুলনা করার সময়, CoAP আরও কার্যকর হতে দেখা গেছে।

এ বিশ্লেষণ MQTT, DDS (ট্রান্সপোর্ট প্রোটোকল হিসাবে TCP সহ) এবং CoAP ব্যান্ডউইথ ব্যবহার করে দেখা গেছে যে CoAP সাধারণত তুলনামূলকভাবে কম ব্যান্ডউইথ খরচ দেখায়, যা MQTT এবং DDS এর বিপরীতে নেটওয়ার্ক প্যাকেট লস বা নেটওয়ার্ক লেটেন্সি বৃদ্ধির সাথে বাড়ে না, যেখানে ছিল উল্লেখিত পরিস্থিতিতে ব্যান্ডউইথের ব্যবহার বৃদ্ধি। আরেকটি দৃশ্যকল্পে প্রচুর সংখ্যক ডিভাইস একযোগে ডেটা প্রেরণ করে, যা আইওটি পরিবেশে সাধারণ। ফলাফলগুলি দেখিয়েছে যে উচ্চতর ব্যবহারের জন্য CoAP ব্যবহার করা ভাল।

হালকা লোডের অধীনে, CoAP সর্বনিম্ন ব্যান্ডউইথ ব্যবহার করেছে, তার পরে MQTT এবং REST HTTP ব্যবহার করেছে। যাইহোক, যখন পেলোডের আকার বৃদ্ধি পায়, তখন REST HTTP-র সেরা ফলাফল ছিল।

বিদ্যুত ব্যবহার

শক্তি খরচের বিষয়টি সর্বদা অত্যন্ত গুরুত্বপূর্ণ, এবং বিশেষত একটি IoT সিস্টেমে। যদি তুলনা করা যদিও MQTT এবং HTTP বিদ্যুৎ খরচ করে, HTTP অনেক বেশি খরচ করে। এবং CoAP বেশি দক্ষ শক্তি MQTT তুলনায়, ক্ষমতা ব্যবস্থাপনা অনুমতি দেয়. যাইহোক, সাধারণ পরিস্থিতিতে, MQTT ইন্টারনেট অফ থিংস নেটওয়ার্কগুলিতে তথ্য আদান-প্রদানের জন্য আরও উপযুক্ত, বিশেষ করে যদি কোনও পাওয়ার সীমাবদ্ধতা না থাকে।

অন্যান্য একটি পরীক্ষা যা একটি মোবাইল বা অস্থির ওয়্যারলেস নেটওয়ার্ক টেস্টবেডে AMQP এবং MQTT-এর ক্ষমতার তুলনা করে দেখা গেছে যে AMQP আরও সুরক্ষা ক্ষমতা প্রদান করে যখন MQTT আরও শক্তি দক্ষ।

নিরাপত্তা

ইন্টারনেট অফ থিংস এবং কুয়াশা/ক্লাউড কম্পিউটিং বিষয় অধ্যয়ন করার সময় নিরাপত্তা আরেকটি গুরুত্বপূর্ণ সমস্যা উত্থাপিত হয়। নিরাপত্তা ব্যবস্থা সাধারণত HTTP-তে TLS, MQTT, AMQP এবং XMPP, অথবা CoAP-তে DTLS-এর উপর ভিত্তি করে এবং উভয় DDS ভেরিয়েন্টকে সমর্থন করে।

TLS এবং DTLS সমর্থিত সাইফার স্যুট এবং কী বিনিময় করার জন্য ক্লায়েন্ট এবং সার্ভার পক্ষের মধ্যে যোগাযোগ স্থাপনের প্রক্রিয়া দিয়ে শুরু হয়। একটি সুরক্ষিত চ্যানেলে আরও যোগাযোগ নিশ্চিত করার জন্য উভয় পক্ষই সেট নিয়ে আলোচনা করে। দুটির মধ্যে পার্থক্যটি ছোট পরিবর্তনগুলির মধ্যে রয়েছে যা UDP-ভিত্তিক DTLS কে একটি অবিশ্বস্ত সংযোগের উপর কাজ করার অনুমতি দেয়।

এ পরীক্ষা আক্রমণ TLS এবং DTLS-এর বিভিন্ন বাস্তবায়নে দেখা গেছে যে TLS একটি ভাল কাজ করেছে। ত্রুটি সহনশীলতার কারণে DTLS-এর উপর আক্রমণগুলি আরও সফল হয়েছিল।

যাইহোক, এই প্রোটোকলগুলির সাথে সবচেয়ে বড় সমস্যা হল যে এগুলি মূলত আইওটি-তে ব্যবহারের জন্য ডিজাইন করা হয়নি এবং কুয়াশা বা মেঘে কাজ করার উদ্দেশ্যে ছিল না। হ্যান্ডশেকিংয়ের মাধ্যমে, তারা প্রতিটি সংযোগ স্থাপনের সাথে অতিরিক্ত ট্র্যাফিক যোগ করে, যা কম্পিউটিং সংস্থানগুলিকে নিষ্কাশন করে। গড়ে, নিরাপত্তা স্তর ছাড়া যোগাযোগের তুলনায় TLS এর জন্য 6,5% এবং ওভারহেড DTLS এর জন্য 11% বৃদ্ধি পেয়েছে। সম্পদ-সমৃদ্ধ পরিবেশে, যা সাধারণত অবস্থিত মেঘলা স্তর, এটি একটি সমস্যা হবে না, কিন্তু IoT এবং কুয়াশা স্তরের মধ্যে সংযোগে, এটি একটি গুরুত্বপূর্ণ সীমাবদ্ধতা হয়ে ওঠে।

কি নির্বাচন করতে? কোন স্পষ্ট উত্তর নেই. MQTT এবং HTTP সবচেয়ে প্রতিশ্রুতিশীল প্রোটোকল বলে মনে হয় কারণ এগুলিকে অন্যান্য প্রোটোকলের তুলনায় তুলনামূলকভাবে আরও পরিপক্ক এবং আরও স্থিতিশীল IoT সমাধান হিসাবে বিবেচনা করা হয়।

একীভূত যোগাযোগ প্রোটোকলের উপর ভিত্তি করে সমাধান

একক-প্রটোকল সমাধানের অনুশীলনের অনেক অসুবিধা রয়েছে। উদাহরণস্বরূপ, একটি সীমাবদ্ধ পরিবেশের জন্য উপযুক্ত একটি প্রোটোকল এমন একটি ডোমেনে কাজ নাও করতে পারে যেখানে কঠোর নিরাপত্তার প্রয়োজনীয়তা রয়েছে৷ এটা মাথায় রেখে, MQTT এবং REST HTTP ছাড়া, IoT-এর Fog-to-Cloud ইকোসিস্টেমের প্রায় সব সম্ভাব্য একক-প্রোটোকল সমাধান আমরা বাতিল করে দিয়েছি।

REST HTTP একটি একক-প্রটোকল সমাধান হিসাবে

আইওটি-টু-ফগ স্পেসে REST HTTP অনুরোধ এবং প্রতিক্রিয়াগুলি কীভাবে ইন্টারঅ্যাক্ট করে তার একটি ভাল উদাহরণ রয়েছে: স্মার্ট খামার. প্রাণীগুলি পরিধানযোগ্য সেন্সর (IoT ক্লায়েন্ট, C) দিয়ে সজ্জিত এবং একটি স্মার্ট ফার্মিং সিস্টেম (ফগ সার্ভার, এস) দ্বারা ক্লাউড কম্পিউটিংয়ের মাধ্যমে নিয়ন্ত্রিত।

POST পদ্ধতির শিরোনামটি (/farm/animals) এবং সেইসাথে HTTP সংস্করণ এবং বিষয়বস্তুর প্রকার সংশোধন করার জন্য সংস্থান নির্দিষ্ট করে, যা এই ক্ষেত্রে একটি JSON অবজেক্ট যা পশু খামারের প্রতিনিধিত্ব করে যা সিস্টেমটি পরিচালনা করবে (ডুলসিনিয়া/গরু) . সার্ভার থেকে প্রতিক্রিয়া নির্দেশ করে যে HTTPS স্ট্যাটাস কোড 201 (রিসোর্স তৈরি) পাঠিয়ে অনুরোধটি সফল হয়েছে। GET পদ্ধতিতে URI-তে শুধুমাত্র অনুরোধ করা রিসোর্স নির্দিষ্ট করতে হবে (উদাহরণস্বরূপ, /farm/animals/1), যা সার্ভার থেকে সেই ID সহ প্রাণীর JSON উপস্থাপনা প্রদান করে।

PUT পদ্ধতি ব্যবহার করা হয় যখন কিছু নির্দিষ্ট রিসোর্স রেকর্ড আপডেট করার প্রয়োজন হয়। এই ক্ষেত্রে, সংস্থানটি পরামিতি পরিবর্তন করার জন্য URI এবং বর্তমান মান (উদাহরণস্বরূপ, নির্দেশ করে যে গরু বর্তমানে হাঁটছে, /farm/animals/1? state=walking)। অবশেষে, DELETE পদ্ধতিটি GET পদ্ধতির সমানভাবে ব্যবহার করা হয়, কিন্তু অপারেশনের ফলে সম্পদটি মুছে দেয়।

MQTT একটি একক-প্রটোকল সমাধান হিসাবে

আসুন একই স্মার্ট ফার্ম নেওয়া যাক, তবে REST HTTP এর পরিবর্তে আমরা MQTT প্রোটোকল ব্যবহার করি। Mosquitto লাইব্রেরি ইনস্টল করা একটি স্থানীয় সার্ভার একটি দালাল হিসাবে কাজ করে। এই উদাহরণে, একটি সাধারণ কম্পিউটার (ফার্ম সার্ভার হিসাবে উল্লেখ করা হয়) রাস্পবেরি পাই একটি MQTT ক্লায়েন্ট হিসাবে কাজ করে, যা Paho MQTT লাইব্রেরির ইনস্টলেশনের মাধ্যমে বাস্তবায়িত হয়, যা Mosquitto ব্রোকারের সাথে সম্পূর্ণভাবে সামঞ্জস্যপূর্ণ।

এই ক্লায়েন্টটি সেন্সিং এবং কম্পিউটিং ক্ষমতা সহ একটি ডিভাইসের প্রতিনিধিত্বকারী একটি IoT বিমূর্ততা স্তরের সাথে মিলে যায়। অন্যদিকে, মধ্যস্থতাকারী, বিমূর্ততার একটি উচ্চ স্তরের সাথে সঙ্গতিপূর্ণ, একটি কুয়াশা কম্পিউটিং নোডের প্রতিনিধিত্ব করে যা বৃহত্তর প্রক্রিয়াকরণ এবং স্টোরেজ ক্ষমতা দ্বারা চিহ্নিত করা হয়।

প্রস্তাবিত স্মার্ট ফার্মের দৃশ্যে, রাস্পবেরি পাই অ্যাক্সিলোমিটার, জিপিএস এবং তাপমাত্রা সেন্সরগুলির সাথে সংযোগ করে এবং এই সেন্সরগুলি থেকে একটি কুয়াশা নোডে ডেটা প্রকাশ করে। আপনি সম্ভবত জানেন, MQTT বিষয়গুলিকে একটি শ্রেণিবিন্যাস হিসাবে বিবেচনা করে। একটি একক MQTT প্রকাশক নির্দিষ্ট বিষয়গুলির একটি সেটে বার্তা প্রকাশ করতে পারে। আমাদের ক্ষেত্রে তাদের মধ্যে তিনটি আছে। একটি সেন্সরের জন্য যা একটি পশুর শস্যাগারের তাপমাত্রা পরিমাপ করে, ক্লায়েন্ট একটি থিম নির্বাচন করে (পশুর খামার/শেড/তাপমাত্রা)। সেন্সরগুলির জন্য যেগুলি অ্যাক্সিলোমিটারের মাধ্যমে জিপিএস অবস্থান এবং প্রাণীর গতিবিধি পরিমাপ করে, ক্লায়েন্ট (অ্যানিমালফার্ম/প্রাণী/জিপিএস) এবং (অ্যানিমালফার্ম/প্রাণী/চলাচল) আপডেট প্রকাশ করবে।

এই তথ্যটি ব্রোকারের কাছে পাঠানো হবে, যিনি পরবর্তীতে অন্য আগ্রহী গ্রাহকের সাথে আসার ক্ষেত্রে অস্থায়ীভাবে স্থানীয় ডাটাবেসে এটি সংরক্ষণ করতে পারেন।

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

যদি ব্রোকারগুলির একটির সাথে সংযোগ ব্যর্থ হয় (উদাহরণস্বরূপ, ক্লাউড) তবে শেষ ব্যবহারকারী অন্য (কুয়াশা) থেকে তথ্য পাবেন। এটি সম্মিলিত কুয়াশা এবং ক্লাউড কম্পিউটিং সিস্টেমের একটি বৈশিষ্ট্যযুক্ত বৈশিষ্ট্য। ডিফল্টরূপে, মোবাইল অ্যাপটিকে প্রথমে কুয়াশা MQTT ব্রোকারের সাথে সংযোগ করতে কনফিগার করা যেতে পারে এবং যদি এটি ব্যর্থ হয়, তাহলে ক্লাউড MQTT ব্রোকারের সাথে সংযোগ করতে। এই সমাধানটি IoT-F2C সিস্টেমের অনেকগুলির মধ্যে একটি।

মাল্টি-প্রটোকল সমাধান

একক প্রোটোকল সমাধানগুলি তাদের সহজ বাস্তবায়নের কারণে জনপ্রিয়। কিন্তু এটা স্পষ্ট যে IoT-F2C সিস্টেমে বিভিন্ন প্রোটোকল একত্রিত করা বোধগম্য। ধারণাটি হল যে বিভিন্ন প্রোটোকল বিভিন্ন স্তরে কাজ করতে পারে। উদাহরণস্বরূপ, তিনটি বিমূর্ততা নিন: IoT, কুয়াশা এবং ক্লাউড কম্পিউটিং এর স্তরগুলি। IoT স্তরের ডিভাইসগুলিকে সাধারণত সীমিত বলে মনে করা হয়। এই সংক্ষিপ্ত বিবরণের জন্য, আসুন IoT স্তরগুলিকে সবচেয়ে সীমাবদ্ধ, ক্লাউড সবচেয়ে কম সীমাবদ্ধ এবং কুয়াশা কম্পিউটিংকে "মাঝখানে কোথাও" হিসাবে বিবেচনা করি। তখন দেখা যাচ্ছে যে IoT এবং কুয়াশার বিমূর্ততার মধ্যে, বর্তমান প্রোটোকল সমাধানগুলির মধ্যে রয়েছে MQTT, CoAP এবং XMPP। কুয়াশা এবং মেঘের মধ্যে, অন্যদিকে, AMQP হল REST HTTP সহ ব্যবহৃত প্রধান প্রোটোকলগুলির মধ্যে একটি, যা এর নমনীয়তার কারণে IoT এবং কুয়াশার স্তরগুলির মধ্যেও ব্যবহৃত হয়।

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

যেহেতু এটি বর্তমানে হয় না, তাই উল্লেখযোগ্য পার্থক্য নেই এমন প্রোটোকলগুলিকে একত্রিত করা বোধগম্য। এই লক্ষ্যে, একটি সম্ভাব্য সমাধান দুটি প্রোটোকলের সংমিশ্রণের উপর ভিত্তি করে যা একই স্থাপত্য শৈলী অনুসরণ করে, REST HTTP এবং CoAP। আরেকটি প্রস্তাবিত সমাধান হল দুটি প্রোটোকলের সংমিশ্রণের উপর ভিত্তি করে যা প্রকাশ-সাবস্ক্রাইব কমিউনিকেশন, MQTT এবং AMQP প্রদান করে। অনুরূপ ধারণা ব্যবহার করা (MQTT এবং AMQP উভয়ই ব্রোকার ব্যবহার করে, CoAP এবং HTTP ব্যবহার করে REST) ​​এই সমন্বয়গুলি বাস্তবায়ন করা সহজ করে তোলে এবং কম একীকরণ প্রচেষ্টার প্রয়োজন হয়।

চিত্র (a) দুটি অনুরোধ-প্রতিক্রিয়া ভিত্তিক মডেল দেখায়, HTTP এবং CoAP, এবং একটি IoT-F2C সমাধানে তাদের সম্ভাব্য বসানো। যেহেতু HTTP আধুনিক নেটওয়ার্কে সবচেয়ে সুপরিচিত এবং গৃহীত প্রোটোকলগুলির মধ্যে একটি, এটি অন্য মেসেজিং প্রোটোকল দ্বারা সম্পূর্ণরূপে প্রতিস্থাপিত হওয়ার সম্ভাবনা কম। ক্লাউড এবং কুয়াশার মধ্যে থাকা শক্তিশালী ডিভাইসগুলির প্রতিনিধিত্বকারী নোডগুলির মধ্যে, REST HTTP একটি স্মার্ট সমাধান।

অন্যদিকে, সীমিত কম্পিউটিং সংস্থান সহ ডিভাইসগুলির জন্য যা কুয়াশা এবং আইওটি স্তরগুলির মধ্যে যোগাযোগ করে, এটি CoAP ব্যবহার করা আরও দক্ষ। CoAP এর একটি বড় সুবিধা হল আসলে HTTP এর সাথে এর সামঞ্জস্য, যেহেতু উভয় প্রোটোকলই REST নীতির উপর ভিত্তি করে।

চিত্র (b) MQTT এবং AMQP সহ একই পরিস্থিতিতে দুটি প্রকাশ-সাবস্ক্রাইব যোগাযোগ মডেল দেখায়। যদিও উভয় প্রোটোকল অনুমানমূলকভাবে প্রতিটি বিমূর্ত স্তরে নোডের মধ্যে যোগাযোগের জন্য ব্যবহার করা যেতে পারে, তাদের অবস্থান কর্মক্ষমতার উপর ভিত্তি করে নির্ধারণ করা উচিত। MQTT সীমিত কম্পিউটিং সংস্থান সহ ডিভাইসগুলির জন্য একটি হালকা প্রোটোকল হিসাবে ডিজাইন করা হয়েছিল, তাই এটি IoT-Fog যোগাযোগের জন্য ব্যবহার করা যেতে পারে। AMQP আরও শক্তিশালী ডিভাইসগুলির জন্য আরও উপযুক্ত, যা আদর্শভাবে এটিকে কুয়াশা এবং ক্লাউড নোডের মধ্যে অবস্থান করবে। MQTT এর পরিবর্তে, XMPP প্রোটোকল IoT-এ ব্যবহার করা যেতে পারে কারণ এটি হালকা ওজনের বলে বিবেচিত হয়। কিন্তু এই ধরনের পরিস্থিতিতে এটি এত ব্যাপকভাবে ব্যবহৃত হয় না।

তথ্যও

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

এর স্থিতিশীলতা এবং সহজ কনফিগারেশনের কারণে, MQTT হল একটি প্রোটোকল যা সীমিত ডিভাইসগুলির সাথে IoT স্তরে ব্যবহার করার সময় সময়ের সাথে সাথে এর উচ্চতর কর্মক্ষমতা প্রমাণ করেছে। সিস্টেমের কিছু অংশে যেখানে সীমিত যোগাযোগ এবং ব্যাটারি খরচ কোনো সমস্যা নয়, যেমন কিছু কুয়াশা ডোমেন এবং বেশিরভাগ ক্লাউড কম্পিউটিং, RESTful HTTP একটি সহজ পছন্দ। CoAP কেও বিবেচনায় নেওয়া উচিত কারণ এটি একটি IoT মেসেজিং স্ট্যান্ডার্ড হিসাবে দ্রুত বিকশিত হচ্ছে এবং সম্ভবত এটি অদূর ভবিষ্যতে MQTT এবং HTTP এর মতো স্থিতিশীলতা এবং পরিপক্কতার স্তরে পৌঁছাবে। কিন্তু মান বর্তমানে বিকশিত হচ্ছে, যা স্বল্প-মেয়াদী সামঞ্জস্যের সমস্যাগুলির সাথে আসে।

আপনি ব্লগে আর কি পড়তে পারেন? Cloud4Y

→ কম্পিউটার আপনাকে সুস্বাদু করে তুলবে
→ AI আফ্রিকার প্রাণীদের অধ্যয়ন করতে সাহায্য করে
→ গ্রীষ্ম প্রায় শেষ। প্রায় কোন অপ্রকাশিত তথ্য অবশিষ্ট নেই
→ ক্লাউড ব্যাকআপে সংরক্ষণ করার 4টি উপায়
→ জনসংখ্যার তথ্য সম্বলিত একটি ইউনিফাইড ফেডারেল তথ্য সম্পদে

আমাদের সদস্যতা Telegram-চ্যানেল, যাতে পরবর্তী নিবন্ধটি মিস না হয়! আমরা সপ্তাহে দুবারের বেশি লিখি না এবং শুধুমাত্র ব্যবসার উপর।

উত্স: www.habr.com