سناریوهای MQTT و الگوی انتشار و اشتراک

در این بخش نحوه استفاده از پروتکل پیام رسانی سبک به روش انتشار – اشتراک برای اینترنت اشیاء را شرح خواهیم داد . همچنین چگونگی کارکرد MQTT و سیستم پیام رسان سبک ، اصول اولیه MQTT ، واژگان خاص آن و حالت های کاری آن را یاد خواهیم گرفت .

مباحث مورد بررسی عبارتند از :

• درک سناریوهای مناسب برای پروتکل MQTT
• کار با الگوی انتشار-اشتراک
• کار با فیلترینگ پیام
• یادگیری مفاهیم اساسی مربوط به MQTT
• درک اجزای MQTT : کلاینت ها ، سرورها یا کارگزاران و ارتباطات
• نصب سرور Mosquitto MQTT روی Linux ، macOS یا Windows
• انتشار پیام ها
• اشتراک در موضوعات
• لغو اشتراک در موضوعات
• کار با بهترین روش ها هنگام ایجاد موضوعات ها
• درک wildcardها
• کسب اطلاعات در مورد سطوح مختلف کیفیت خدمات
• کار با حداقل یک بار تحویل
• کار با دقیقا یک بار تحویل

درک سناریوهای مناسب برای پروتکل MQTT

تصور کنید که ما چندین دستگاه مختلف داریم که باید داده ها را بین خود رد و بدل کنند . این دستگاه ها داده را از دستگاه های دیگر درخواست میکنند و دستگاه های دریافت کننده درخواست ها باید به داده های خواسته شده پاسخ دهند . سپس دستگاه هایی که داده را درخواست کرده بودند داده های دریافتی را پردازش می کنند .

این دستگاه ها بردهای اینترنت اشیا هستند که ده ها سنسور به آنها متصل می شود . بردهای IoT  قدرت پردازش متفاوتی دارند ، از جمله این بردها میتوان به Raspberry Pi 3 ،Raspberry Pi Model B ، Intel Edison و Intel Joule 570x اشاره کرد . هر یک از این بردها باید قابلیت ارسال و دریافت داده را داشته باشند . علاوه بر این ، بسیاری از دستگاه های تلفن همراه باید بتوانند به این بردها داده ارسال و دریافت کنند و از بسیاری از زبان های برنامه نویسی نیز پشتیبانی کنند .

ما می خواهیم داده ها را بصورت Real Time از طریق اینترنت ارسال / دریافت کنیم ولی ممکن است با برخی از مشکلات شبکه روبرو شویم ، یعنی شبکه های بی سیم تا حدودی غیرقابل اعتماد هستند و برخی از محیط ها تأخیر بالایی دارند . قدرت برخی از دستگاه ها کم است ، بسیاری از آنها با باتری کار می کنند و منابع آنها کم است . علاوه بر این ، باید مراقب استفاده از پهنای باند شبکه باشیم زیرا برخی از دستگاه ها از اینترنت حجمی استفاده می کنند.

با استفاده از درخواست های HTTP میتوان مدل انتشار-اشتراک برای تبادل داده ها بین دستگاه های مختلف ایجاد کرد . پروتکلی  وجود دارد که به طور خاص طراحی شده است تا سبکتر از پروتکل HTTP 1.1 باشد و در صورت اتصال شبکه های غیر قابل اعتماد ، عملکرد بهتری داشته باشد . MQ Telemetry Transport(MQTT) برای این کار مناسب تر است چراکه در آن اکثر دستگاه ها داده را از طریق اینترنت بین خود مبادله میکنند و باید کمترین پهنای باند شبکه را مصرف کنند .

پروتکل MQTT یک پروتکل اتصال ماشین به ماشین (M2M) و اینترنت اشیا است . MQTT یک پروتکل پیام رسان سبک است که با مکانیزم انتشار-اشتراک کار می کند و در بالای پروتکل کنترل انتقال / پروتکل اینترنت (TCP / IP) اجرا می شود .

نمودار زیر پروتکل MQTT را در بالای استک TCP / IP نشان می دهد :

MQTT نسبت به پروتکل HTTP 1.1 سبک تر است و بنابراین ، هر زمان که بخواهیم داده ها را بصورت Real Time با مدل انتشار-اشتراک ارسال و دریافت کنیم ، گزینه مناسبی است و به کمترین فوت پرینت ممکن نیاز داریم . MQTT در پروژه های IoT ، M2M و تعبیه شده بسیار محبوب است و همچنین در برنامه های تحت وب و برنامه های تلفن همراه که به پیامرسانی مطمئن و توزیع پیام نیاز دارند نیز استفاده میشود . MQTT برای دامنه های برنامه زیر که در آنها تبادل داده مورد نیاز است ، مناسب میباشد :

