MQTT هو بروتوكول مراسلة خفيف صُمم للاتصال الفعال بين الأجهزة والتطبيقات والمستشعرات والبوابات ومنصات السحابة وأنظمة التحكم. يُستخدم على نطاق واسع في شبكات إنترنت الأشياء، وأنظمة القياس عن بعد، والمباني الذكية، والمراقبة الصناعية، ومنصات المركبات، وأنظمة الطاقة، وأتمتة المنازل، وإدارة المعدات عن بُعد، والتطبيقات المحمولة حيث قد تكون سعة النطاق أو الطاقة أو استقرار الشبكة محدودة.

يعتمد البروتوكول على نموذج النشر/الاشتراك. فبدلاً من أن يرسل جهاز البيانات مباشرة إلى جهاز آخر، تُرسل الرسائل إلى وسيط. بعد ذلك يوزع الوسيط هذه الرسائل على العملاء الذين اشتركوا في الموضوعات المطابقة. تجعل هذه البنية الاتصال مرناً وقابلاً للتوسع ومناسباً للأنظمة التي تضم عدداً كبيراً من الأجهزة التي لا تحتاج إلى معرفة عناوين الشبكة الخاصة ببعضها.

طريقة مختلفة لفهم مراسلة الأجهزة

تعمل اتصالات العميل والخادم التقليدية غالباً كطلب مباشر واستجابة مباشرة. يطلب عميل واحد معلومات من خادم، ويرد الخادم. أما MQTT فيتبع فكرة مختلفة. يستطيع الجهاز نشر رسالة دون معرفة من سيتلقاها، بينما يستطيع جهاز آخر الاشتراك في موضوع دون معرفة من سينشر فيه.

هذا الفصل مفيد في الأنظمة الموزعة الكبيرة. فمستشعر الحرارة لا يحتاج إلى معرفة أي لوحة معلومات أو قاعدة بيانات أو تطبيق محمول أو قاعدة أتمتة ستستخدم بياناته. عليه فقط أن ينشر في موضوع محدد، ويتولى الوسيط عملية التوزيع.

والنتيجة هي نمط اتصال يقلل الترابط الشديد بين الأجهزة. يمكن للأنظمة إضافة مشتركين جدد من دون تعديل المستشعر. ويمكنها أيضاً إضافة ناشرين جدد من دون إعادة كتابة كل تطبيق. وهذا أحد أسباب انتشار البروتوكول في تصميم إنترنت الأشياء والقياس عن بعد.

الوسيط كمركز للرسائل

الوسيط هو المكوّن المركزي في البنية. فهو يقبل اتصالات العملاء، ويصادق العملاء عند الحاجة، ويستقبل الرسائل المنشورة، ويطابق الموضوعات مع الاشتراكات، ثم يمرر الرسائل إلى المشتركين الصحيحين.

قد يعمل الوسيط على منصة سحابية أو خادم خاص أو بوابة طرفية أو حاسوب صناعي أو جهاز مدمج أو خدمة مراسلة مُدارة. في النشر الصغير قد يتعامل وسيط واحد مع كل الحركة. وفي النشر الأكبر يمكن تجميع عدة وسطاء أو ربطهم أو موازنة حملهم أو توزيعهم عبر مناطق مختلفة.

يتحكم الوسيط أيضاً في كثير من السلوكيات التشغيلية، مثل حالة الجلسة، والرسائل المحتفَظ بها، والتحكم في الوصول، وتسليم جودة الخدمة، ومهلة keepalive، وحدود الاتصال، وتفويض الموضوعات، واستمرارية الرسائل. لذلك يؤثر تصميم الوسيط مباشرة في الموثوقية وقابلية التوسع والأمان.

دورة حياة الاتصال

ينشئ العميل جلسة

يفتح العميل أولاً اتصالاً شبكياً مع الوسيط. يعمل MQTT غالباً فوق TCP، وتستخدم عمليات النشر الآمنة عادةً تشفير TLS. بعد إنشاء اتصال النقل، يرسل العميل حزمة CONNECT تحتوي على معلومات مثل معرّف العميل وبيانات المصادقة وقيمة keepalive وسلوك الجلسة وإعدادات رسالة الوصية الاختيارية.

يفحص الوسيط طلب الاتصال ويرد بحزمة CONNACK. إذا قُبل الاتصال، يستطيع العميل بدء النشر والاشتراك وإلغاء الاشتراك واستقبال الرسائل. وإذا رُفض الاتصال، يقدم الوسيط سبباً وفق إصدار البروتوكول والإعدادات.

