MQTT چیست؟ (معرفی و بررسی پروتکل MQTT)

پروتکل MQTT چیست؟

پروتکل MQTT یکی از مهم ترین و پرکاربردترین پروتکل ها در حوزه اینترنت اشیا بشمار می رود.

طبق آمارهای داده شده در سال 2018 MًQTT پر استفاده ترین پروتکل در اینترنت اشیا می باشد. اما نکته جالب در ارتباط MQTT این است که تنها پروتکلی می باشد که از سال های 2016 تا 2018 روندی روبه روشد را داشته است. در این آمار سایر پروتکل های دیگر یک روندی سینوسی را تجربه کرده اند. پروتکل های HTTP, Websocket, Coap و AMQP در رتبه های بعدی این آمار قرار داشته اند.

اما اگر بیشتر در ارتباط با MQTT صحبت کنیم باید گفت که MQTT یک پروتکل M2M یا machine to machine است. ارتباط این پروتکل بر اساس ارتباطات کلاینت سروری می باشد و همچنین در لایه شبکه یا Network قرار دارد. MQTT پروتکلی است که بر روی پروتکل TCP کار می کند و برای شبکه هایی بر روی TCP کار می کند مناسب می باشد.

ورژن دیگری از MQTT وجود دارد که برای شبکه های UDP مناسب است.

معماری MQTT :

MQTT از مدل Publish/Subscrib برای ارتباط خود استفاده می کند.

به این صورت که هر دیوایس یا سنسور در این پروتکل اطلاعات خود را به سرور MQTT که در اینجا یک Broker است، Publish می کند به عنوان مثال یک سنسور دما اطلاعات خود را با استفاده از یک topic خاص تحت عنوان Tempmohit بر روی سرور Publish می کند، در اینجا هر کسی که بخواهد به این اطلاعات دسترسی داشته باشد یا به اصطلاح Subscrib کند، باید آن Topic خاص را که در اینجا Tempmohit است، داشته باشد تا بتواند اطلاعات را از سرور دریافت کند. در واقع دستگاه های یا Client ها در MQTT هم می توانند Publisher و هم Subscriber باشند.

در MQTT محدودیتی برای تعداد Topic ها وجود ندارد. همچنین هر دستگاه می تواند داده های خود را در چند Topic مختلف قرار دهد. با یک مثال ساده تر می توانید این موضوع را درک کنید.

در اینجا ما یک سنسور نور داریم که میخواهیم اطلاعات آن را Publish کنیم.

می توانیم از Topic های lightswitch یا Sensors1 استفاده کنیم.

شما می توانید از Topic زیر برای وضعیت خاموش یا روشن شدن دستگاه استفاده کنید.

lightswitch/Status

یک مثال از دریافت اطلاعات یک سنسور دما در یک خانه:

Sensor/temp/home/bedrome

.این تاپیک اطلاعات سنسور های نصب شده در اتاق خواب خانه را نشان می دهد

Sensor/temp/home/#

این تاپیک اطلاعات تمام سنسور های نصب شده در خانه را به ما می دهد در واقع می توان میانگین دمای خانه را محاسبه کرد.

با استفاده از “/” می توان ساختار درختی به Topic داد.

همچنین با استفاده از “#” می توان تمام زیر topic های مربوط را از Broker دریافت کرد.

و در نهایت از “+” هم برای دیدن تمام سنسور های موجود استفاده می کنیم.

مفهوم QOS در MQTT :

مفهوم QOS به معنی مدیریت ارسال اطلاعات در شبکه است.

با استفاده از این می توان سرعت انتقال داده ها، زمان ارسال اطلاعات، حجم ارسال اطلاعات، نحوه ی ارسال اطلاعات و … را کنترل کرد.

MQTT دارای سه نوع Qos است:

Qos0 :

ساده ترین حالت برقراری ارتباط در MQTT با Broker همین حالت می باشد.

در Qos0 دستگاه Publisher که اطلاعات را به Broker ارسال می کند هیچ نیازی به Ack (تائید) ندارد.

بنابراین هیچ اهمیتی ندارد که پیام به Broker رسیده باشد یا خیر، همین که در Qos0 دستگاه Publisher بتواند Ack مربوط به شبکه TCP را دریافت کند فرض به دریافت اطلاعات از طرف Broker می کند. در این روش اگر ارتباط قطع شود و هنوز اطلاعات به آن دستگاه نرسیده باشد، بخشی از اطلاعات هیچ گاه به Broker نمی رسد.

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

Qos1

در این روش دستگاه مطمئن می شود که حداقل یک بار پیام توسط سرور دریافت می شود.

به این صورت که Broker پس از دریافت پیام، یک پیام Puback به دستگاه Publisher ارسال می کند. سپس دستگاه پس از دریافت Puback مطمئن می شود که پیام به Broker رسیده است و پیام را از صف ارسال خارج می کند. اگر به هر دلیلی پیام Puback ارسال نشود دستگاه دوباره پیام را ارسال خواهد کرد تا زمانی که پیام Puback دریافت شود. اما اگر پیام دوباره ارسال شود، Publisher یک Flag تکراری (DUP) ایجاد می کند.