• ردیابی و مدیریت دارایی
• ردیابی شیمیایی
• نظارت بر محیط و ترافیک
• اتوماسیون Field force
• تست آتش و گاز
• اتوماسیون خانگی
• سرگرمی درون خودرو
• پزشکی
• پیام رسانی
• پایانه های فروش (POS)
• راه آهن
• شناسایی فرکانس رادیویی (RFID)
• کنترل نظارت و داده برداری (SCADA)

MQTT برای پشتیبانی مناسب از چالش های زیر در IoT، M2M ، برنامه های تعبیه شده و تلفن همراه طراحی شده است :

• سبک باشد تا امکان انتقال حجم زیادی از داده ها بدون هزینه های سنگین وجود داشته باشد .
• حداقل بسته های داده را در حجم عظیم توزیع کند .
• به راحتی داده ها را از یک کلاینت برای بسیاری از کلاینت ها ارسال کند .
• گوش دادن به رویدادها را هر زمان که اتفاق می افتد امکان پذیر کند . (معماری رویداد محور)
• از مدل های همیشه متصل و گاهی متصل پشتیبانی کند .
• اطلاعات را از طریق شبکه های غیر قابل اعتماد منتشر کند و اطلاعات قابل اعتماد ارائه دهد .
• با دستگاه های مجهز به باتری بسیار خوب کار کند و یا به مصرف برق کم نیاز داشته باشد .
• مدلی از پاسخگویی را فراهم کند که دستیابی به اطلاعات بصورت Real Time امکان پذیر باشد .
• امنیت و حریم خصوصی برای همه داده ها را ارائه دهد .
• بتواند مقیاس پذیری لازم را برای توزیع داده ها برای صدها هزار کلاینت فراهم کند .

کار با الگوی انتشار-اشتراک

قبل از اینکه به جزئیات MQTT بپردازیم باید الگوی انتشار-اشتراک را درک کنیم . در الگوی انتشار-اشتراک ، کلاینتی که پیام را منتشر می کند از کلاینت های دیگر که پیام را دریافت می کنند جدا می شود در نتیجه کلاینت ها از وجود سایر کلاینت ها اطلاع ندارند . یک کلاینت می تواند پیام هایی از یک نوع خاص را منتشر کند و فقط کلاینت هایی که به آن نوع خاص از پیام ها علاقه مند هستند پیام های منتشر شده را دریافت کنند .

الگوی انتشار-اشتراک به یک کارگزار احتیاج دارد که به آن سرور نیز می گویند . همه کلاینت ها با سرور ارتباط برقرار می کنند . کلاینتی که از طریق سرور پیامی ارسال می کند به عنوان ناشر شناخته می شود . سرور پیام های دریافتی را فیلتر کرده و میان کلاینت هایی که به آن نوع پیام دریافتی علاقه مند هستند توزیع می کند . کلاینت هایی که به عنوان علاقه مند به انواع خاصی از پیام ها در سرور ثبت نام می کنند ، به عنوان مشترک شناخته می شوند . از این رو ، ناشران و مشترکین با سرور ارتباط برقرار می کنند .

با یک نمودار ساده نحوه کار بخش های مختلف مشخص میشود . نمودار زیر یک ناشر و دو مشترک متصل به سرور را نشان می دهد :

یک برد Raspberry Pi 3 با سنسور ارتفاع که به آن وصل میباشد ناشری است که با سرور ارتباط برقرار می کند . تلفن هوشمند iOS و تبلت اندروید دو مشترک هستند که با سرور ارتباط برقرار می کنند.

تلفن هوشمند iOS و تبلت اندروید به سرور نشان می دهند که می خواهند برای همه پیام های متعلق به موضوع سنسور ۱ / ارتفاع را مشترک شوند . از این رو ، هر دو تلفن هوشمند iOS و تبلت Android در موضوع sensor1 / altitude مشترک هستند . سرور پیام را به دو کلاینت مشترک در موضوع sensor1 / altitude توزیع می کند : تلفن هوشمند iOS و تبلت Android .

برد Raspberry Pi 3 پیامی را با ۱۰۰ فوت بار و سنسور ۱ / ارتفاع به عنوان موضوع منتشر می کند . برد که نقش ناشر را دارد درخواست انتشار را برای سرور ارسال می کند .

سرور پیام را به دو کلاینت مشترک شده در موضوع سنسور ۱ / ارتفاع توزیع می کند : تلفن هوشمند iOS و تبلت Android .