النبض يحافظ على بقاء الرابط

تساعد آلية keepalive الطرفين على اكتشاف الاتصالات المنقطعة. إذا لم يتم تبادل أي بيانات خلال الوقت المتفق عليه، يرسل العميل حزمة PINGREQ ويرد الوسيط بحزمة PINGRESP.

هذا مهم لأن أجهزة إنترنت الأشياء قد تعمل على شبكات غير مستقرة أو روابط متنقلة أو Wi-Fi أو اتصالات خلوية أو روابط أقمار صناعية أو مسارات WAN بعيدة. قد تفشل الشبكة بصمت من دون إغلاق الاتصال بشكل نظيف. تساعد keepalive على اكتشاف هذه الحالة.

قطع الاتصال وإعادة الاتصال

يمكن للعميل قطع الاتصال بشكل طبيعي بإرسال حزمة DISCONNECT. وقد يختفي أيضاً بشكل غير متوقع بسبب فقدان الطاقة أو فشل الشبكة أو تعطل البرنامج الثابت أو فقدان الإشارة. عندها يطبق الوسيط قواعد الجلسة ورسالة الوصية المكوّنة لهذا العميل.

سلوك إعادة الاتصال مهم في عمليات النشر الفعلية. يجب أن تتعامل الأجهزة مع انقطاع الشبكة بسلاسة، وأن تتجنب عواصف إعادة الاتصال، وأن تستأنف الاتصال وفق سياسة الجلسة المطلوبة.

أسماء الموضوعات وتوجيه الرسائل

الموضوعات هي مسارات نصية تُستخدم لتصنيف الرسائل. قد يبدو الموضوع كتسلسل هرمي مثل building/floor1/room102/temperature أو factory/line3/motor7/status. يرسل الناشرون الرسائل إلى الموضوعات، ويتلقى المشتركون الرسائل من الموضوعات التي اشتركوا فيها.

التصميم الجيد للموضوعات من أهم أجزاء النشر الناجح. يجب أن تكون أسماء الموضوعات متوقعة وسهلة القراءة ومتوافقة مع بنية النظام الحقيقية. أما التصميم الضعيف فيجعل التصفية والأذونات والمراقبة والصيانة طويلة الأمد أكثر صعوبة.

يمكن للمشتركين استخدام موضوعات دقيقة أو اشتراكات بأحرف بدل. يمكن لحرف بدل أحادي المستوى أن يطابق مستوى واحداً من الموضوع، بينما يمكن لحرف بدل متعدد المستويات أن يطابق مستويات كثيرة. تفيد أحرف البدل لوحات المعلومات ومنصات التحليل وأدوات المراقبة وتطبيقات الإدارة التي تحتاج إلى استقبال رسائل من أجهزة كثيرة.

تدفق النشر والاشتراك

نشر البيانات

عندما ينشر العميل بيانات، يرسل حزمة PUBLISH إلى الوسيط. تتضمن الحزمة اسم الموضوع والحمولة ومستوى جودة الخدمة وعلامة الاحتفاظ ومعرّف الحزمة عندما يتطلب مستوى QoS المختار ذلك.

يمكن أن تحتوي الحمولة على صيغ كثيرة للبيانات. قد تكون نصاً عادياً أو JSON أو بيانات ثنائية أو قيماً لمستشعرات أو رسائل حالة أو أوامر أو إنذارات أو سجلات قياس عن بعد أو بيانات تطبيق مشفرة. لا يحدد MQTT نفسه معنى الحمولة. التطبيق هو الذي يقرر كيفية تنظيمها وتفسيرها.

استقبال الاشتراكات

يشترك العميل بإرسال حزمة SUBSCRIBE تحتوي على مرشح موضوع واحد أو أكثر. يرد الوسيط بحزمة SUBACK ويبدأ في تسليم الرسائل المطابقة إلى ذلك العميل وفق مستوى QoS المطلوب والممنوح.

قد يكون المشتركون لوحات معلومات أو قواعد بيانات أو محركات أتمتة أو خدمات سحابية أو تطبيقات محمولة أو وحدات تحكم في الأجهزة أو أجهزة ميدانية أخرى. ويمكن أن تُسلّم رسالة منشورة واحدة إلى عدد كبير من المشتركين في الوقت نفسه.

إزالة الاهتمام

عندما لا يرغب العميل في رسائل معينة، يرسل حزمة UNSUBSCRIBE. يتوقف الوسيط عن تمرير رسائل الموضوعات المطابقة بعد تأكيد الطلب.

