MQTTv5.0: نظرة عامة على الميزات الجديدة. الجزء 2

مرحبا!



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



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



يوجد أدناه جدول بجميع الخصائص ( انظر القسم 2.2.2.2 في المواصفات ).







الآن دعونا نلقي نظرة فاحصة عليهم.

مؤشر تنسيق الحمولة - مؤشر تنسيق الحمولة

• 0 - البيانات عبارة عن مجموعة من البايتات غير المحددة ، والتي تعادل عدم إرسال مؤشر تنسيق الحمولة النافعة ،
  
  
• 1 - البيانات عبارة عن بيانات ذات أحرف مشفرة UTF-8.
  
  

الفاصل الزمني لانتهاء صلاحية الرسالة - الفاصل الزمني لانتهاء صلاحية الرسالة

رقم يمثل فترة انتهاء صلاحية الرسالة (بالثواني).



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

نوع المحتوى - نوع المحتوى

يتم تحديد معنى نوع المحتوى بواسطة العميل المرسل والمستقبل.

موضوع الرد - موضوع للرد

سلسلة UTF-8 تُستخدم كموضوع لرسالة الرد.



يرسل مستلم الرسالة بالموضوع المحدد للرد رده ، مستخدمًا هذا الموضوع كموضوع للنشر.



يحدث تفاعل الطلب / الاستجابة في هذه الحالة على النحو التالي ( انظر الفقرة 4.10.1 في المواصفات ):

1. ينشر العميل (المرسل) رسالة طلب مع بعض الموضوعات التي تحدد موضوع الاستجابة.
   
   
2. () , , . . , .
   
   
3. , , .
   
   
4. . - . , .
   
   

Correlation Data —

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



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



تكون قيمة بيانات الارتباط ذات مغزى فقط لمرسل رسالة الطلب ومتلقي رسالة الاستجابة.

معرف الاشتراك - معرف الاشتراك

رقم يمثل معرف الاشتراك.



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



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



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



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

الفاصل الزمني لانتهاء الجلسة - الفاصل الزمني لانتهاء الجلسة

رقم يمثل الفاصل الزمني لانتهاء الجلسة (بالثواني).



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



إذا كان الفاصل الزمني لانتهاء صلاحية الجلسة هو 0xFFFFFFFF (UINT_MAX) ، لا تنتهي صلاحية جلسة العمل.



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



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



إعداد Clean Start على 1 وفترة انتهاء الصلاحية 0 يعادل ضبط CleanSession على 1 في الإصدار 3.1.1 من مواصفات MQTT. إعداد Clean Start على 0 ولا يوجد فاصل زمني لانتهاء الجلسة يعادل ضبط CleanSession على 0 في الإصدار 3.1.1 من مواصفات MQTT.

معرف العميل المعين - معرف العميل المعين

سلسلة هي معرف العميل المعين من قبل الخادم. يُستخدم إذا تم استخدام معرف عميل بطول صفري في حزمة CONNECT.

Server Keep Alive - خادم Keep Alive

رقم يحدد وقت Keep Alive المعين من قبل الخادم. إذا قام الخادم بإرجاع Server Keep Alive في حزمة CONNACK ، فيجب على العميل استخدام هذه القيمة بدلاً من القيمة التي أرسلها على أنها Keep Alive. إذا لم يرسل الخادم Server Keep Alive ، فيجب أن يستخدم قيمة Keep Alive التي حددها العميل في حزمة CONNECT.



الاستخدام الأساسي لـ Server Keep Alive للخادم هو إبلاغ العميل بأنه سيفصل العميل في حالة عدم النشاط قبل انتهاء مهلة Keep Alive المحددة للعميل.

طريقة المصادقة - طريقة المصادقة

سلسلة تحتوي على اسم طريقة المصادقة المستخدمة للمصادقة الموسعة.



إذا لم تكن هناك طريقة مصادقة ، فلن يتم تنفيذ المصادقة الموسعة.



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

بيانات المصادقة - بيانات المصادقة

بيانات ثنائية تحتوي على بيانات المصادقة. يتم إرساله فقط إذا تم تحديد طريقة مصادقة. يتم تحديد محتوى هذه البيانات من خلال طريقة المصادقة.

طلب معلومات المشكلة - معلومات حول مشكلة الطلب

يستخدم العميل هذه القيمة للإشارة إلى ما إذا كان قد تم إرسال سلسلة سبب أو خصائص مخصصة عند الفشل.

