يعد بروتوكول MQTT واحداً من أكثر بروتوكولات إنترنت الأشياء انتشاراً واعتماداً، وقد جعل التصميم المبسّط وخفّة هذا البروتوكولات منه حلّا مناسباً للأجهزة المضمّنة ذات الموارد المحدودة واللامحدودة على حدٍّ سواء في مجال قدرة المعالجة والتخزين. يقدم البروتوكول فوائد تقلّل من استهلاك الطاقة وسعة الشبكة bandwidth وهذين عاملين مهمين جداً في أجهزة إنترنت الأشياء وهذا ما تؤكده بشدّة أرقام تقرير رائع من ستيفن نيكولاس. سنلقي في هذا المقال نظرة عن قرب عن هذا البروتوكول وسنقوم بتجربته على الجهاز المحلي localhost.
MQTT ببساطة
إن MQTT أو Message Queuing Telemetry Transport هو ” بروتوكول نقل رسائل بين مخدّم وزبون Client Server بنمط ناشر/مشترك publish/subscribe . هو بروتوكول خفيف ،ومفتوح ،ومصمّم بحيث يسهل تنفيذه”. هذا تبعاً للتعريف الرسمي، وهو مصمّم خصياً لسياق تطبيقات إنترنت الأشياء بالبيئات محدودة الموارد resources في مجال الطاقة وتبادل البيانات وذواكر التخزين.
لبروتوكول الـMQTT أجزاء أساسيّة ثلاثة: المخدّم broker ،و الناشر publisher ،والمشترك subscriber.
- يعد المخدّم أو ما يسمى broker مسؤولاً عن إدارة الشبكة من العملاء clients والذين هم مزيج من الناشرين والمشتركين.
- الناشر هو الجهاز الذي يقوم بإرسال الرسائل (نشر) إلى المخدّم. هذه الرسائل معنونة بعنوان/موضوع topic.
- المشترك هو الجهاز الذي يستمع لموضوع أو مواضيع معيّنة.
ليس هناك اتصال مباشر بين المشترك والناشر وإنما وببساطة يقوم المشترك بإخبار المخدّم أنه مهتم بمواضيع محدّدة ويهتم بعد ذلك المخدّم broker بإرسال الرسائل إلى المشتركين عند توفرها. إن نموذج الناشر/مشترك مختلف تماماً عن نموذج الطلب/رد request/response المتبع في بروتوكول الـHTTP وهذا يسمح بنمط نقل واحد-لعدّة one-to-many.
يمكن تشبيه الموضوع topic بوسم خاص بكل رسالة، ويمكن أن يكون وحيد الطبقة أو متعدد الطبقات multi-level تُفصل كل طبقة بـ(/) (مثال: rooms/room1/sensors/temp). يسمح هذا بتقسيم منطقي جيد للمعطيات.
يجب على كل جهاز يرغب باستقبال الرسائل بموضوع معين أن “يشترك” به وذلك بإخبار المخدّم. يمكن للاشتراك أن يكون بموضوع محدد أن نمط معين pattern. ولتحقيق هذا يُستخدم إشارات wildcards وهما (+ و #)
- تعني إشارة الـ’+’ الاشتراك بكل المواضيع في تلك الطبقة. مثال: تعني rooms/+/sensors/temp أن يتم الاشتراك في حساسات الحرارة الخاصة بكل الغرف.
- تعني إشارة الـ’#’ الاشتراك بكل المواضيع في تلك الطبقة والطبقات اللاحقة. مثال: rooms/room1/# وهذا يعني الاشتراك في كل ما يتعلق بالغرفة الأولى.
إن بروتوكول الـMQTT يعمل بالاعتماد على TCP/IP، وعلى خلاف الـHTTP هو بروتوكول binary وليس بروتوكول ASCII، حيث تُستخدم بت/بتات للتحكم بمزايا البروتوكول بينما بروتوكولات ASCII تستخدم المحارف، وبالنتيجة تستهلك بروتوكولات الـbinary كمية نقل بيانات أقل من الشبكة.
إن بروتوكول الـMQTT قد صُمّم للبيئات محدودة الموارد وخاصة مورد النفاذ للشبكة، وبالتالي هناك خيارات في البروتوكول تتعلّق بتوصيل الرسالة بين المخدّم والعميل. إن QoS أو Quality of Service هو المصطلح لـ3 خيارات بخصوص هذا الشأن:
- المستوى 0 (QoS = 0) توصيل الرسالة مرة واحدة في أفضل حالة. هذا يعني في حال المشترك لم يستلم الرسالة فإن المخدّم لن يقوم بإرسالها مرة أخرى، حيث لا يتوقع المخدّم تأكيد acknowledgment من طرف المشترك حول وصول الرسالة.
- المستوى 1 (QoS = 1) توصيل الرسالة على الأقل مرة واحدة.هذا يعني أن المخدّم يستمر بإرسال الرسالة إلى أن يقوم المشترك باستلام الرسالة ويرسل تأكيد باستلامها acknowledgment هذا قد يؤدي إلى وصول الرسالة أكثر من مرة إلى المشترك.
- المستوى 2 (QoS =2) توصيل الرسالة مرّة واحدة لزوماً. هذا يعني أن الرسالة يجب أن تصل لمرة واحدة ودون تكرار إلى المشترك.
لكن ماذا لو لم يكن المشترك متصل أساساً؟ هل ستضيع الرسائل أم ستصله عندما يتصل مرة أخرى؟ الجواب: هذا ” الأمر يعتمد على الإعدادات”. إذا تم ضبط الإعدادات بحيث يبدأ الاتصال بجلسة اتصال نظيفة “Clean Session”فإن المخدّم سيتجاهل الرسائل القديمة ويبدأ جلسة جديدة، بينما لو تم تعطيل هذه الخاصية وذلك بتصفير بت موجود في رزمة packet طلب الاتصال بين المستخدم والمخدّم، فإن المخدّم سيرسل الرسائل المتراكمة ذات الجودة QoS 1 و QoS 2 إلى المشتركين التي حدثت أثناء انقطاعهم.
تتوفر ميزات أخرى مثل الرسالة المحفوظة retained message والوصيّة الأخيرة last will وهذا ما سنناقشه في الفقرة القادمة. يكفي أن نعرف الآن أن الرسالة المحفوظة هي رسالة تُرسل إلى كل مشترك فور اشتراكه وهي مميّزة على مستوى كل موضوع على حدى، وأما الوصيّة الأخيرة فهي رسالة يتم ارسالها ونشرها باسم موضوع معيّن وذلك عندما يكتشف المخدّم أنه قد فقد الاتصال بالمستخدم وهذه الرسالة مميزة على مستوى المستخدم (المميّز برقم ID) ولها اسم موضوع محدّد.
تجريب MQTT
سوف نستخدم البرمجية Eclipse Mosquitto لتجريب MQTT وتتوفر البرمجيّة لكثير من المنصّات. بداية قم بتنزيل وبتنصيب البرمجية. هناك خطوات إضافية لجعل البرمجية تعمل على ويندوز 10. يرجى اتباع الخطوات من المصدر في Medium.
قم بتشغيل المخدّم من خلال تنفيذ التعليمة mosquitto على جهازك. يمكنك التحقق من رؤية البورت 1883 في القائمة في خرج تنفيذ التعليمة netstat -an (و هو رقم بورت الـMQTT).
والآن، قم بتشغيل نافذتين CMD (للويندور) أو طرفيتين terminal (لينكس). واحدة من أجل النشر والأخرى من أجل الاشتراك والحصول على الرسائل.
Publisher/Subscriber بسيط
توفّر البرمجية Eclipse Mosquitto تعليمتين وهما mosquitto_pub و mosquitto_sub وتستخدمان للنشر والاشتراك.
لنستخدم أولاً التعليمة التالية للاشتراك بالموضوع “rooms/room1/sensors/temp”:
mosquitto_sub -t rooms/room1/sensors/temp
ولنستخدم الواجهة الثانية للاشتراك في الموضوع نفسه. ‘-m’ تحدد محتوى الرسالة.
mosquitto_pub -t rooms/room1/sensors/temp -m 25
QoS & Clean Session
لنجرب الآن عندما يدخل الـQoS إلى الخط، ولكن علينا أولاً تحديد ID للمستخدم وذلك عبر الخيار ‘i-‘، بحيث يتم حفظ الجلسة للمستخدم برقم ID محدد ومعروف، والأمر هو إضافة الخيار ‘c-‘ والذي يقوم بتعطيل خيار ‘clean session’.
بعد أن يكون المستخدم ID=2 بحالة فصل، يقوم الناشر بنشر 3 رسائل ونلاحظ أن المستخدم يستقبل الرسائل كلها فور اتصاله مجدّداً. إن الرسائل الـ3 لها سوية QoS =2 وذلك باستخدام الخيار ‘q-‘ لتحديد السويّة.
لنجرّب الآن إرسال 3 رسائل (21 و 22 و 23) بنفس السناريو السابق ولكن بوجود رسالة واحدة ذات سوية خدمة أعلى من الصفر والباقي صفر.
Retained Message and Last Will
إن الرسائل المحفوظة هي رسائل يتم إرسالها لكل مشترك جديد لكل موضوع على حدى. مثال: من أجل الموضوع ‘rooms/room1/sensors/temp’، إذا تعطل حساس الحرارة وتوقف عن العمل بشكل جيد لسبب ما، فإن ارسال قيمة NaN لكل مشترك جديد ستكون مفيدة لمعرفة أن الحساس لا يعمل. يمكن تحديد هذه الرسالة كرسالة محفوظة وذلك باستخدام الخيار ‘r-‘.
ستصل الرسالة ‘NaN’ لكل مشترك جديد في الموضوع حتى لو تم تفعيل خاصية ‘clean session’.
نجد بالعودة إلى بتات البروتوكول أن خاصية retained message أنها محدّدة ببت في ترويسة publish packet.
ماذا لو قام أحد بفصل الجهاز والتلاعب به بشكل غير مسموح به؟ كيف سيعلم المشتركين بذلك؟ هنا يأتي دور الوصيّة الأخيرة. حيث سيتم إرسال رسالة لكل المشتركين عبر اسم موضوع محدّد ويُعرف من قبل المستخدم بمحتوى يدل على ذلك.
يمكن التعرف بشكل معمّق أكثر وتنقيح مراحل ارسال/استقبال الرسائل عبر تفعيل الـdebugging من خلال الخيار ‘d-‘.
أخيراً، يمكن الاطلاع على التوثيق للخيارات التي تتيحها التعليمتين mosquitto_sub و mosquitto_pub وذلك لتجربة ميزات أخرى من البروتوكول.
المراجع ولمزيد من القراءة
يعد الاطلاع على التوصيف الرسمي للبروتوكول أمر أساسي ذو أولويّة بعد هذه المقدّمة، كما يمكن الاطلاع على سلسلة الدروس HiveMQ – MQTT essentials والورقة Tutorial: MQTT (Message Queuing Telemetry Transport) أيضاً. يعد الكتاب Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry مرجع جيّد للقراءة عن البروتوكول. أخيراً وليس آخراً يمكن التبحّر أكثر عن الأمان المتاح عبر البروتوكول باستخدام MQTT مع TLS وأيضاً استخدام MQTT عبر Websockets وأيضاً البحث عن مكتبة للبروتوكول مناسبة في حال كنت تريد استخدام البروتوكول في جهاز مضّمن.
سوف نرى في مقال لاحق كيفية استخدام الـESP32 مع الـMQTT وسيرفر خارجي.