يتيح ذلك للتطبيقات تغيير اهتمامها بالبيانات ديناميكياً. على سبيل المثال، قد تشترك لوحة معلومات في مبنى معين أثناء عرض المستخدم له، ثم تلغي الاشتراك عندما ينتقل المستخدم إلى موقع آخر.

يتيح نموذج النشر/الاشتراك لمنتجي البيانات ومستهلكيها التطور بشكل مستقل، بينما يدير الوسيط التوجيه وسلوك الجلسة والتحكم في التسليم.

مستويات جودة الخدمة

QoS 0: مرة واحدة على الأكثر

QoS 0 هو أبسط مستوى تسليم. تُرسل الرسالة مرة واحدة، ولا يوجد تأكيد من المستقبل على طبقة MQTT. إذا فُقدت الرسالة، فلن يعيد البروتوكول إرسالها.

هذا المستوى مفيد للقياس عن بعد المتكرر عندما يكون فقدان تحديث عارض مقبولاً. على سبيل المثال، قد لا يحتاج مستشعر حرارة يرسل بيانات كل بضع ثوانٍ إلى وصول كل قراءة منفردة.

QoS 1: مرة واحدة على الأقل

يتطلب QoS 1 تأكيداً. يعيد المرسل إرسال الرسالة إذا لم يتلق تأكيداً. يحسن ذلك موثوقية التسليم، لكن المستقبل قد يتلقى رسائل مكررة.

يجب أن تكون التطبيقات التي تستخدم QoS 1 مستعدة لمعالجة التكرار. وهذا شائع في الإنذارات وتغييرات الحالة والأوامر والقياس عن بعد المهم حيث يكون وصول الرسالة أهم من تجنب التكرار تماماً.

QoS 2: مرة واحدة بالضبط

يستخدم QoS 2 مصافحة أكثر تعقيداً لضمان تسليم الرسالة مرة واحدة بالضبط على مستوى البروتوكول. يوفر أقوى ضمان للتسليم، لكنه يضيف حملاً وتأخيراً أكبر.

يمكن استخدام هذا المستوى عندما يكون تكرار المعالجة ضاراً. ومع ذلك، تستخدم كثير من عمليات النشر الواقعية QoS 0 أو QoS 1 لأنهما يقدمان توازناً أفضل بين الأداء والموثوقية.

الرسائل المحتفَظ بها وآخر حالة معروفة

الرسالة المحتفَظ بها هي رسالة يخزنها الوسيط كأحدث رسالة لموضوع معين. عندما يشترك مشترك جديد في ذلك الموضوع، يرسل الوسيط الرسالة المحتفَظ بها فوراً حتى يرى المشترك آخر حالة معروفة.

يفيد ذلك في معلومات الحالة مثل حالة اتصال الجهاز، أو حالة المفتاح، أو قيمة المستشعر، أو إصدار الإعدادات، أو حالة الإنذار، أو وضع التشغيل الحالي. من دون الرسائل المحتفَظ بها قد يضطر المشترك الجديد إلى انتظار التحديث التالي قبل معرفة الحالة الحالية.

يجب استخدام الرسائل المحتفَظ بها بحذر. فهي مفيدة للحالة، لكنها ليست دائماً مناسبة لتدفقات الأحداث. قد تربك رسالة حدث محتفَظ بها مثل “فتح الباب” مشتركاً جديداً إذا لم تعد صحيحة. ينبغي تصميم موضوعات الحالة وموضوعات الأحداث بشكل منفصل.

سلوك الجلسة والتسليم أثناء عدم الاتصال

يدعم MQTT سلوك الجلسة الذي يحدد ما يحدث عندما ينقطع العميل ثم يعيد الاتصال لاحقاً. بحسب إصدار البروتوكول والإعدادات، قد يخزن الوسيط الاشتراكات والرسائل الموضوعة في الطابور وحالة الجلسة الخاصة بالعميل.

هذا مفيد للأجهزة التي تدخل وضع السكون أو تنتقل بين الشبكات أو تفقد الاتصال مؤقتاً. عندما يعيد الجهاز الاتصال، يمكنه متابعة استقبال الرسائل التي وُضعت في الطابور أثناء عدم اتصاله، إذا سمحت سياسة الجلسة وقواعد QoS بذلك.

