وڊيو ڪميونيڪيشن Vimbox پليٽ فارم تي استاد ۽ شاگرد جي وچ ۾ رابطي جو مکيه طريقو آهي. اسان گهڻو وقت اڳ Skype کي ڇڏي ڏنو، ڪيترن ئي ٽئين پارٽي حل جي ڪوشش ڪئي ۽ آخرڪار WebRTC - Janus-gateway combination تي آباد ٿياسون. ڪجهه وقت لاءِ اسان هر شيءِ ۾ خوش هئاسين، پر پوءِ به ڪجهه منفي پهلو سامهون اچڻ لڳا. نتيجي طور، هڪ الڳ وڊيو هدايت ٺاهي وئي.
مون Kirill Rogovoy کان پڇيو، نئين هدايت جي سربراه، Skyeng تي ويڊيو ڪميونيڪيشن جي ارتقا بابت ڳالهائڻ لاءِ، دريافت ڪيل مسئلا، حل ۽ ڪچيون جيڪي اسان آخرڪار استعمال ڪيون. اسان کي اميد آهي ته مضمون انهن ڪمپنين لاءِ ڪارآمد ثابت ٿيندو جيڪي پڻ ويب ايپليڪيشن ذريعي پنهنجو پاڻ تي وڊيو ٺاهينديون آهن.
تاريخ جو هڪ سا
2017 جي اونهاري ۾، Skyeng ڊولپمينٽ جو سربراهه، سرجي صفونوف، Backend Conf تي هڪ ڪهاڻي سان ڳالهايو ته ڪيئن اسان "Skype کي ڇڏي ڏنو ۽ WebRTC تي عمل ڪيو." دلچسپي رکندڙ ماڻهو تقرير جي رڪارڊنگ ڏسي سگهن ٿا (~ 45 منٽ)، ۽ هتي آئون مختصر طور تي ان جو خلاصو بيان ڪندس.
Skyeng اسڪول لاءِ، وڊيو ڪميونيڪيشن هميشه استاد-شاگردن جي رابطي جو هڪ ترجيحي طريقو رهيو آهي. شروعات ۾، Skype استعمال ڪيو ويو، پر اهو واضح طور تي ڪيترن ئي سببن جي ڪري اطمينان بخش نه هو، بنيادي طور تي لاگ ان جي گهٽتائي ۽ سڌو سنئون ويب ايپليڪيشن ۾ انضمام جي ناممڪن سبب. تنهن ڪري، اسان سڀني قسمن جا تجربا ڪيا.
دراصل، وڊيو ڪميونيڪيشن لاءِ اسان جون گهرجون لڳ ڀڳ ھيون ھيون:
- استحڪام؛
- گهٽ قيمت في سبق؛
- رڪارڊنگ سبق؛
- ٽريڪنگ ڪير ڪيترو ڳالهائي ٿو (اهو اسان لاءِ اهم آهي ته شاگرد سبق دوران استاد کان وڌيڪ ڳالهائين)؛
- لڪير ماپڻ؛
- UDP ۽ TCP ٻنهي کي استعمال ڪرڻ جي صلاحيت.
2013 ۾ ٽوڪ باڪس کي لاڳو ڪرڻ جي ڪوشش ڪئي وئي. هر شي سٺي هئي، پر اهو تمام مهانگو ٿي ويو - 113 روبل في سبق - ۽ منافعو کائي.
ان کان پوء 2015 ۾، Voximplant ضم ڪيو ويو. هتي اهو فنڪشن هو جنهن کي اسان کي ٽريڪ ڪرڻ جي ضرورت هئي ته ڪير ڪيترو ڳالهائيندو هو، ۽ ساڳئي وقت حل تمام سستو هو: جيڪڏهن صرف آڊيو رڪارڊ ڪيو ويو، اهو هر سبق جي قيمت 20 روبل آهي. بهرحال، اهو صرف UDP ذريعي ڪم ڪيو ۽ TCP ڏانهن تبديل نه ٿي سگهيو. بهرحال، اٽڪل 40٪ شاگردن ان کي استعمال ڪندي ختم ڪيو.
هڪ سال بعد، اسان شروع ڪيو ڪارپوريٽ گراهڪ انهن جي پنهنجي مخصوص گهرجن سان. مثال طور، هر شي کي برائوزر ذريعي ڪم ڪرڻ گهرجي؛ ڪمپني صرف http ۽ https کوليندي آهي؛ يعني نه Skype يا UDP. ڪارپوريٽ گراهڪ = پئسا، تنهنڪري اهي ٽوڪ باڪس ڏانهن واپس آيا، پر قيمت جو مسئلو نه ٿيو.
حل - WebRTC ۽ جانس
استعمال ڪرڻ جو فيصلو ڪيو . اهو هڪ ڪنيڪشن قائم ڪرڻ، انڪوڊنگ ۽ ڊيڪوڊنگ اسٽريمز، هم وقت سازي ٽريڪز ۽ نيٽ ورڪ جي خرابين کي سنڀالڻ سان معيار ڪنٽرول ڪرڻ جو ذميوار آهي. اسان جي حصي لاء، اسان کي يقيني بڻائڻ گهرجي ته ڪئميرا ۽ مائڪروفون مان اسٽريمز پڙهڻ، وڊيو ڊرائنگ، ڪنيڪشن کي منظم ڪرڻ، هڪ WebRTC ڪنيڪشن قائم ڪرڻ ۽ ان کي اسٽريم منتقل ڪرڻ، انهي سان گڏ ڪنيڪشن قائم ڪرڻ لاءِ ڪلائنٽ جي وچ ۾ سگنلنگ پيغامن کي منتقل ڪرڻ (WebRTC پاڻ صرف بيان ڪري ٿو. ڊيٽا فارميٽ، پر ان جي ميکانيزم جي منتقلي نه). جيڪڏهن گراهڪ NAT جي پويان آهن، WebRTC STUN سرورز کي ڳنڍيندو آهي؛ جيڪڏهن اهو مدد نه ڪندو آهي، سرور کي ڦيرايو.
هڪ باقاعده p2p ڪنيڪشن اسان لاءِ ڪافي ناهي، ڇاڪاڻ ته اسان شڪايتن جي صورت ۾ وڌيڪ تجزيي لاءِ سبق رڪارڊ ڪرڻ چاهيون ٿا. تنهن ڪري اسان هڪ رلي ذريعي WebRTC اسٽريم موڪليندا آهيون . نتيجي طور، گراهڪ هڪ ٻئي جي پتا نه ڄاڻندا آهن، صرف جانس سرور ايڊريس ڏسي؛ اهو پڻ هڪ سگنل سرور جي ڪم کي انجام ڏئي ٿو. جانس وٽ ڪيتريون ئي خاصيتون آھن جن جي اسان کي ضرورت آھي: خودڪار طور تي TCP ڏانھن سوئچ ڪري ٿو جيڪڏھن ڪلائنٽ UDP بلاڪ ڪيو آھي؛ ٻئي UDP ۽ TCP اسٽريمز کي رڪارڊ ڪري سگھن ٿا؛ وڌائڻ لائق؛ گونج ٽيسٽ لاءِ پڻ هڪ بلٽ ان پلگ ان آهي. جيڪڏهن ضروري هجي ته، Twilio کان STUN ۽ TURN سرور خودڪار طور تي ڳنڍيل آهن.
2017 جي اونهاري ۾، اسان وٽ ٻه جانس سرور هلندڙ هئا، گڏوگڏ رڪارڊ ٿيل خام آڊيو ۽ وڊيو فائلن جي پروسيسنگ لاءِ هڪ اضافي سرور، ته جيئن مکيه وارن جي پروسيسرز تي قبضو نه ٿئي. جڏهن ڳنڍيندي، جانس سرورز کي بي ترتيب جي بنياد تي چونڊيو ويو (ڪنيڪشن نمبر). ان وقت، اهو ڪافي هو، اسان جي احساسن جي مطابق، اهو تقريبا چار گنا حفاظتي مارجن ڏنو، لاڳو ڪرڻ جو سيڪڙو اٽڪل 80 هو. ساڳئي وقت، قيمت گھٽائي وئي ~ 2 روبل في سبق، گڏوگڏ ترقي ۽ مدد.
وڊيو ڪميونيڪيشن جي موضوع ڏانهن واپسي
اسان بروقت مسئلن جي نشاندهي ڪرڻ ۽ درست ڪرڻ لاءِ شاگردن ۽ استادن جي راءِ جي مسلسل نگراني ڪندا آهيون. 2018 جي اونهاري تائين، ڪال معيار مضبوط طور تي شڪايتن جي وچ ۾ پهرين جڳهه تي هئي. هڪ طرف، ان جو مطلب اهو هو ته اسان ڪاميابيء سان ٻين گهٽتائي تي غالب ٿي چڪا آهيون. ٻئي طرف، اهو ضروري هو ته فوري طور تي ڪجهه ڪيو وڃي: جيڪڏهن سبق ۾ خلل پوي ٿو، اسان کي ان جي قيمت وڃائڻ جو خطرو آهي، ڪڏهن ڪڏهن ايندڙ پيڪيج جي خريداري جي قيمت سان گڏ، ۽ جيڪڏهن تعارفي سبق ۾ خلل پوي ٿو، اسان کي هڪ امڪاني گراهڪ کي وڃائڻ جو خطرو آهي. مجموعي طور تي.
ان وقت، اسان جي وڊيو ڪميونيڪيشن اڃا تائين MVP موڊ ۾ هئي. سادي لفظ ۾، انهن ان کي شروع ڪيو، اهو ڪم ڪيو، انهن ان کي هڪ ڀيرو وڌايو، اهي سمجهي رهيا هئا ته اهو ڪيئن ڪجي - سٺو، عظيم. جيڪڏهن اهو ڪم ڪري، ان کي درست نه ڪريو. ڪنهن به ڄاڻي واڻي رابطي جي معيار جي مسئلي کي خطاب نه ڪيو. آگسٽ تائين، اهو واضح ٿي ويو ته اهو جاري نه ٿو رهي سگهي، ۽ اسان اهو معلوم ڪرڻ لاءِ هڪ الڳ هدايت شروع ڪئي ته WebRTC ۽ Janus سان ڇا غلط هو.
ان پٽ تي، هي هدايت ملي ٿي: هڪ MVP حل، نه ميٽرڪس، نه مقصد، نه بهتري لاءِ ڪو به عمل، جڏهن ته 7٪ استادن ڪميونيڪيشن جي معيار بابت شڪايت ڪن ٿا (شاگردن تي ڪا به ڊيٽا نه هئي).
هڪ نئون رخ جاري آهي
حڪم ڪجهه هن طرح نظر اچي ٿو:
- ڊپارٽمينٽ جو سربراهه، جيڪو پڻ مکيه ترقي ڪندڙ آهي.
- QA تبديلين کي جانچڻ ۾ مدد ڪري ٿو، غير مستحڪم مواصلاتي حالتون پيدا ڪرڻ لاء نوان طريقا ڳولي ٿو، ۽ اڳئين لائن کان مسئلن جي رپورٽ ڪري ٿو.
- تجزيه نگار مسلسل ٽيڪنيڪل ڊيٽا ۾ مختلف لاڳاپن کي ڳولي ٿو، صارف جي راءِ جي تجزيو کي بهتر بڻائي ٿو، ۽ تجربن جي نتيجن کي چيڪ ڪري ٿو.
- پراڊڪٽ مينيجر تجربن لاءِ وسيلن جي مجموعي هدايت ۽ مختص ڪرڻ ۾ مدد ڪري ٿو.
- هڪ ٻيو ڊولپر اڪثر ڪري پروگرامنگ ۽ لاڳاپيل ڪمن سان مدد ڪري ٿو.
شروع ڪرڻ لاءِ، اسان ھڪ نسبتاً قابل اعتماد ميٽرڪ قائم ڪيو آھي جيڪو رابطي جي معيار جي جائزي ۾ تبديلين کي ٽريڪ ڪري ٿو (اوسط ڏينھن، ھفتي، مھينن ۾). ان زماني ۾، اهي استادن جا گريڊ هئا؛ بعد ۾ شاگردن جا گريڊ انهن ۾ شامل ڪيا ويا. پوءِ انهن مفروضن کي ٺاهڻ شروع ڪيو ته ڇا غلط ڪم ڪري رهيو هو، ان کي درست ڪريو، ۽ متحرڪ تبديلين کي ڏسو. اسان وياسين گھٽ لٽڪندڙ ميوو لاءِ: مثال طور، اسان vp8 ڪوڊيڪ کي vp9 سان تبديل ڪيو، ڪارڪردگي بهتر ٿي. اسان جينس سيٽنگن سان راند ڪرڻ جي ڪوشش ڪئي ۽ ٻين تجربن کي منظم ڪرڻ جي ڪوشش ڪئي - اڪثر ڪيسن ۾ انهن کي ڪجهه به نه ڏنو.
ٻئي مرحلي تي، هڪ مفروضو سامهون آيو: WebRTC هڪ پير کان پيئر حل آهي، ۽ اسان وچ ۾ هڪ سرور استعمال ڪندا آهيون. شايد مسئلو هتي ئي آهي؟ اسان کوٽڻ شروع ڪيو ۽ هن وقت تائين سڀ کان اهم سڌارو مليو.
ان وقت، پول مان ھڪڙو سرور ھڪڙو بيوقوف الورورٿم استعمال ڪندي چونڊيو ويو: ھر ھڪ جو پنھنجو "وزن" ھو، چينل ۽ طاقت تي منحصر آھي، ۽ اسان صارف کي ھڪڙي وڏي "وزن" سان گڏ موڪلڻ جي ڪوشش ڪئي. ڌيان ڏيڻ جتي صارف جغرافيائي طور تي واقع هو. نتيجي طور، سينٽ پيٽرسبرگ جو هڪ استاد سائبيريا جي هڪ شاگرد سان ماسڪو ذريعي رابطو ڪري سگهي ٿو، ۽ سينٽ پيٽرسبرگ ۾ اسان جي جانس سرور ذريعي نه.
الورورٿم ٻيهر ڪيو ويو آهي: هاڻي، جڏهن ڪو صارف اسان جي پليٽ فارم کي کوليندو آهي، اسان هن کان پنگ گڏ ڪندا آهيون سڀني سرورن ڏانهن Ajax استعمال ڪندي. جڏهن هڪ ڪنيڪشن قائم ڪيو وڃي، اسان پنگ جو هڪ جوڙو چونڊيو (استاد-سرور ۽ شاگرد-سرور) ننڍي رقم سان. گھٽ پنگ جو مطلب آھي سرور تائين گھٽ نيٽ ورڪ فاصلو؛ ننڍو فاصلو مطلب آهي پيڪٽ وڃائڻ جو گهٽ امڪان؛ وڊيو ڪميونيڪيشن ۾ پيڪٽ جو نقصان سڀ کان وڏو منفي عنصر آهي. منفيات جو حصو ٽن مهينن ۾ اڌ کان گهٽجي ويو (منصفانه هجڻ لاء، هن وقت ٻيا تجربا ڪيا ويا، پر اهو تقريبا ضرور تمام گهڻو اثر پيو).
اسان تازو دريافت ڪيو هڪ ٻيو غير واضع، پر ظاهري طور تي اهم شيءِ: هڪ موڙي چينل تي هڪ طاقتور جانس سرور جي بدران، اهو بهتر آهي ته ٻه آسان آهن پتلي بينڊوڊٿ سان. اها ڳالهه تڏهن واضح ٿي وئي جڏهن اسان طاقتور مشينون خريد ڪيون ته ان اميد ۾ ته ڪيترن ئي ڪمرن (ڪميونيڪيشن سيشنز) ۾ هڪ ئي وقت ڀرجي. سرورز وٽ بينڊوڊٿ جي حد آھي، جنھن کي اسين ڪمرن جي تعداد ۾ صحيح ترجمو ڪري سگھون ٿا - اسان ڄاڻون ٿا ته ڪيترا کوليا سگھجن ٿا، مثال طور، 300 Mbit/s تي. جيئن ئي سرور تي تمام گھڻا ڪمرا کليل آھن، اسان ان کي نون سرگرمين لاءِ چونڊڻ بند ڪريون ٿا جيستائين لوڊ گھٽ نه ٿئي. خيال اهو هو ته، هڪ طاقتور مشين خريد ڪري، اسان چينل کي ان کي وڌ ۾ وڌ لوڊ ڪنداسين، ته جيئن آخر ۾ اهو پروسيسر ۽ ميموري طرفان محدود هوندو، ۽ بينڊوڊٿ طرفان نه. پر اهو معلوم ٿيو ته کليل ڪمرن جي هڪ خاص تعداد (420) کان پوء، حقيقت اها آهي ته پروسيسر، ميموري ۽ ڊسڪ تي لوڊ اڃا تائين حد کان تمام پري آهي، منفيات ٽيڪنيڪل سپورٽ تي پهچڻ شروع ٿئي ٿو. بظاهر، جانس جي اندر ڪجهه خراب ٿي رهيو آهي، شايد اتي به ڪجهه پابنديون آهن. اسان تجربو شروع ڪيو، بينڊوڊٿ جي حد کي 300 کان 200 Mbit/s تائين گھٽ ڪيو، ۽ مسئلا ختم ٿي ويا. ھاڻي اسان ھڪ ئي وقت ٽي نوان سرور خريد ڪيا آھن گھٽ حدن ۽ خاصيتن سان، اسان سمجھون ٿا ته اھو ڪميونيڪيشن جي معيار ۾ مستحڪم سڌارو آڻيندو. يقينن، اسان اهو معلوم ڪرڻ جي ڪوشش نه ڪئي ته اتي ڇا ٿي رهيو آهي؛ اسان جون ڪچيون سڀ ڪجهه آهن. اسان جي دفاع ۾، اچو ته اهو چوڻ گهرجي ته ان وقت اهو ضروري هو ته جلدي ممڪن طور تي دٻاء واري مسئلي کي حل ڪرڻ، ۽ ان کي خوبصورت طور تي نه ڪرڻ؛ ان کان سواء، جانس اسان جي لاء هڪ بليڪ باڪس آهي جيڪو C ۾ لکيل آهي، ان سان ٽڪرائڻ تمام مهانگو آهي.
خير، عمل ۾ اسان:
- سڀني انحصار کي اپڊيٽ ڪيو جيڪو اپڊيٽ ٿي سگهي ٿو، ٻئي سرور تي ۽ ڪلائنٽ تي (اهي پڻ تجربا هئا، اسان نتيجن جي نگراني ڪئي)؛
- مخصوص ڪيسن سان لاڳاپيل سڀني سڃاتل بگ کي درست ڪيو، مثال طور، جڏهن ڪنيڪشن ختم ٿي ويو ۽ خودڪار طور تي بحال نه ٿيو؛
- اسان ويڊيو ڪميونيڪيشن جي شعبي ۾ ڪم ڪندڙ ڪمپنين سان ڪيتريون ئي گڏجاڻيون ڪيون ۽ اسان جي مسئلن کان واقف آهيون: اسٽريمنگ گيمز، ويبنرز کي منظم ڪرڻ؛ اسان هر شيء جي ڪوشش ڪئي جيڪا اسان لاء مفيد لڳي؛
- استادن جي هارڊويئر ۽ ڪميونيڪيشن جي معيار جو ٽيڪنيڪل جائزو ورتو، جن کان سڀ کان وڌيڪ شڪايتون آيون.
تجربن ۽ بعد ۾ ڪيل تبديلين استادن جي وچ ۾ رابطي جي عدم اطمينان کي جنوري 7,1 ۾ 2018٪ مان جنوري 2,5 ۾ 2019٪ تائين گھٽائڻ ممڪن بڻايو.
ايندڙ ڇا آهي
اسان جي Vimbox پليٽ فارم کي مستحڪم ڪرڻ 2019 لاءِ ڪمپني جي مکيه منصوبن مان هڪ آهي. اسان کي وڏيون اميدون آهن ته اسان رفتار کي برقرار رکڻ جي قابل ٿي وينداسين ۽ هاڻي مٿين شڪايتن ۾ وڊيو مواصلات نه ڏسندا. اسان سمجهون ٿا ته انهن شڪايتن جو هڪ اهم حصو صارفين جي ڪمپيوٽرن ۽ انٽرنيٽ ۾ دير سان لاڳاپيل آهي، پر اسان کي اهو حصو طئي ڪرڻ گهرجي ۽ باقي حل ڪرڻ گهرجي. باقي سڀ ڪجهه هڪ ٽيڪنيڪل مسئلو آهي، لڳي ٿو ته اسان کي ان کي منهن ڏيڻ گهرجي.
بنيادي ڏکيائي اها آهي ته اسان کي خبر ناهي ته معيار کي بهتر ڪرڻ اصل ۾ ڪهڙي سطح تي ممڪن آهي. هن ڇت کي ڳولڻ بنيادي ڪم آهي. تنهن ڪري، ٻه تجربا منصوبا ڪيا ويا:
- جنگي حالتن ۾ باقاعده p2p سان Janus ذريعي ويڊيو جو مقابلو ڪريو. هي تجربو اڳ ۾ ئي ڪيو ويو آهي، اسان جي حل ۽ p2p جي وچ ۾ ڪوبه شمارياتي لحاظ کان اهم فرق نه مليو.
- اچو ته انهن ڪمپنين کان (مهانگي) خدمتون فراهم ڪريون جيڪي پئسا ڪمائينديون آهن خاص طور تي وڊيو ڪميونيڪيشن حلن تي، ۽ انهن مان ناڪاري جي مقدار کي موجوده هڪ سان ڀيٽيون.
اهي ٻه تجربا اسان کي هڪ قابل مقصد مقصد جي نشاندهي ڪرڻ ۽ ان تي ڌيان ڏيڻ جي اجازت ڏين ٿا.
ان کان سواء، اتي ڪيترائي ڪم آھن جيڪي باقاعده حل ڪري سگھجن ٿيون:
- اسان موضوعي جائزو جي بدران رابطي جي معيار جو هڪ ٽيڪنيڪل ميٽرڪ ٺاهيو؛
- اسان وڌيڪ تفصيلي سيشن لاگز ٺاهيندا آهيون وڌيڪ صحيح طور تي تجزيو ڪرڻ لاءِ ناڪامين جو وڌيڪ صحيح تجزيو ڪرڻ لاءِ، سمجهون ته اهي ڪڏهن ۽ ڪٿي واقعا پيش آيا، ۽ ان وقت ڪهڙا بظاهر غير لاڳاپيل واقعا پيش آيا؛
- اسان سبق کان اڳ هڪ خودڪار ڪنيڪشن جي معيار جو امتحان تيار ڪريون ٿا، ۽ ڪلائنٽ کي دستي طور تي ڪنيڪشن کي جانچڻ جو موقعو پڻ ڏيون ٿا ته جيئن هن جي هارڊويئر ۽ چينل جي ڪري ناڪاري جي مقدار کي گھٽايو وڃي؛
- اسان ترقي ڪنداسين ۽ وڌيڪ ويڊيو ڪميونيڪيشن لوڊ ٽيسٽون خراب حالتن ۾، متغير پيڪٽ نقصان، وغيره سان.
- اسان سرور جي رويي کي تبديل ڪريون ٿا مسئلن جي صورت ۾ غلطي رواداري کي وڌائڻ لاء؛
- اسان صارف کي ڊيڄارينداسين ته جيڪڏهن هن جي ڪنيڪشن ۾ ڪجهه غلط آهي، جيئن Skype ڪري ٿو، ته جيئن هو سمجهي ته مسئلو هن جي پاسي آهي.
اپريل کان وٺي، وڊيو ڪميونيڪيشن جي هدايت Skyeng جي اندر هڪ مڪمل الڳ الڳ منصوبو بڻجي چڪو آهي، پنهنجي پروڊڪٽ سان معاملو ڪندي، نه رڳو Vimbox جو هڪ حصو. ان جو مطلب اهو آهي ته اسان ماڻهن کي ڳولڻ شروع ڪري رهيا آهيون . خير، هميشه وانگر .
۽، يقينا، اسان فعال طور تي ماڻهن ۽ ڪمپنين سان ڪم ڪندڙ ويڊيو ڪميونيڪيشن سان ڪم ڪرڻ جاري رکون ٿا. جيڪڏهن توهان چاهيو ٿا ته اسان سان تجربو مٽايو، اسان کي خوشي ٿيندي! تبصرو، رابطي ۾ حاصل ڪريو - اسان سڀني کي جواب ڏينداسين.
جو ذريعو: www.habr.com