ناشران و مشترکان یکدیگر را نمی شناسند و آنها مجبور نیستند همزمان کار کنند ، ناشر می تواند پیامی را منتشر کند و مشترک بعدا آن را دریافت کند . علاوه بر این ، عملیات انتشار با عملیات دریافت هماهنگ نیست . ناشری از سرور درخواست می کند تا پیامی را منتشر کند و کلاینت ها مختلفی که در موضوع مورد نظر مشترک شده اند می توانند پیام را در زمان های مختلف دریافت کنند . ناشر می تواند برای جلوگیری از مسدود شدن تا زمانی که کلاینت پیام ها را دریافت کند ، پیام ها را به صورت یک عملیات ناهمزمان ارسال می کند .

ناشری که نیاز به ارسال پیام به صدها کلاینت دارد ، می تواند این کار را با یک عملیات انتشار به سرور انجام دهد . سرور وظیفه ارسال پیام منتشر شده برای کلیه کلاینت هایی که در موضوع موردنظر مشترک شده اند ، دارد . از آنجا که ناشران و مشترکان از هم جدا شده اند ، ناشر نمی داند مشترکی وجود دارد که به پیام هایی که می خواهد ارسال کند گوش دهد یا نه . از این رو ، گاهی لازم است مشترک به ناشر تبدیل شود و پیامی را منتشر کند که نشان می دهد پیامی را دریافت و پردازش کرده است . نیازهای خاص به نوع راه حل ما بستگی دارد .

کار با فیلترینگ پیام

سرور باید اطمینان حاصل کند که مشترکان فقط پیام های موردنظر خود را دریافت می کنند . فیلتر کردن پیام ها بر اساس معیارهای مختلف در الگوی انتشار-اشتراک امکان پذیر است . ما بر روی آنالیز فیلترینگ مبتنی بر موضوع تمرکز خواهیم کرد .

در نظر بگیرید که هر پیام متعلق به یک موضوع است . وقتی ناشر از سرور درخواست انتشار پیام می کند ، باید موضوع و پیام را مشخص کند . سرور پیام را دریافت می کند و آن را به همه کلاینت هایی که در آن موضوع مشترک شده اند ، ارسال می کند .

سرور برای تحویل پیام به مشترکان مربوطه نیازی به بررسی میزان payload  ندارد . فقط باید موضوع مربوط به هر پیامی را که رسیده است و باید فیلتر شود را قبل از انتشار بررسی کند .

مشترک می تواند در بیش از یک موضوع مشترک شود . در این حالت ، سرور باید اطمینان حاصل کند که مشترک پیام هایی را که متعلق به همه موضوعاتی است که مشترک شده است ، دریافت می کند .

نمودار زیر دو ناشر آینده را نشان می دهد که هنوز هیچ پیامی منتشر نکرده اند ، یک سرور و دو مشترک متصل به سرور :

یک برد Raspberry Pi 3 با سنسور ارتفاع وصل شده به آن و یک برد Intel Edison با یک سنسور دما که به آن وصل شده است ، دو ناشر خواهند بود . یک تلفن هوشمند iOS و یک تبلت اندروید دو مشترک هستند که با سرور ارتباط برقرار می کنند.

بیشتر بدانید : بردهای توسعه به طراحی اینترنت اشیا کمک میکنند

تلفن هوشمند iOS به سرور نشان می دهد که می خواهد همه پیام های متعلق به موضوع سنسور ۱ / ارتفاع را مشترک شود . تبلت Android به سرور نشان می دهد که می خواهد همه پیام هایی را که متعلق به هر یک از دو موضوع زیر است مشترک شود : سنسور ۱ / ارتفاع و سنسور ۴۲ / دما . از این رو ، تبلت اندروید در دو موضوع مشترک است در حالی که تلفن هوشمند iOS فقط در یک موضوع مشترک است .

نمودار زیر نشان می دهد که پس از اتصال و انتشار پیام با موضوعات مختلف از طریق سرور توسط دو ناشر چه اتفاقی می افتد:

برد Raspberry Pi 3 پیامی را با ۱۲۰ فوت بار و حسگر ۱ / ارتفاع به عنوان موضوع منتشر می کند . برد که ناشر است درخواست انتشار را برای سرور ارسال می کند . سرور پیام را به دو کلاینت مشترک در موضوع sensor1 / altitude توزیع می کند : تلفن هوشمند iOS و تبلت Android .

برد اینتل ادیسون پیامی را با ۷۵ F به عنوان بار و حسگر ۴۲ / دما به عنوان موضوع منتشر می کند . برد که همان ناشر  است درخواست انتشار را برای سرور ارسال می کند . سرور پیام را به تنها کلاینت که در موضوع sensor42 / temperature مشترک است توزیع می کند :  Android Tablet . بنابراین ، تبلت اندروید دو پیام دریافت می کند .