در Qos1 این پرچم تنها برای اهداف داخلی استفاده می شود.

در هر بسته Publisher یک PachID یا شناسه بسته استفاده می شود تا بسته Publish شده را با Puback مطابقت دهد.

هر کدام از Puback ها نیز یک PackID دارند.

Qos2 :

این حالت مطمئن ترین و امن ترین حالت ارسال پیام و البته کندترین حالت در MQTT است.

در این Qos فرستنده یا Publisher مطمئن می شود که تنها یک بار پیام توسط Sunscriber ها دریافت شود. در Qos2 از دو پیام req/resp بین Sender و Reciver برای اطمینان از ارسال و دریافت پیام استفاده می شود. فرستنده و گیرنده از شناسه بسته اصلی (Publish) برای هماهنگی و تحویل پیام استفاده می کنند. روال کار به این شکل است که وقتی گیرنده یک بسته (به طور پیش فرض Broker) پیام Publish شده را از Publisher دریافت می کند، پیام دریافت شده پس از پردازش توسط Broker با ارسال یک پیام pubrec که برای تائید یک Publish است تائید می شود. هنگامی که فرستنده یک بسته pubrec دریافت می کند publisher می تواند با خیال بسته اولیه Publish را حذف کند. Publisher بسته Pubrec را که Broker دریافت کرده، ذخیره می کند و با یک بسته Pubrel پاسخ می دهد.

پس از این که Broker پیام Pubrel را دریافت کرد می تواند تمام پیام ها و حالت های ذخیره شده را حذف کند و با یک بسته Pubcomp پاسخ بدهد.

Publisher هم پس از دریافت Pubcomp می تواند تمام پیام ها را حذف کند.

بسته های ارسالی در MQTT :

بسته ارسالی Client به Broker :

به بسته های ارسالی از سمت Client به Broker برای ارتباط و ارسال اطلاعات Connect گفته می شود.

یک بسته که از کلاینت به سمت Broker می رود شامل اطلاعات زیر است.

• Client ID: هر کلاینت دارای یک ID می باشد که در این بخش نشان داده می شود.
• Cleansession: اگر مقدار Cleansession در بالا برابر False باشد سرور داده ها را کش کرده و اگر کلاینتی دوباره متصل شود اطلاعات قدیمی و کش شده را دریافت خواهد کرد.
• Username: نام کاربری هر کلاینت است که برای Login استفاده می شود.
• Password: رمز هر کلاینت که برای Login استفاده می شود.
• Lastwilltopic: تاپیکی است که کلاینت اطلاعات خود را بر روی آن قرار داده است. کلاینت از آن برای نمایش اطلاعات استفاده می کند.
• LastwillQos: این پارامتر مقدار Qos را نشان میدهد.
• Lastwillmassage: این پیام در صورت قطع اتصال کلاینت با Broker و قطع Willtopic به صورت اتفاقی و غیره منتظره ارسال می شود.
• LastwillRetain: زمانی که برابر با False باشد Willmasasge حفظ نمی شود، اگر هم برابر True باشد این پیام حفظ می شود.
• KeepAlive: این مقدار مدت زمانی که Client و broker می توانند بدون ارسال هیچ پیامی ارتباط خود را حفظ کنند را نشان میدهد.

بسته ارسالی Broker به سمت Client :

به بسته های ارسالی از سمت Broker به Client بسته Connack گفته می شود.

جدول زیر هم جوابی است که Broker به کلاینت ارسال می کند.

Session Present: ای مقدار نشان دهنده این است که آیا Broker قبلا با Client داشته یا نه.

اگر Client به Broker با استفاده از CleanSession که بر روی True تنظیم شده است وصل شود مقدار Session Present همیشه False است. زیرا Cleansession کل اطلاعات اتصال فعلی را از بین خواهد برد. اما اگر Client با استفاده از Cleansession که مقدار آن برابر False است با Broker ارتباط برقرار کند، در این صورت دو حالت به وجود می آید. حالت اول به این صورت است که اگر اطلاعاتی از Session برای آن ClientID موجود باشد مقدار Session Present برابر با True خواهد شد.

اما حالت دوم به این صورت است که Broker هیچ اطلاعاتی از این ClientID ندارد.

در آن صورت این مقدار False خواهد بود.

این حالت در در نسخه MQTT 3.1.1 اضافه شده است. این حالت نشان می دهد آیا Client نیاز به عضویت در مباحث و تاپیک های جدید دارد یا خیر و یا بداند آیا هنوز موضوعات در یک جلسه ذخیره می شوند یا نمی شوند.

Ruturn Code: این مقدار نشان میدهد که آیا اتصال بین سرور و کلاینت موفقیت آمیز بوده یا خیر، که خود دارای مقادیر مختلف است.

جدول زیر نشان دهنده این است که هر عدد چه جوابی را نشان می دهد.

Return code response	Return code
اتصال برقرار شد.	0
اتصال رد شد، نسخه پروتکل غیر قابل قبول است.	1
اتصال رد شد، شناسه اشتباه است.	2