• 0 - يمكن للخادم إرجاع سلسلة سبب أو خصائص مخصصة في حزمة CONNACK أو DISCONNECT ، ولكن يجب ألا يرسل سلسلة سبب أو خصائص مخصصة في أي حزمة بخلاف النشر أو الاتصال أو قطع الاتصال ،
  
  
• 1 - يمكن للخادم إرجاع سلسلة سبب أو خصائص مخصصة لأي حزمة مسموح بها.
  
  

سوف تأخير الفاصل - هل رسالة تأخير الفاصل

رقم يمثل الفاصل الزمني لتأخير رسالة الوصية (بالثواني). إذا لم يكن هناك فاصل تأخير ، فسيكون الافتراضي هو 0 ولا يوجد تأخير قبل نشر "رسالة الوصية".



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



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

طلب معلومات الاستجابة - طلب معلومات للرد

بايت بقيمة 0 أو 1. يستخدم العميل هذه القيمة لطلب معلومات استجابة CONNACK من الخادم.

• 0 - يجب ألا يعرض الخادم معلومات الاستجابة ،
  
  
• 1 - يمكن للخادم إرجاع معلومات الاستجابة في حزمة CONNACK ، لكن هذا ليس مطلوبًا حتى إذا طلب العميل هذه المعلومات.
  
  

معلومات الاستجابة - معلومات للاستجابة

سلسلة UTF-8 تُستخدم كأساس لإنشاء موضوع الاستجابة. لم يتم تحديد الطريقة التي ينشئ بها العميل "موضوع استجابة" من معلومات الاستجابة بواسطة هذه المواصفات.



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

مرجع الخادم - ارتباط بالخادم

سلسلة يمكن للعميل استخدامها لتعريف خادم آخر قيد الاستخدام. قيمة هذه السلسلة هي قائمة روابط مفصولة بمسافات. تنسيق الروابط غير منظم.



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

• استخدام خادم مختلف - يجب على العميل التبديل مؤقتًا لاستخدام خادم مختلف.
  
  
• تم نقل الخادم - يجب على العميل دائمًا الاتصال بخادم مختلف.
  
  

من المستحسن أن يتكون كل ارتباط من اسم متبوع بنقطتين ورقم منفذ. إذا كان الاسم يحتوي على نقطتين ، فيمكن وضع سلسلة الاسم بين قوسين مربعين. لا يمكن أن يحتوي الاسم المضمن بين قوسين معقوفين على حرف قوس مربع أيمن ("]"). يستخدم هذا لتمثيل عنوان IPv6 الذي يستخدم نقطتين كفاصل.



عادةً ما يكون الاسم الموجود في ارتباط الخادم هو اسم المضيف أو اسم DNS أو اسم SRV أو عنوان IP. عادةً ما تكون القيمة بعد النقطتين هي رقم المنفذ العشري. هذا غير مطلوب إذا كانت معلومات المنفذ مأخوذة من الاسم (على سبيل المثال ، لـ SRV) أو كانت الاسم الافتراضي.



إذا تم توفير روابط متعددة ، فمن المتوقع أن يختار العميل إحداها.

سلسلة السبب - سلسلة السبب

سلسلة تصف السبب المرتبط بهذه الاستجابة. يستخدم الخادم هذه القيمة لتوفير معلومات إضافية للعميل.



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

تلقي الحد الأقصى - الحد الأقصى لقيمة عدد حزم QOS> 0

رقم يحدد حصة الإرسال ، والذي يستخدم للحد من عدد حزم PUBLISH QOS> 0 التي يمكن إرسالها دون تلقي PUBACK (لـ QoS 1) أو PUBCOMP (لـ QoS 2). أي ، يتم استخدام هذه القيمة للحد من عدد منشورات QoS 1 و QoS 2 المرسلة في وقت واحد. يجب ألا يرسل العميل / الخادم رسائل مع QoS 1 و QoS 2 إذا كانت هناك رسائل "تلقي الحد الأقصى من الرسائل المرسلة التي لم تتلق ردودًا بعد". عند الوصول إلى الحد الأقصى للاستلام ، يمكن أيضًا إيقاف إرسال الحزم ذات جودة الخدمة 0 مؤقتًا ، ولكن ليس مطلوبًا. في الوقت نفسه ، ليست هناك حاجة لتأخير إرسال الحزم بخلاف النشر.



إذا قام كل من العميل والخادم بتعيين الحد الأقصى للاستلام على 1 ، فإنهم يتأكدون من عدم وجود أكثر من رسالة واحدة "في الرحلة" في نفس الوقت.



تنطبق القيمة المحددة فقط على اتصال الشبكة الحالي وتتم إعادة تهيئتها عند إعادة الاتصال.



إذا لم يتم تحديدها ، يتم تعيينها افتراضيًا على 65.535.

