بروتوكول MQTT: الغمر المفاهيمي

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

وهذا يعني أن البروتوكولات خفيفة الوزن ، مفتوحة ، وبأسعار معقولة سوف تصبح أكثر أهمية مع مرور الوقت. توفر هذه المقالة الانغماس المفاهيمي في MQTT: كيف يعمل ، وكيف يتم استخدامه الآن وكيف سيتم استخدامه في المستقبل.

مقدمة صغيرة


MQTT هو بروتوكول مراسلة يستند إلى الناشر (pub / sub). تم نشر الإصدار الأولي في عام 1999 من قبل آندي ستانفورد كلارك من آي بي إم وآرلين نيبر من سيروس لينك. نظروا إلى MQTT كوسيلة للحفاظ على الاتصال بين الأجهزة في الشبكات ذات النطاق الترددي المحدود أو الاتصالات غير المتوقعة. كان أحد الخيارات الأولى لاستخدامه هو ضمان الاتصال بين أجزاء خط الأنابيب مع بعضها البعض ومع الروابط المركزية عبر الأقمار الصناعية.

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

وبالتالي ، أصبح MQTT بروتوكولًا لتدفق البيانات بين الأجهزة ذات طاقة وحدة المعالجة المركزية و / أو عمر البطارية المحدود ، وكذلك بالنسبة للشبكات ذات النطاق الترددي العالي أو المنخفض أو الاستقرار غير المتوقع أو الكمون العالي. لهذا السبب تُعرف MQTT بأنها السيارة المثالية لإنترنت الأشياء. إنه مبني على بروتوكول TCP / IP ، ولكن يوجد فرع MQTT-SN للعمل عبر Bluetooth و UDP و ZigBee وشبكات إنترنت الأشياء الأخرى غير TCP / IP.

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

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

كيف تعمل MQTT: الأساسيات


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



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

مثال على كيفية تكوين العميل للاتصال من خلال وسيط MQTT :

var options = { keepalive: 60, username: 'FIRST_HALF_OF_API_KEY', password: 'SECOND_HALF_OF_API_KEY', port: 8883 }; var client = mqtt.connect('mqtts:mqtt.ably.io', options); 

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

 var ably = new Ably.Realtime('REPLACE_WITH_YOUR_API_KEY'); var decoder = new TextDecoder(); var channel = ably.channels.get('input'); channel.subscribe(function(message) { var command = decoder.decode(message.data); }); 

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

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

بالإضافة إلى ذلك ، في MQTT ، يمكنك استخدام مصادقة Ably على الرموز إذا كنت لا ترغب في الكشف عن مفتاح API الخاص بك لعميل MQTT الفعلي على الإطلاق (في حالة MQTT بدون SSL ، الرموز المميزة مطلوبة لمنع نقل مفاتيح API بنص واضح). مثال مصادقة الرمز المميز:

 var options = { keepalive: 60, username: INSERT_TOKEN_HERE, password: '', port: 8883 }; var client = mqtt.connect('mqtts:mqtt.ably.io', options); client.subscribe("[mqtt]tokenevents", { /* Create a new token called 'NEW_TOKEN' */ client.end(); options.username = NEW_TOKEN; client = mqtt.connect('mqtts:mqtt.ably.io', options); }); 

وظيفة MQTT: الانغماس أعمق


وفقًا لـ IBM ، تمتلك MQTT الخصائص التالية:

  • محايد لمحتوى الرسالة
  • مثالي للاتصالات الموزعة من واحد إلى العديد والتطبيقات غير المتصلة
  • مجهز بوظيفة LWT (الوصية الأخيرة والعهد ، "الوصية الأخيرة والشهادة") لإعلام الأطراف بقطع الاتصال غير الطبيعي للعميل
  • يعتمد على TCP / IP للقيام بمهام الاتصال الأساسية
  • مصمم لتوصيل الرسائل باستخدام القوالب "على الأكثر مرة واحدة" و "مرة واحدة على الأقل" و "مرة واحدة تمامًا"

يمكن للعضو في نظام MQTT تولي دور الناشر أو المستهلك أو كلاهما في آن واحد.

إحدى الخصائص المميزة لـ MQTT هي فهمها الفريد للقنوات: يتم التعامل مع كل واحدة منها كمسار للملف ، على سبيل المثال:

 channel = "user/path/channel" 

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

تنسيق رسالة MQTT


