المقدمة

السلام عليكم دي مشاكل واجهتنا في تصميم service streaming تستوفي هذه الشروط:

1. تستخدم كمية محدودة من ال resources، وده لأنها هتشتغل بجانب services أخرى أكثر استهلاكًا لل resources، وكان لازم نحافظ علي معدل استهلاك = 4CPU Core Max.
2. تكون معزولة عن بقية الخدمات (isolation from other services) ده معناه إنها هتتعامل مع الـ outputs بتاع الـ services التانية زي الـ folders without direct communication with other services.
3. هذه ال service تسمح لل Client أنه يسمع علي ال stream سواء extra... ,web browser mobile application native.
4. مصدر البيانات protocol UDP، وممكن يتم القراءة عن ال protocol network ده، لكن باختصار هو مبينتظرش ل acknowledge messages من الClient) يعني الي راح راح بالبلدي (شوية messages يوصولو وشوية لاء)، يعني Data فيها مشاكل.

Streaming Solution

1. نستخدم file watcher لاكتشاف أي تغييرات في مصدر البيانات (source data) والتكيّف معها.
   بمعنى إننا نقرأ الداتا من المصدر الأساسي (services) ونقوم بإخراجها في الـ output folder النهائي.
2. الخطوة التانية إننا نستخدم ما يُعرف بـ healing لستريم الداتا اللي جاية من الـ file watcher.
   وده معناه إننا نستخدم media engine (زي ffmpeg) لإعادة الـ encode / decode للبيانات (codecs).
   والهدف هنا إننا نقدر نعيد ترميز الداتا بحيث لو مفيش sound في فريم معين (مثلاً أثناء streaming over UDP) بسبب فقدان بعض الحزم (packets) من الشبكة، ففي الحالة دي نعرض الفيديو على الأقل — والعكس صحيح لو الفقد كان في الفيديو فقط. يعني بمعنى أصح: نحاول نتدارك ما يمكن تداركه من البيانات المفقودة.

TCP Challenges

وهنا بييجي السؤال
ليه أصلًا من البداية ما استخدمناش بروتوكول بيعتمد على acknowledge / wait / resend زي TCP لتفادي فقد البيانات؟

السبب هو:

• الـ Low latency: إحنا بنهدف إلى تقليل الـ latency قدر الإمكان لتحقيق real-time streaming.
• اخترنا real-time streaming وتقبلنا احتمالية فقد بعض الفريمات (frame drops) كأمر طبيعي، زي اللي بيحصل في تطبيقات زي Zoom لما الشبكة تضعف مؤقتًا.

استخدام الـ Media Engine

استخدمنا open source media engine (اسمه Oven) لتوليد (generate) الـ streaming،
اللي بيتم عرضه على endpoints نقدر نستمع منها بأي client.

الـ engine ده بيقوم بعملية healing للبيانات اللي جاياله، وبيستقبل ويُصدر على ports مختلفة حسب البروتوكول:

• WebRTC على المنفذ 3334
• LL-HLS على المنفذ 3333

ليه استعملنا الـ Engine ده ؟

الـ engine المستخدم بيحقق كفاءة عالية، حيث لا يحتاج لأكثر من 2 CPU cores فقط، وده مناسب جدًا لحالتنا.

Final Architecture

(انظر المخططات أدناه)

الهدف من الـ approach ده هو توضيح حل مشكلة وبناء خدمة streaming resilient يمكن الاعتماد عليها في بيئة إنتاجية، مع استخدام أقل قدر ممكن من الموارد (resource-efficient streaming service).

Sequence Diagram

Isolation and Resource Constraints

Output Protocols