ویڈیو کمیونیکیشن Vimbox پلیٹ فارم پر استاد اور طالب علم کے درمیان رابطے کا بنیادی طریقہ ہے۔ ہم نے کافی عرصہ پہلے Skype کو ترک کر دیا، کئی فریق ثالث حل آزمائے اور بالآخر WebRTC - Janus-gateway مجموعہ پر طے پا گئے۔ کچھ عرصے تک ہم ہر چیز سے خوش رہے لیکن پھر بھی کچھ منفی پہلو سامنے آتے رہے۔ نتیجے کے طور پر، ایک علیحدہ ویڈیو سمت بنایا گیا تھا.
میں نے نئی سمت کے سربراہ Kirill Rogovoy سے کہا کہ وہ Skyeng میں ویڈیو کمیونیکیشن کے ارتقاء، دریافت شدہ مسائل، حل اور بیساکھیوں کے بارے میں بات کریں جنہیں ہم نے بالآخر استعمال کیا۔ ہمیں امید ہے کہ مضمون ان کمپنیوں کے لیے کارآمد ثابت ہو گا جو ویب ایپلیکیشن کے ذریعے خود بھی ویڈیو بناتی ہیں۔
تاریخ کا ایک تھوڑا سا
2017 کے موسم گرما میں، Skyeng کی ترقی کے سربراہ، Sergey Safonov نے Backend Conf میں ایک کہانی کے ساتھ بات کی کہ کس طرح ہم نے "Skype کو چھوڑ دیا اور WebRTC کو لاگو کیا۔" دلچسپی رکھنے والے اس پر تقریر کی ریکارڈنگ دیکھ سکتے ہیں۔ (~45 منٹ)، اور یہاں میں مختصراً اس کے جوہر کا خاکہ پیش کروں گا۔
Skyeng سکول کے لیے، ویڈیو کمیونیکیشن ہمیشہ استاد اور طالب علم کے درمیان رابطے کا ایک ترجیحی طریقہ رہا ہے۔ سب سے پہلے، Skype کا استعمال کیا گیا تھا، لیکن یہ واضح طور پر کئی وجوہات کی بناء پر تسلی بخش نہیں تھا، بنیادی طور پر لاگز کی کمی اور ویب ایپلیکیشن میں براہ راست انضمام کے ناممکن ہونے کی وجہ سے۔ لہذا، ہم نے ہر طرح کے تجربات کئے۔
دراصل، ویڈیو کمیونیکیشن کے لیے ہمارے تقاضے تقریباً درج ذیل تھے:
- استحکام؛
- فی سبق کم قیمت؛
- ریکارڈنگ اسباق؛
- یہ معلوم کرنا کہ کون کتنا بولتا ہے (یہ ہمارے لیے اہم ہے کہ طلباء اسباق کے دوران استاد سے زیادہ بولیں)؛
- لکیری اسکیلنگ؛
- UDP اور TCP دونوں کو استعمال کرنے کی صلاحیت۔
سب سے پہلے ٹوک باکس کو 2013 میں نافذ کرنے کی کوشش کی گئی۔ سب کچھ اچھا تھا، لیکن یہ بہت مہنگا نکلا - 113 روبل فی سبق - اور منافع کھایا.
پھر 2015 میں، Voximplant کو ضم کر دیا گیا۔ یہ وہ فنکشن تھا جس کی ہمیں یہ معلوم کرنے کی ضرورت تھی کہ کس نے کتنا بولا، اور اس کے ساتھ ہی حل بہت سستا تھا: اگر صرف آڈیو ریکارڈ کیا جائے تو اس کی لاگت 20 روبل فی سبق ہے۔ تاہم، یہ صرف UDP کے ذریعے کام کرتا تھا اور TCP پر سوئچ نہیں کر سکتا تھا۔ تاہم، تقریباً 40% طلباء نے اسے استعمال کرنا شروع کر دیا۔
ایک سال بعد، ہمارے پاس کارپوریٹ کلائنٹس ان کی اپنی مخصوص ضروریات کے ساتھ ہونے لگے۔ مثال کے طور پر، ہر چیز کو براؤزر کے ذریعے کام کرنا چاہیے؛ کمپنی صرف http اور https کھولتی ہے؛ یعنی کوئی Skype یا UDP نہیں۔ کارپوریٹ کلائنٹس = پیسے، تو وہ ٹوک باکس میں واپس آئے، لیکن قیمت کا مسئلہ دور نہیں ہوا۔
حل - WebRTC اور Janus
استعمال کرنے کا فیصلہ کیا۔ . یہ ایک کنکشن قائم کرنے، انکوڈنگ اور ڈی کوڈنگ اسٹریمز، ٹریکس کو سنکرونائز کرنے اور نیٹ ورک کی خرابیوں سے نمٹنے کے ساتھ کوالٹی کنٹرول کے لیے ذمہ دار ہے۔ ہمارے حصے کے لیے، ہمیں کیمرہ اور مائیکروفون سے اسٹریمز کو پڑھنے، ویڈیو ڈرائنگ، کنکشن کا انتظام، WebRTC کنکشن قائم کرنے اور اس میں اسٹریمز کی ترسیل کو یقینی بنانا چاہیے، نیز کنکشن قائم کرنے کے لیے کلائنٹس کے درمیان سگنلنگ پیغامات کی ترسیل کو یقینی بنانا چاہیے (WebRTC بذات خود صرف ڈیٹا فارمیٹ، لیکن اس کا میکانزم ٹرانسفر نہیں)۔ اگر کلائنٹس NAT کے پیچھے ہیں، WebRTC STUN سرورز کو جوڑتا ہے؛ اگر اس سے مدد نہیں ملتی ہے تو سرورز کو تبدیل کریں۔
ہمارے لیے باقاعدہ p2p کنکشن کافی نہیں ہے، کیونکہ ہم شکایات کی صورت میں مزید تجزیہ کے لیے اسباق کو ریکارڈ کرنا چاہتے ہیں۔ اس لیے ہم WebRTC اسٹریمز کو ریلے کے ذریعے بھیجتے ہیں۔ . نتیجے کے طور پر، کلائنٹس ایک دوسرے کے پتے نہیں جانتے، صرف Janus سرور ایڈریس دیکھ کر؛ یہ سگنل سرور کے کام بھی انجام دیتا ہے۔ جینس کے پاس بہت سی خصوصیات ہیں جن کی ہمیں ضرورت ہے: اگر کلائنٹ نے UDP بلاک کر دیا ہے تو خود بخود TCP میں تبدیل ہو جاتا ہے۔ UDP اور TCP دونوں سلسلے کو ریکارڈ کر سکتے ہیں۔ توسیع پذیر یہاں تک کہ ایکو ٹیسٹ کے لیے ایک بلٹ ان پلگ ان بھی ہے۔ اگر ضروری ہو تو، Twilio سے STUN اور ٹرن سرور خود بخود جڑ جاتے ہیں۔
2017 کے موسم گرما میں، ہمارے پاس دو Janus سرورز چل رہے تھے، نیز ریکارڈ شدہ خام آڈیو اور ویڈیو فائلوں کی پروسیسنگ کے لیے ایک اضافی سرور تھا، تاکہ اہم کے پروسیسرز پر قبضہ نہ ہو سکے۔ جڑتے وقت، جینس سرورز کو طاق-جفت کی بنیاد پر منتخب کیا گیا تھا (کنکشن نمبر)۔ اس وقت، یہ کافی تھا، ہمارے احساسات کے مطابق، اس نے تقریباً چار گنا حفاظتی مارجن دیا، نفاذ کا فیصد تقریباً 80 تھا۔ اسی وقت، قیمت کم کر کے ~2 روبل فی سبق، نیز ترقی اور مدد کر دی گئی۔
ویڈیو کمیونیکیشن کے موضوع پر واپس آ رہا ہوں۔
ہم طلباء اور اساتذہ کے تاثرات کی مسلسل نگرانی کرتے ہیں تاکہ بروقت مسائل کی نشاندہی اور ان کو درست کیا جا سکے۔ 2018 کے موسم گرما تک، شکایات میں کال کا معیار مضبوطی سے پہلے نمبر پر تھا۔ ایک طرف، اس کا مطلب یہ تھا کہ ہم نے دوسری کوتاہیوں کو کامیابی سے دور کر لیا ہے۔ دوسری طرف، فوری طور پر کچھ کرنا ضروری تھا: اگر سبق میں خلل پڑتا ہے، تو ہمیں اس کی قیمت کھونے کا خطرہ ہوتا ہے، بعض اوقات اگلے پیکیج کی خریداری کی لاگت کے ساتھ، اور اگر تعارفی سبق میں خلل پڑتا ہے، تو ہمیں ممکنہ کلائنٹ کو کھونے کا خطرہ ہوتا ہے۔ ایک ساتھ.
اس وقت، ہمارا ویڈیو مواصلات ابھی بھی MVP موڈ میں تھا۔ سیدھے الفاظ میں، انہوں نے اسے لانچ کیا، اس نے کام کیا، انہوں نے اسے ایک بار پیمانہ بنایا، وہ سمجھ گئے کہ اسے کیسے کرنا ہے - ٹھیک ہے، بہت اچھا۔ اگر یہ کام کرتا ہے تو اسے ٹھیک نہ کریں۔ کسی نے بھی جان بوجھ کر کمیونیکیشن کے معیار کے مسئلے پر توجہ نہیں دی۔ اگست تک، یہ واضح ہو گیا کہ یہ جاری نہیں رہ سکتا، اور ہم نے یہ جاننے کے لیے ایک الگ سمت شروع کی کہ WebRTC اور Janus میں کیا غلط ہے۔
ان پٹ پر، یہ سمت موصول ہوئی: ایک MVP حل، کوئی میٹرکس، کوئی اہداف، بہتری کے لیے کوئی عمل نہیں، جبکہ 7% اساتذہ کمیونیکیشن کے معیار کے بارے میں شکایت کرتے ہیں (طلبہ پر بھی کوئی ڈیٹا نہیں تھا)۔
ایک نئی سمت چل رہی ہے۔
کمانڈ کچھ اس طرح نظر آتی ہے:
- محکمہ کا سربراہ جو کہ مرکزی ڈویلپر بھی ہے۔
- QA تبدیلیوں کی جانچ میں مدد کرتا ہے، غیر مستحکم مواصلاتی حالات پیدا کرنے کے نئے طریقے تلاش کرتا ہے، اور فرنٹ لائن سے مسائل کی اطلاع دیتا ہے۔
- تجزیہ کار مسلسل تکنیکی ڈیٹا میں مختلف ارتباط تلاش کرتا ہے، صارف کے تاثرات کے تجزیے کو بہتر بناتا ہے، اور تجربات کے نتائج کو چیک کرتا ہے۔
- پروڈکٹ مینیجر تجربات کے لیے وسائل کی مجموعی سمت اور مختص کرنے میں مدد کرتا ہے۔
- دوسرا ڈویلپر اکثر پروگرامنگ اور متعلقہ کاموں میں مدد کرتا ہے۔
شروع کرنے کے لیے، ہم نے ایک نسبتاً قابل بھروسہ میٹرک ترتیب دیا جس میں کمیونیکیشن کے معیار کے جائزوں (اوسط دنوں، ہفتوں، مہینوں میں) میں تبدیلیوں کو ٹریک کیا گیا۔ اس وقت، یہ اساتذہ کے درجات تھے؛ بعد میں طلباء کے درجات ان میں شامل کیے گئے۔ پھر انہوں نے غلط کام کرنے کے بارے میں مفروضے بنانا شروع کیے، اسے درست کریں، اور حرکیات میں تبدیلیوں کو دیکھیں۔ ہم کم لٹکنے والے پھل کے لیے گئے: مثال کے طور پر، ہم نے vp8 کوڈیک کو vp9 سے بدل دیا، کارکردگی بہتر ہوئی۔ ہم نے جانس کی ترتیبات کے ساتھ کھیلنے اور دوسرے تجربات کرنے کی کوشش کی - زیادہ تر معاملات میں وہ کچھ بھی نہیں لے گئے۔
دوسرے مرحلے پر، ایک مفروضہ سامنے آیا: WebRTC ایک ہم مرتبہ سے ہم مرتبہ حل ہے، اور ہم درمیان میں ایک سرور استعمال کرتے ہیں۔ شاید مسئلہ یہیں ہے؟ ہم نے کھدائی شروع کی اور اب تک کی سب سے نمایاں بہتری دیکھی۔
اس وقت، پول سے ایک سرور کا انتخاب کافی احمقانہ الگورتھم کا استعمال کرتے ہوئے کیا گیا تھا: چینل اور طاقت کے لحاظ سے ہر ایک کا اپنا "وزن" تھا، اور ہم نے صارف کو سب سے بڑے "وزن" والے کے پاس بھیجنے کی کوشش کی۔ اس بات پر توجہ دینا کہ صارف جغرافیائی طور پر کہاں واقع تھا۔ نتیجے کے طور پر، سینٹ پیٹرزبرگ کا ایک استاد سائبیریا کے ایک طالب علم سے ماسکو کے ذریعے رابطہ کر سکتا ہے، نہ کہ سینٹ پیٹرزبرگ میں ہمارے جینس سرور کے ذریعے۔
الگورتھم کو دوبارہ کر دیا گیا ہے: اب، جب کوئی صارف ہمارا پلیٹ فارم کھولتا ہے، تو ہم ایجیکس کا استعمال کرتے ہوئے اس سے تمام سرورز پر پنگ جمع کرتے ہیں۔ کنکشن قائم کرتے وقت، ہم سب سے کم رقم کے ساتھ پنگس (استاد سرور اور طالب علم سرور) کا ایک جوڑا منتخب کرتے ہیں۔ کم پنگ کا مطلب ہے سرور سے نیٹ ورک کا کم فاصلہ۔ کم فاصلہ کا مطلب ہے پیکٹ کے کھونے کا کم امکان؛ ویڈیو مواصلات میں پیکٹ کا نقصان سب سے بڑا منفی عنصر ہے۔ منفی کا حصہ تین مہینوں میں نصف تک گر گیا (منصفانہ طور پر، اس وقت دیگر تجربات کیے گئے تھے، لیکن اس کا تقریباً یقینی طور پر سب سے زیادہ اثر ہوا)۔
ہم نے حال ہی میں ایک اور غیر واضح، لیکن بظاہر اہم چیز دریافت کی ہے: موٹے چینل پر ایک طاقتور Janus سرور کی بجائے، پتلی بینڈوتھ کے ساتھ دو آسان سرور کا ہونا بہتر ہے۔ یہ اس وقت واضح ہو گیا جب ہم نے ایک ہی وقت میں ان میں زیادہ سے زیادہ کمروں (مواصلاتی سیشنز) کو بھرنے کی امید میں طاقتور مشینیں خریدیں۔ سرورز کی ایک بینڈوتھ کی حد ہوتی ہے، جسے ہم کمروں کی تعداد میں درست طریقے سے ترجمہ کر سکتے ہیں - ہم جانتے ہیں کہ کتنے کھولے جا سکتے ہیں، مثال کے طور پر، 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