انظر إلى المكونين اللذين يشكلان كل رسالة من رسائل MQTT:

  • البايتة 1 : تحتوي على نوع الرسالة (طلب اتصال العميل ، تأكيد الاشتراك ، طلب اختبار الاتصال ، وما إلى ذلك) ، إشارة ازدواجية ، تعليمات لحفظ الرسائل ، ومعلومات حول جودة الخدمة (QoS).
  • البايتة 2 : تحتوي على معلومات حول طول الرسالة المتبقية ، بما في ذلك الحمولة وأية بيانات في رأس متغير اختياري.

تستحق علامة جودة الخدمة في البايتة 1 اهتمامًا خاصًا ، حيث إنها تدعم الوظيفة المتغيرة التي تدعمها MQTT. تحتوي إشارات جودة الخدمة على القيم التالية استنادًا إلى نية الرسالة وإلحاحها:

  • 0 = ليس أكثر من مرة: يتم تشغيل الخادم ونسيانه. قد يتم فقد الرسائل أو تكرارها.
  • 1 = مرة واحدة على الأقل: يؤكد المستلم التسليم. يمكن تكرار الرسائل ، لكن التسليم مضمون
  • 2 = مرة واحدة بالضبط: يوفر الخادم التسليم. تصل الرسائل مرة واحدة تمامًا دون فقدها أو تكرارها

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

أين يمكنني استخدام MQTT؟


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

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

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

عندما لا تستخدم MQTT؟


للمطورين مجموعة واسعة من البروتوكولات لتصميم ونشر قنوات اتصال ثنائية الاتجاه IoT ، بما في ذلك MQTT و HTTP و CoAP و WebSockets (إذا كانت وحدة المعالجة المركزية / البطارية تسمح) وغيرها. ما إذا كان MQTT هو الخيار الأفضل يعتمد على الأجهزة ومهمة التطبيق.

مصمم لبيئات ذات عرض نطاق ترددي منخفض للغاية ، يمكن أن يكون بروتوكول MQTT غير مرن للغاية في سعيه لإنقاذ كل بايت. على سبيل المثال ، تحدد المواصفات خمس رسائل خطأ فقط يمكن للخادم رفض الاتصال بها (على سبيل المثال ، اسم مستخدم / كلمة مرور غير صالحة أو إصدار غير مقبول من البروتوكول). إذا كان الخادم يريد الإشارة إلى بعض الأخطاء الأخرى ، فسيكون ذلك محظوظًا. والأسوأ من ذلك ، إذا حدث خطأ بعد بدء الاتصال ، فلا توجد آلية للإبلاغ عن خطأ على الإطلاق. يمكن أن يتجاهل الخادم كتفيه وينهي اتصال TCP بشكل مفاجئ ، ويترك العميل دون أدنى فكرة عن سبب إسقاطه (ودون أي طريقة لتمييز الانفصال المتعمد عن مشكلة مؤقتة في الشبكة). بالنسبة للأشخاص الذين اعتادوا على بروتوكولات pub / sub (أكثر اقتصادا من حيث عرض النطاق الترددي) ، قد يبدو هذا الأسلوب Spartan بدائيًا قليلاً.

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

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

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

في الحالات التي يجب أن يتلقى فيها العملاء البيانات فقط ، تعتبر أحداث Server-Sent خيارًا مناسبًا أيضًا.

كيفية إعداد MQTT بسرعة


يحتوي مستودع MQTT على GitHub على قائمة واسعة من مكتبات MQTT مفتوحة المصدر بعدة لغات. فيما يلي مثالان للتخصيص باستخدام وسيط MQTT مفتوح المصدر ومكتبة JavaScript ومكتبة .NET.

الكسوف البعوض - مفتوح المصدر وسيط MQTT


Eclipse Mosquitto هو وسيط رسالة مفتوحة المصدر (EPL / EDL) يقوم بتنفيذ بروتوكولات MQTT الإصدار 5.0 و 3.1.1 و 3.1. إن Mosquitto خفيف الوزن ومناسب للاستخدام على جميع الأجهزة: من أجهزة الكمبيوتر ذات اللوحة أحادية منخفضة الطاقة إلى الخوادم الكاملة.

MQTT.js