الحد الأقصى للاسم المستعار للموضوع - الحد الأقصى لقيمة الاسم المستعار للموضوع

رقم يمثل الحد الأقصى لقيمة الاسم المستعار للموضوع.



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

موضوع الاسم المستعار - موضوع الاسم المستعار

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



من جانب المستلم ، عند تلقي اسم مستعار لموضوع ما ، يتم إنشاء المراسلات الضرورية بين الموضوع والاسم المستعار الخاص به.



إذا كانت حزمة PUBLISH تحتوي على اسم مستعار للموضوع ، يقوم المستلم بمعالجته على النحو التالي ( انظر القسم 3.3.4 في المواصفات ):

1. ,
   
   a) , , ,
   
   b) , , , .
   
   
2. ,
   
   a) ,
   
   b) , .
   
   

Maximum QoS — QoS

يمكن أن يكون 0 أو 1. إذا لم يكن هناك حد أقصى لجودة الخدمة ، يستخدم العميل الحد الأقصى لجودة الخدمة 2.



إذا كان الخادم لا يدعم حزم PUBLISH QoS 1 أو QoS 2 ، فيجب أن يرسل الحد الأقصى لجودة الخدمة (QoS) في حزمة CONNACK التي تشير إلى أعلى جودة خدمة يدعمها.



إذا تلقى العميل الحد الأقصى من جودة الخدمة (QoS) من الخادم ، فلا يجب أن يرسل حزم نشر بمستوى جودة الخدمة يتجاوز الحد الأقصى المحدد.

الاحتفاظ متاح - الحفظ متاح

• 0 - الرسائل المحفوظة غير مدعومة ،
  
  
• 1 - دعم الرسائل المحفوظة.
  
  

يجب ألا يرسل العميل الذي يتلقى القيمة 0 من الخادم الاحتفاظ بالمتاحة حزمة نشر مع تعيين علامة RETAIN على 1.

خاصية المستخدم - خاصية المستخدم

إنه زوج سلسلة "اسم" - "قيمة". هذه الخاصية ، على عكس الآخرين ، يمكن أن تظهر عدة مرات. يمكن استخدام نفس الاسم لعدة خصائص.



يمكن استخدام هذه الخاصية لتقديم تشخيص إضافي أو معلومات أخرى.



لم يتم تحديد معنى هذه الخصائص في المواصفات ، ومعناها وتفسيرها معروفان فقط للعملاء المرسلين والمستقبلين.

الحد الأقصى لحجم الحزمة - الحد الأقصى لحجم الحزمة

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



إذا لم يكن هناك حد أقصى لحجم الحزمة ، فلن يتم فرض حد لحجم الحزمة.



تقع على عاتق التطبيق مسؤولية تحديد أقصى قيمة مناسبة لحجم الحزمة إذا اختار تحديد حجم الحزمة.

يتوفر اشتراك Wildcard - يتوفر اشتراك Wildcard

• 0 - اشتراكات أحرف البدل غير مدعومة ،
  
  
• 1 - هذه الاشتراكات مدعومة.
  
  

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



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

معرف الاشتراك متاح - يتوفر معرف الاشتراك

• 0 - معرفات الاشتراك غير مدعومة ،
  
  
• 1 - معرفات الاشتراك مدعومة.
  
  

إذا كانت الخاصية مفقودة ، يتم دعم معرّفات الاشتراك.

اشتراك مشترك متاح - اشتراك مشترك متاح

• 0 - الاشتراكات العامة غير مدعومة ،
  
  
• 1 - الاشتراكات العامة مدعومة.
  
  

إذا كان الموقع مفقودًا ، يتم دعم الاشتراكات العامة.

خاتمة

اسمحوا لي أن أذكركم بأن المقالة ولدت أثناء العمل على دمج الوظائف الناشئة الموضحة أعلاه في خدمة منصة إنترنت الأشياء. بدا لي أيضًا أنه من الملائم جدًا عرض عرض الخصائص المستلمة من العميل في واجهة الكائن ( يمكنك قراءة المزيد عن الكائنات هنا >>> ). يمكنك إخفاء الخصائص غير المثيرة للاهتمام ، ويمكنك إضافة خصائص مخصصة إضافية لعرضها. بشكل عام ، يبدو مثل هذا. ربما هذا كل شيء. لاختبار الوظيفة ، وجدت أن هذا المشروع redboltz / mqtt_cpp مريح للغاية وواضح . سأكون سعيدًا جدًا إذا شاركت في التعليقات مشاريع أخرى مفتوحة المصدر لعملاء MQTT (مع واجهة المستخدم الرسومية وبدونها) تدعم الإصدار 5.0.