يجب أن تتوافق استمرارية الجلسة مع دور الجهاز. قد لا يحتاج مستشعر يعمل بالبطارية إلى حفظ كل أمر في الطابور إلى الأبد. وقد يحتاج متحكم بعيد إلى تحديثات إعدادات موضوعة في الطابور. كثرة الطوابير أثناء عدم الاتصال تستهلك موارد الوسيط، وقلتها قد تؤدي إلى فقدان الأوامر.

رسائل الوصية للفشل غير المتوقع

تسمح رسالة الوصية، التي يشار إليها غالباً باسم رسالة الوصية الأخيرة، للعميل بتحديد رسالة يجب أن ينشرها الوسيط إذا انقطع العميل بشكل غير متوقع. يساعد ذلك الأنظمة الأخرى على اكتشاف فشل الجهاز أو فقدان الشبكة أو الإيقاف غير الطبيعي.

على سبيل المثال، قد يضبط جهاز رسالة وصية على موضوع حالة مثل device/123/status. إذا فقد الجهاز الطاقة من دون إرسال قطع اتصال طبيعي، ينشر الوسيط رسالة عدم الاتصال المكوّنة.

تُستخدم هذه الميزة على نطاق واسع في لوحات المراقبة وأنظمة صحة الأجهزة والقياس الصناعي عن بعد ومراقبة البوابات وإدارة الأصول عن بُعد. وهي توفر طريقة بسيطة لإظهار الانقطاع غير الطبيعي لأجزاء أخرى من النظام.

الأمان والتحكم في الوصول

المصادقة

يجب على الوسيط التحقق من هوية العميل قبل السماح بالوصول. قد تستخدم المصادقة اسم مستخدم وكلمة مرور أو شهادات عميل أو رموزاً أو بيانات اعتماد API أو تكاملاً مع نظام هوية خارجي.

قد تسمح المصادقة الضعيفة لأجهزة غير مصرح بها بنشر بيانات مزيفة أو الاشتراك في موضوعات حساسة أو تعطيل بيئة المراسلة.

التفويض

بعد التحقق من الهوية، يجب أن يقرر الوسيط الموضوعات التي يمكن للعميل النشر فيها والاشتراك فيها. لا ينبغي لمستشعر أن ينشر أوامر إلى أجهزة غير مرتبطة. ولا ينبغي لتطبيق مستأجر أن يتلقى بيانات مستأجر آخر.

تعد الأذونات على مستوى الموضوع ضرورية في عمليات النشر متعددة الأجهزة ومتعددة المواقع ومتعددة المستأجرين.

التشفير

يحمي تشفير TLS البيانات أثناء انتقالها بين العملاء والوسيط. هذا مهم عندما تمر الرسائل عبر شبكات عامة أو شبكات خلوية أو اتصالات سحابية أو بنية تحتية غير موثوقة.

يجب إقران التشفير بإدارة الشهادات والتخزين الآمن للمفاتيح وتجهيز العملاء بعناية. لا تساعد طبقة النقل الآمنة إذا كانت بيانات الاعتماد مكشوفة في البرنامج الثابت أو ملفات الإعداد.

أنماط النشر

من الجهاز إلى السحابة

في كثير من أنظمة إنترنت الأشياء، تنشر المستشعرات والبوابات البيانات إلى وسيط سحابي. ثم تقوم التطبيقات السحابية بتخزين البيانات وعرضها وتحليلها والعمل بناءً عليها. هذا النموذج شائع في المباني الذكية وإدارة الطاقة ومراقبة الأساطيل ومنصات المعدات البعيدة.

أهم اعتبارات التصميم هي الأمان ومرونة الشبكة وهوية الجهاز وحجم الرسائل والتوسع في جانب السحابة.

تجميع بوابة الحافة

يمكن لبوابة الحافة جمع البيانات من الأجهزة المحلية ونشر بيانات ملخصة أو مرشحة إلى وسيط مركزي. ويمكنها أيضاً الاشتراك في موضوعات الأوامر وتمرير التعليمات إلى المعدات المحلية.

يقلل ذلك عرض النطاق، ويحسن التحكم المحلي، ويسمح للموقع بمواصلة بعض الوظائف حتى عندما يكون الاتصال السحابي غير متاح.

وسيط محلي لأنظمة الموقع

تستخدم بعض عمليات النشر وسيطاً محلياً داخل مصنع أو مبنى أو مختبر أو حرم أو غرفة تحكم. تتبادل الأجهزة والتطبيقات البيانات محلياً بزمن تأخير منخفض واعتماد أقل على الشبكات الخارجية.

