MQTT در سال 1999 توسط مهندسان Andy Stanford-Clark و Arlen Nipper ابداع شد ، به عنوان روشی برای برقراری ارتباط خطوط لوله در صنعت نفت و گاز با سیستم های نظارت و دستیابی به داده ها (SCADA).
هدف داشتن پروتكل کارآمد برای پهناي باند ، سبك و مصرف کم باتری بود ، زيرا دستگاه ها از طريق اتصالات ماهواره اي متصل بودند كه در آن زمان بسيار گران بود. این سیستم ها از پروتکل های انحصاری و متفاوت استفاده می کردند و به همین ترتیب قادر به برقراری ارتباط با یکدیگر نبودند. افزودن یکسری قابلیت ها به MQTT به برقراری ارتباط بین دستگاه ها کمک می کند.
MQTT یک پروتکل M2M یا machine to machine است. ارتباط این پروتکل بر اساس ارتباطات کلاینت سروری می باشد و همچنین در لایه شبکه یا Network قرار دارد. MQTT پروتکلی است که بر روی پروتکل TCP کار می کند و برای شبکه هایی که بر روی TCP کار می کند مناسب می باشد.
ورژن دیگری از MQTT وجود دارد که برای شبکه های UDP مناسب است.
در این قسمت به درک درستی از اینکه MQTT چطور کار می کند می رسیم و در قسمت های بعدی با topic ها در MQTT و همچنین فرآیند انتشار و سابسکرایب در MQTT آشنا خواهیم شد و در آخر یک مثال عملی برای استفاده از بروکر Mosquitto و پیاده سازی کلاینت ها برای ارسال و دریافت پیام خواهیم داشت.
کلاینت های MQTT بسیار کوچک هستند ، به حداقل منابع نیاز دارند تا بتوان از آنها در میکروکنترلرهای کوچک استفاده کرد. هدرهای پیام MQTT برای بهینه سازی پهنای باند شبکه کوچک هستند.
امکان پیام رسانی بین دستگاه به cloud و cloud به دستگاه را فراهم می کند. این امر باعث می شود پیام ها به راحتی بین گروهی از کلاینت ها توزیع شود.
MQTT می تواند برای ارتباط با میلیون ها دستگاه اینترنت اشیا استفاده شود.
قابلیت اطمینان در ارسال پیام برای بسیاری از یوزکیس های اینترنت اشیا مهم است. به همین دلیل است که MQTT دارای 3 سطح کیفیت خدمات تعریف شده است: 0 - حداکثر یک بار ، 1- حداقل یک بار ، 2 - دقیقاً یک بار
بسیاری از دستگاه های اینترنت اشیا از طریق شبکه های تلفن همراه غیر قابل اطمینان متصل می شوند. پشتیبانی MQTT از ارتباط مداوم زمان اتصال مجدد مشتری با بروکر را کاهش می دهد.
MQTT از رمزگذاری پیام با استفاده از TLS و احراز هویت سرویس گیرنده با استفاده از پروتکل های مدرن احراز هویت ، مانند OAuth استفاده می کند.
MQTT یک پروتکل ارسال پیام است که برای فرستادن پیام بکار می رود و از مدل publish/subscribe استفاده می کند
این مدل امکان ارسال پیام به یک یا چندین کلاینت را فراهم می سازد.
برای مثال در تلویزیون، پخش کننده تلویزیونی با استفاده از یک کانال خاص یک برنامه تلویزیونی را پخش می کند و بیننده برای دیدن برنامه به این کانال ملحق می شود. در اینجا ارتباط مستقیمی بین پخش کننده و بیننده وجود ندارد.
در MQTT انتشاردهنده پیام(publisher) یک پیام را روی یک موضوع(topic ) منتشر می کند و دریافت کننده پیام (subscriber) با اشتراک در آن تاپیک می تواند پیام را دریافت کند.
MQTT به یک بروکر مرکزی همانطور که در شکل زیر نشان داده شده نیاز دارد.
برای برقراری ارتباط در MQTT از TCP/IP استفاده می شود. TCP گارانتی می کند که بسته ها به ترتیب دریافت شوند. ارتباط TCP/IP مانند ارتباط تلفن هست. وقتی ارتباط تلفن برقرار شد شما می توانید حرف بزنید تا اینکه یکی از طرفین قطع شود. اغلب کلاینت های MQTT به بروکر وصل می شوند تا وقتی که آنها نخواهند پیامی ارسال کنند.
هیچ انتشار و اشتراک پیامی انجام نمی شود مگر اینکه ارتباط برقرار شود.
برای برقراری ارتباط در MQTT از TCP/IP استفاده می شود که یک ارتباط یک طرفه باز است که کلاینت در هر زمانی می تواند پیام ارسال یا دریافت کند ولی اگر در طول یک زمان مشخصی هیچ پیامی دریافت نشود کلاینت یک PINGREQ ایجاد میکند و انتظار یک PINGRESP از بروکر دارد. این تبادل پیغام تصدیق می کند که ارتباط همچنان برقرار است به این طول زمان مشخص شده keep alive period گفته می شود.
کلاینت ها یک پیام keepalive در هر 60 ثانیه به بروکر ارسال می کنند که اطلاع دهند هنوز ارتباط برقرار است. در حقیقت Keep Alive یه بازه زمانی هست که به ثانیه تعریف می شود و با 16بیت توصیف می شود.حالت پیش فرض 60ثانیه هست ولی هر تایمی می توان تنظیم کرد.
connect(host, port=1883, keepalive=60, bind_address=””)
همه کلاینت ها باید client name یا ID داشته باشند. client name توسط بروکر برای شناسایی سابسکرایب ها بکار می رود. client name باید یکتا باشد. اگر شما سعی کنید با یک client name تکراری به بروکر وصل شوید ارتباط کلاینت قبلی که با این نام وصل شده٬ قطع می شود.حال به دلیل اینکه کلاینت هایی که قطع می شوند سعی در اتصال مجدد دارند و این حلقه قطع و وصل ادامه می یابد
کلاینت ها ارتباط Clean Sessions را با بروکر برقرار می کنند. در Clean Sessions وقتی یک کلاینت قطع می شود٬ بروکر هیچ اطلاعاتی را نگهداری نمی کند. در یک ارتباط non clean session بروکر سابسکرایب های انجام شده توسط کلاینت و پیام هایی که به کلاینت تحویل داده نشده است را نگهداری می کند.
البته این بستگی به مقدار Quality of service دارد وقتی اشتراک یا انتشاری بر روی یک تاپیک انجام می شود٬ تنظیم می شود٬ که در بخش بعدی در این مورد بحث خواهیم کرد.
ایده Last Will Messages این است که به مشترک اطلاع داده شود که انتشار دهنده پیام در شبکه در دسترس نیست. Last Will Messages توسط کلاینت انتشاردهنده پیام تنظیم می شود و هر تاپیک می تواند مقدار خودش را داشته باشد. این پیام در بروکر ذخیره می شود و اگر ارتباط با انتشاردهنده پیام ناموفق باشد این پیغام به مشترک ها ارسال می شود.
منبع: http://www.steves-internet-guide.com/mqtt-works/