MQTT.js هي مكتبة عميل لبروتوكول MQTT ، مكتوبة بلغة JavaScript لـ Node.js ومتصفح. فيما يلي مثال على إرسال رسالة باستخدام MQTT.js:

 var mqtt = require('mqtt') var client = mqtt.connect('mqtt://test.mosquitto.org') client.on('connect', function () { client.subscribe('presence', function (err) { if (!err) { client.publish('presence', 'Hello mqtt') } }) }) client.on('message', function (topic, message) { // message is Buffer console.log(message.toString()) client.end() }) 

MQTTnet


MQTTnet هي مكتبة .NET عالية الأداء توفر كل من العميل وخادم MQTT (وسيط).

تثبيت عميل MQTT:

 // Create a new MQTT client. var factory = new MqttFactory(); var mqttClient = factory.CreateMqttClient(); 

بعد تكوين إعدادات عميل MQTT ، يمكنك إنشاء اتصال. توضح التعليمة البرمجية التالية كيفية الاتصال بالخادم:

 // Use WebSocket connection. var options = new MqttClientOptionsBuilder() .WithWebSocketServer("broker.hivemq.com:8000/mqtt") .Build(); await client.ConnectAsync(options); 

تلقي الرسائل الواردة:

 client.UseApplicationMessageReceivedHandler(e => { Console.WriteLine("### RECEIVED APPLICATION MESSAGE ###"); Console.WriteLine($"+ Topic = {e.ApplicationMessage.Topic}"); Console.WriteLine($"+ Payload = {Encoding.UTF8.GetString(e.ApplicationMessage.Payload)}"); Console.WriteLine($"+ QoS = {e.ApplicationMessage.QualityOfServiceLevel}"); Console.WriteLine($"+ Retain = {e.ApplicationMessage.Retain}"); Console.WriteLine(); Task.Run(() => client.PublishAsync("hello/world")); }); 

نشر بعد:

 var message = new MqttApplicationMessageBuilder() .WithTopic("MyTopic") .WithPayload("Hello World") .WithExactlyOnceQoS() .WithRetainFlag() .Build(); await client.PublishAsync(message); 

راجع وثائق MQTTnet وويكي لمزيد من الأمثلة .

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

ماذا عن التحجيم؟


عندما يتعلق الأمر بتوسيع نطاق MQTT ، هناك اعتباران يجب مراعاتهما: 1) هل هذا هو البروتوكول الصحيح ؛ 2) بغض النظر عن اختيار البروتوكول ، ما هي البنية التحتية وقدرات الشبكة اللازمة للتعامل مع زيادة حركة المرور بين الأجهزة التي تستخدم MQTT.

الجهاز خفيف الوزن من آلة إلى آلة (LWM2M) هو بروتوكول آخر يمكن استخدامه مع MQTT على مستوى المؤسسة. بالمقارنة مع MQTT ، يكون في بعض الأحيان أكثر ملاءمة لأنظمة إنترنت الأشياء على المدى الطويل . تعتبر MQTT مناسبة بشكل مثالي للتشغيل التجريبي لـ IoT دون عناء ، بينما يوفر LWM2M ميزات للبنية التحتية طويلة المدى ومتعددة الاستخدامات. يوفر LWM2M أيضًا أدوات متفوقة لإدارة الأجهزة مثل مراقبة الاتصال وتحديثات البرامج الثابتة وإجراءات الجهاز عن بُعد. بالنسبة للشركات التي لديها عدد كبير من الأجهزة غير المدارة التي ترسل كميات كبيرة من البيانات إلى نظام أساسي مركزي ، فإن LWM2M هو الخيار الأفضل. ومع ذلك ، فإننا نتحدث عن عمليات النشر الواسعة النطاق لإنترنت الأشياء ، لذلك عادةً ما تكون MQTT أكثر من خيار مناسب. بالإضافة إلى ذلك ، تعد MQTT أكثر شيوعًا وتتمتع بدعم أوسع.

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

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

ما هو الوضع الحالي مع MQTT؟


في أبريل 2019 ، أصدرت OASIS MQTT v5.0 كمعيار رسمي. OASIS هو اتحاد غير ربحي يضم 600 منظمة عضو و 5000 عضو فردي .

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

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

للحصول على قائمة كاملة بميزات MQTT 5.0 الجديدة ، راجع الملحق C بالمعايير الرسمية.

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

MQTT و باقتدار


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

يوفر Ably وسيط ومحول بروتوكول MQTT مع ترجمة لبروتوكول Ably الخاص في كلا الاتجاهين ، مما يسمح لك بالتكامل مع أي أنظمة واتصالات موجودة. WebSockets المدعومة ، HTTP ، SSE ، gRPC (قيد التطوير) ، STOMP ، AMQP وغيرها من البروتوكولات لتنظيم البنية التحتية للرسائل الموزعة في الوقت الحقيقي. هناك أكثر من 40 مكتبة عميل SDK ودعم بروتوكولات الوقت الحقيقي الملكية.

Source: https://habr.com/ru/post/ar463669/


All Articles