rtmfp cpp
Version 1.5.1
هذا هو تطبيق C ++ (11) لبروتوكول تدفق الوسائط الآمن في الوقت الفعلي (RTMFP) كما هو موضح في RFC 7016.
تتضمن المكتبة محولات منصة العينات وغيرها من المرافق ، مثل حلقة التشغيل select() ، ولكن لا يلزم استخدامها. يهدف تطبيق البروتوكول إلى أن يكون قابلاً للتكيف مع أي بيئة برنامج مضيفة.
المكتبة مخصصة للعملاء والخوادم وتطبيقات P2P. ويشمل المساعدين اللازمة وسنانير رد الاتصال لدعم مقدمة P2P وموازنة التحميل.
يتضمن دليل test اختبارات الوحدة والأمثلة. تجدر الإشارة إلى tcserver ، خادم وسائط LIVE SIMPLE RTMFP و RTMP ؛ tcrelay ، RTMFP ↔︎ RTMP Relay/Proxy ؛ وإعادة redirector ، موازن تحميل بسيط.
توجد وثائق API الأكثر اكتمالا حاليًا في ملف رأس rtmfp.hpp .
سيقوم أحد التطبيقات بتثبيت IPlatformAdapter و ICryptoAdapter ، ثم com::zenomt::rtmfp::RTMFP (الذي يتطلب هذه المحولات). عادةً ما يجب إخبار محول النظام الأساسي عن مثيل RTMFP الجديد حتى يتمكن من استدعاء أساليب منصة المثيل (مثل howLongToSleep() و onReceivePacket() ).
سيضيف النظام الأساسي واجهة واحدة على الأقل عن طريق الاتصال RTMFP::addInterface() .
يمكن للتطبيق فتح تدفقات إرسال إلى نقاط النهاية الجديدة أو الحالية مع RTMFP::openFlow() و Flow::openFlow ، ويمكن فتح تدفقات الإرجاع المرتبطة مع RecvFlow::openReturnFlow() .
يمكن للتطبيق قبول التدفقات الجديدة عن طريق ضبط عوائق onRecvFlow على RTMFP (للتدفقات الواردة العارية) أو على SendFlow S (لتدفقات الإرجاع المرتبطة).
يمكن للتطبيق إرسال رسائل إلى أقرانها البعيدة باستخدام SendFlow::write() ، وتلقي الرسائل من أقرانها البعيدة عن طريق تعيين رد اتصال onMessage على RecvFlow s. يمكن أن تنتهي صلاحية الرسائل والتخلي عنها إذا لم يتم تشغيلها أو تسليمها بواسطة المواعيد النهائية لكل وسيلة ، أو عن طريق منطق التطبيق التعسفي باستخدام WriteReceipt S الذي تم إرجاعه بواسطة SendFlow::write() . يمكن إخطار التطبيق عن طريق رد الاتصال عند تسليم الرسالة أو التخلي عنها.
يعتبر SendFlow s على الأولوية/الأسبقية PRI_PRIORITY ، PRI_IMMEDIATE ، PRI_FLASH ، أو PRI_FLASHOVERRIDE وقتًا بالغ الأهمية. يؤدي إرسال الرسائل الحرجة للوقت إلى السيطرة على الازدحام.
عند الانتهاء من ذلك ، يمكن للتطبيق إغلاق RTMFP بطريقة منظمة أو فجأة.
تنفيذ البروتوكول أحادي الخيوط وليس له أقفال/طفرات. يجب مزامنة جميع المكالمات إلى واجهات برمجة التطبيقات الخاصة بها خارجيًا ، على سبيل المثال من خلال كل شيء في نفس الخيط أو بنية تشبه الحلقة. تم ذلك لتحسين قابلية النقل والأداء ، لأن القفل يمكن أن يكون مكلفًا للغاية على وحدات المعالجة المركزية الحديثة. يتم تجريد التزامن بواسطة طريقة perform محول النظام الأساسي للسماح بتفريغ بعض العمليات باهظة الثمن أو تستغرق وقتًا طويلاً إلى النوى/المواضيع الأخرى ، إذا رغبت في ذلك.
لا يتفاعل تطبيق البروتوكول بشكل مباشر مع مآخذ UDP لنظام التشغيل أو الساعة أو الحلقات تشغيل أو أقفال أو مؤشرات ترابط. يتم استخلاص هذه التفاعلات إلى محول النظام الأساسي الذي يقدمه البرنامج المضيف.
سيكون محول المنصة بمثابة تطبيق ملموس لـ com::zenomt::rtmfp::IPlatformAdapter ، الذي يطلق على أساليب المثيلات العامة RTMFP في قسم "المستخدم بواسطة محول النظام الأساسي". يوفر المحول الوقت الحالي والقراءة والكتابة للمآخذ والتوقيت والمزامنة.
توفر المكتبة محولات منصة مثالين يتم تشغيلها في RunLoop S: PosixPlatformAdapter للتطبيقات المفردة المفردة ، و PerformerPosixPlatformAdapter للسماح بإلغاء تحميل تشفير المفتاح العام المكثف في وحدة المعالجة المركزية إلى مؤشر ترابط العامل. يجب أن تكون محولات المنصات هذه مناسبة للعديد من التطبيقات حول أنظمة التشغيل التي تشبه UNIX ويجب أن تكون بمثابة أمثلة على كيفية كتابة محولات منصات واحدة متتالية ومتعددة الخيوط لتطبيقك المضيف.
لا يوجد أي شرط لواجهات محول المنصة لتكون مآخذ UDP. على سبيل المثال ، يمكن أن تكون الواجهة جواربًا أو تحويلًا للمحاكاة أو النفق أو الشبكة.
بالنسبة لأنظمة التشغيل التي تشبه UNIX ، توفر هذه المكتبة حلقة تشغيل select() قائمة بسيطة مناسبة للعديد من التطبيقات المستندة إلى المقبس. ويتضمن أيضًا حلقة تشغيل بسيطة تستند إلى epoll لـ Linux والتي تحدد أفضل من select() للتعامل مع العديد من المقابس. استخدم الاسم PreferredRunLoop للاختيار تلقائيًا أفضل متغير متاح في وقت الترجم لنظام التشغيل المستهدف.
يمكن توصيل Performer بحلقة تشغيل لتمكين التذرع بمهمة داخل/متزامنة مع حلقة التشغيل من أي مؤشر ترابط. يتم استخدام Performer S مع PerformerPosixPlatformAdapter .
Microsoft Windows ليس منصة مدعومة رسميًا . ومع ذلك ، يجب أن تبني المكتبة الأساسية (باستثناء محولات النظام الأساسي ، وحلقات التشغيل ، Performer ) على النوافذ ، وسيتم محاولة صيانة جوهر هذا النظام الأساسي كوقت ومساعدة من المجتمع يسمح بذلك. يرجى فتح مشكلة إذا كانت هناك مشكلة في المكتبة الأساسية على Windows.
لاستخدام هذه المكتبة على Windows ، ستحتاج إلى توفير محول منصة مناسب.
يرجى الاتصال بالمؤشر أو فتح مشكلة لطلب رابط إلى محول Windows Platform لإضافته هنا في هذا المستند.
يصف RFC 7016 إطارًا معممًا لتأمين اتصال RTMFP وفقًا لاحتياجات التطبيق ، ويترك تفاصيل التشفير إلى ملف تعريف التشفير . لا تقفل هذه المكتبة تطبيقها على أي ملف تعريف تشفير معين ، ويتم كتابته لدعم العديد من الملفات الشخصية المحتملة. يتم تنفيذ ملف تعريف التشفير من قبل ICryptoAdapter الخرسانة المقدمة إلى RTMFP على مثيل.
ستستخدم معظم تطبيقات RTMFP ملف تعريف التشفير للاتصالات الفلاش الموصوفة في RFC 7425. يتم توفير هذا بواسطة FlashCryptoAdapter . لاحظ أن هذا المحول مجردة ويجب أن يكون فئات فرعية لتوفير تطبيقات ملموسة للبدائل التشفير المطلوبة. يتم توفير تطبيق ملموس باستخدام OpenSSL بواسطة FlashCryptoAdapter_OpenSSL ، والذي يمكن أن يكون أيضًا مثالًا على كيفية استخدام مكتبات التشفير الأخرى. إذا لم يكن لديك OpenSSL أو كنت لا ترغب في استخدامه ، فيمكنك قمع بناء هذه الوحدة عن طريق تحديد make Dariable WITHOUT_OPENSSL . إذا تم تثبيت OpenSSL خارج مسارات البحث الافتراضية للمترجم الخاص بك ، فيمكنك تحديد متغيرات make OPENSSL_INCLUDEDIR و OPENSSL_LIBDIR مع التوجيهات المناسبة (انظر Makefile للحصول على أمثلة).
ينفذ تطبيق OpenSSL لـ FlashCryptoAdapter Group 16 ، Group 16 ، 2048-BIT Group 14 ، و 1024-Bit IKE Group 2 للحصول على اتفاقية مفتاح Diffie-Hellman. يجب أن تنفذ جميع تطبيقات ملف تشفير Flash Communication على الأقل المجموعة 2 ؛ يقوم البعض أيضًا بتنفيذ المجموعة 14. هذا التنفيذ يفضل أقوى مجموعة مشتركة.
لاحظ أن RTMFP لا يقتصر على اتصال Flash Platform. توفر هذه المكتبة عبارة عن PlainCryptoAdapter مناسبة للاختبار والتقييم. نظرًا لأنه لا يوفر أي تشفير فعلي (وطرق cryptoHash256() وطرق pseudoRandomBytes() ضعيفة بشكل خاص) ، فهي ليست مناسبة لاستخدام الإنتاج في الإنترنت المفتوح. لا.
يمكن أن يسبب BufferBloat (التخزين المؤقت المفرط في الشبكة) تأخيرات رفيعة المستوى مما يؤدي إلى أداء غير مقبول للتطبيقات في الوقت الفعلي. لسوء الحظ ، لا يتم نشر أفضل حل لهذه المشكلة (إدارة قائمة الانتظار النشطة مع إشعار الازدحام الصريح) على الإنترنت في هذا الوقت.
بالإضافة إلى إشارات الازدحام العادية (الخسارة وإخطار الازدحام الصريح) ، يمكن لهذه المكتبة استنتاج الازدحام المحتمل اختياريًا في جلسة من الزيادات في وقت الرحلة المستديرة (RTT). لتمكين هذه القدرة ، استخدم Flow::setSessionCongestionDelay() لوضع كمية من التأخير الإضافي فوق RTT الأساسي المراد تفسيره على أنه مؤشر على الازدحام. القيمة الافتراضية هي INFINITY . تقترح قيمة 0.1 ثانية من التأخير الإضافي لهذه الميزة.
RTT الأساسي هو الحد الأدنى لـ RTT الذي لوحظ في الدقائق الثلاث الماضية على الأكثر. يتم مسح نافذة مراقبة RTT الأساسية وإعادة ضبطها في الظروف التالية:
من وقت لآخر ، إذا تم استخدام جزء كبير من نافذة الازدحام ، فسيتم تقليل نافذة الازدحام مؤقتًا من أجل التحقيق في مسار RTT الأساسي الجديد (في حالة إخفاء إرسالنا الأساسي). لاحظ أن هذا يمكن أن يسبب الارتعاش.
إذا لوحظ أن RTT الملساء هو أعلى من خط الأساس بالإضافة إلى CongestionDelay المكون (وهو أيضًا 30 مللي ثانية على الأقل) ، فمن المفترض أن يكون هذا مؤشراً على الازدحام. يستجيب مراقب الازدحام إلى هذا كما لو كان خسارة.
مخطط الكشف عن الازدحام هذا ، مثله مثل كل ما يعتمد على التأخير الشامل ، غير كامل ، ويخضع للإشارات الإيجابية الخاطئة الناجمة عن حالات تشمل:
على هذا النحو ، قد لا يتم الإشارة إلى هذه الميزة لجميع حالات الاستخدام. يجب توخي الحذر لتمكين هذه الميزة فقط عندما تكون إشارات الازدحام الإيجابية الخاطئة غير مرجحة ، مثل نقل وسائل الإعلام غير الاتجاهية بشكل كبير من خلال عنق الزجاجة المخصص. الإيجابيات الخاطئة يمكن أن تسبب جوع انتقال.
هذه الميزة مستوحاة من نقل خلفية التأخير الإضافي المنخفض (LEDBAT) ، والتكيف المعدل ذاتيًا للوسائط المتعددة (SCREAM) ، وخوارزمية التحكم في احتقان BBR من Google.
يضيف تنفيذ RTMFP دعمًا لإخطار الازدحام الصريح (ECN). يضيف قطعة تجريبية جديدة "تقرير ECN" (النوع 0xec ) للمستقبل لإرسال عدد من نقاط CodePoints المستلمة ECN إلى مرسل ECN. يجب ألا يرسل RTMFP تقرير ECN إلى نظيره ما لم تتلق حزمة واحدة صالحة على الأقل في جلسة S_OPEN الخاصة بها مع هذا النظير الذي يتميز بنقطة رمز نقل ECN ( ECT(0) أو ECT(1) أو ECN-CE ).
يرسل جهاز استقبال RTMFP الذي يمكن أن يكون قادرًا على ECN تقارير ECN إلى نظيره القادر على ECN. يجب تجميع تقارير ECN قبل الجزء الأول من الإقرار في أي حزمة تحتوي على إقرار (لتجنب اقتطاع التقرير). من أجل أن يتمكن المرسل ECN من اكتشاف ما إذا كان الواجهات القريبة والمسار ، و Path ، و Sectiver Support ECN ، يجب أن يرسل جهاز استقبال قادر على ECN تقرير ECN في أي حزمة تحتوي على إقرار ، إذا لم يتم إرسال أي حزمة تحمل علامة مع نقطة نقل ECN إما منذ آخر مرة تم إرسال تقرير ECN أو إذا لم يتم إرسال تقرير.
يجب على مرسل RTMFP إيقاف وضع علامة على الحزم مع نقاط رمز النقل القادرة على ECN إذا قرر أن المتلقي غير قادر على ECN (على سبيل المثال ، إذا لم يتلق المرسل تقرير ECN واحد على الأقل مع إقرار لبيانات المستخدم التي تم إرسالها في حزمة ملحوظة أثناء الجلسة المفتوحة مع الأقران).
يحتفظ جهاز استقبال RTMFP القادر على ECN على الأقل بعدد الحزم المستلمة مع ECN-CE . ترسل نقطة النهاية 8 بتات منخفضة من العداد الحالي إلى نظيرها في قطع تقرير ECN.
هذا التنفيذ يرسل ECT(0) . يستجيب وحدة تحكم الازدحام لزيادات ECN-CE-count كما لو كانت خسارة. يتم إرسال ECT(0) فقط على حزم تحتوي على بيانات المستخدم.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xec | 1 | ECN-CE-count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
struct ecnReportChunkPayload_t
{
uint8_t congestionExperiencedCountMod256; // ECN-CE-count
} :8;
congestionExperiencedCountMod256 : منخفض 8 بت من عدد الحزم التي تم استلامها من النظير المميز بـ ECN-CE (احتقان ECN). 