يمكن للوسيط المحلي لاحقاً ربط بيانات مختارة بمنصة سحابية أو مؤسسية. وهذا يمنح مصممي النظام تحكماً أكبر في تدفق البيانات والاعتماد على الشبكة.

التطبيقات عبر الأنظمة المتصلة

المراقبة الصناعية

تستخدم المصانع ومواقع المرافق MQTT لجمع حالة المعدات وبيانات المستشعرات ورسائل الإنذار وقيم الطاقة وقراءات الحرارة وبيانات الاهتزاز ومؤشرات الإنتاج. يناسب البروتوكول البيئات التي ترسل فيها أجهزة كثيرة رسائل صغيرة إلى منصات إشرافية.

يجب أن تراعي عمليات النشر الصناعية تقسيم الشبكة، وتكرار الوسيط، واختيار QoS، والحالة المحتفَظ بها، وتجهيز الأجهزة بشكل آمن.

المباني الذكية

يمكن لأنظمة المباني استخدام البروتوكول لربط الإضاءة و HVAC والتحكم في الوصول ومستشعرات الإشغال والعدادات والمصاعد ولوحات الغرف ولوحات المعلومات. ويمكن لبنية الموضوعات أن تعكس تسلسل المبنى والطابق والغرفة والجهاز.

يجعل ذلك البيانات أسهل تنظيماً ويساعد قواعد الأتمتة على الاشتراك فقط في الأحداث أو الحالات ذات الصلة.

الطاقة والقياس

قد تستخدم منصات الطاقة MQTT لجمع قراءات العدادات وبيانات العاكسات وحالة البطاريات ومعلومات الحمل والقياس عن بعد المرتبط بالشبكة. تكون المراسلة الخفيفة مفيدة عندما تبلغ أجهزة كثيرة عن قيم صغيرة بشكل دوري.

لأن أنظمة الطاقة قد تؤثر في الفوترة أو التحكم أو السلامة، يجب التعامل بعناية مع المصادقة وسلامة الرسائل.

المركبات المتصلة والتنقل

قد تستخدم منصات المركبات ومحطات الشحن وأنظمة الأساطيل وخدمات التنقل البروتوكول للقياس عن بعد وتحديثات الموقع والتشخيص والتنبيهات ووظائف التحكم عن بُعد.

قد تكون الشبكات المحمولة غير مستقرة، لذلك تعد معالجة الجلسة ومنطق إعادة الاتصال وتصميم الحمولة بكفاءة أموراً مهمة.

الاستهلاك وأتمتة المنزل

تستخدم أنظمة أتمتة المنزل MQTT لربط المستشعرات والمفاتيح والأضواء وأجهزة تنظيم الحرارة والكاميرات والمحاور وقواعد الأتمتة. يجعل نموذج النشر/الاشتراك من السهل أن يطلق حدث مستشعر واحد عدة إجراءات.

في النشر المنزلي، تعد تسمية الموضوعات ببساطة وإعداد الوسيط المحلي بشكل آمن أمرين مهمين لتجنب الارتباك والوصول غير المصرح به.

اعتبارات الأداء وقابلية التوسع

يجب أن يبقى حجم الرسالة معقولاً. MQTT فعال للرسائل الصغيرة، لكنه ليس مثالياً للملفات الكبيرة جداً أو تدفقات الوسائط الثقيلة. قد تزيد الحمولات الكبيرة استخدام ذاكرة الوسيط وازدحام الشبكة وتأخير المعالجة.

يؤثر تصميم الموضوعات في الأداء. الاستخدام المفرط لاشتراكات أحرف البدل الواسعة قد يزيد عبء الوسيط، لأن رسائل كثيرة يجب مطابقتها وتسليمها إلى عملاء كثيرين. تساعد البنية الواضحة للموضوعات الأنظمة على التوسع بصورة أكثر قابلية للتوقع.

عدد الاتصالات عامل آخر. يجب على وسيط يخدم آلافاً أو ملايين العملاء أن يتعامل مع حركة keepalive والمصادقة وحالة الجلسة والرسائل المحتفَظ بها والرسائل الموضوعة في الطابور وحدود الشبكة. قد يتطلب التوسع التجميع أو موازنة الحمل أو تجميع الحافة أو تقسيم الموضوعات.

يؤثر مستوى QoS أيضاً في الأداء. يوفر QoS 2 دلالة تسليم أقوى لكنه ينشئ تبادلاً أكبر للحزم. في القياس عن بعد عالي الحجم، قد يكون استخدام QoS 0 أو QoS 1 مع منطق على مستوى التطبيق أكثر عملية.

أخطاء تصميم شائعة

تسمية موضوعات غير واضحة

تجعل أسماء الموضوعات العشوائية أو غير المتسقة إدارة الأذونات ولوحات المعلومات والتنبيهات والتحليلات صعبة. يجب إنشاء خطة للموضوعات قبل النشر واسع النطاق.

استخدام الرسائل المحتفَظ بها للأحداث

الرسائل المحتفَظ بها أفضل للحالة الحالية. استخدامها للأحداث التي تحدث مرة واحدة قد يضلل المشتركين الجدد لأنهم قد يتلقون حدثاً قديماً كأنه حدث للتو.

عدم معالجة التكرار

يمكن أن يسلّم QoS 1 رسائل مكررة. يجب أن تستخدم التطبيقات طوابع زمنية أو معرّفات رسائل أو أرقام تسلسل أو معالجة عديمة الأثر الجانبي عندما قد تسبب الرسائل المكررة مشكلات.

إدارة ضعيفة لبيانات الاعتماد

قد تنشئ كلمات المرور المشتركة المضمّنة ومعرّفات العملاء المعاد استخدامها والشهادات غير المحمية مخاطر أمنية خطيرة. يجب أن يمتلك كل جهاز هوية قابلة للإدارة ومساراً للإلغاء.

تجاهل فشل الوسيط

الوسيط مركز البنية. إذا فشل ولا يوجد تكرار أو خطة استرداد، فقد يتوقف الاتصال. يجب أن تراعي عمليات النشر الحرجة التجميع أو الوسطاء الاحتياطيين أو تصميم الجسور أو سلوك التراجع المحلي.

يعمل MQTT جيداً عندما تُصمم الموضوعات والجلسات و QoS والحالة المحتفَظ بها والأمان وسعة الوسيط معاً، بدلاً من إعدادها كخيارات منفصلة.

الصيانة والمراقبة

يجب على فرق التشغيل مراقبة CPU الوسيط والذاكرة وعدد الاتصالات ومعدل الرسائل وعدد الرسائل المحتفَظ بها وعدد الاشتراكات والرسائل في الطابور وفشل المصادقة والاتصالات المنقطعة وزمن تأخير الشبكة.

يجب أن تكون صحة العميل مرئية أيضاً. قد تشير عمليات إعادة الاتصال المتكررة والجلسات المنتهية ومعرّفات العملاء المكررة ومعدلات النشر غير الطبيعية والوصول غير المتوقع إلى الموضوعات إلى أعطال في الأجهزة أو مشكلات أمنية.

النسخ الاحتياطية للإعدادات مهمة. يجب توثيق إعدادات الوسيط وقوائم التحكم في الوصول والشهادات وسياسات الموضوعات وإعدادات الجسر وسلوك الحالة المحتفَظ بها، وأن تكون قابلة للاسترداد.

الأسئلة الشائعة

هل يمكن أن يعمل MQTT عبر WebSocket؟

نعم. يدعم كثير من الوسطاء MQTT عبر WebSocket، مما يسمح للتطبيقات القائمة على المتصفح ولوحات الويب بالتواصل عبر مسارات نقل مناسبة للويب.

هل هو مناسب لإرسال فيديو كبير أو محتوى ملفات؟

عادةً لا يكون هو الطريقة الأساسية. هو أفضل للرسائل الصغيرة والقياس عن بعد والأحداث والأوامر وتحديثات الحالة. غالباً ما تُنقل الملفات الكبيرة عبر بروتوكولات أخرى، مع رسالة تحمل مرجع الملف.

ماذا يحدث إذا استخدم عميلان معرّف العميل نفسه؟

يفصل كثير من الوسطاء العميل الموجود عندما يتصل عميل جديد بالمعرّف نفسه. تعد معرّفات العملاء الفريدة مهمة لاستقرار سلوك الجلسة.

هل يمكن لوسيط أن يتصل بوسيط آخر؟

نعم. يمكن استخدام ربط الوسطاء أو التجميع لتبادل موضوعات مختارة بين المواقع والمناطق وبوابات الحافة والمنصات السحابية، بحسب قدرة الوسيط.

كيف ينبغي تخطيط أسماء الموضوعات؟

استخدم تسلسلاً هرمياً متسقاً يعتمد على الموقع والنظام والجهاز ونوع البيانات والوظيفة. تجنب الأسماء العشوائية، والمعلومات الحساسة في مسارات الموضوعات، والاعتماد المفرط على أحرف البدل الواسعة.