Skype မှ WebRTC သို့ ကျွန်ုပ်တို့သည် ဝဘ်မှတစ်ဆင့် ဗီဒီယိုဆက်သွယ်ရေးကို မည်သို့စီစဉ်မည်နည်း။

ဗီဒီယိုဆက်သွယ်ရေးသည် Vimbox ပလပ်ဖောင်းတွင် ဆရာနှင့်ကျောင်းသားကြား ဆက်သွယ်မှု၏ အဓိကနည်းလမ်းဖြစ်သည်။ ကျွန်ုပ်တို့သည် အချိန်ကြာမြင့်စွာကတည်းက Skype ကိုစွန့်လွှတ်ခဲ့ပြီး ပြင်ပကုမ္ပဏီဖြေရှင်းချက်များစွာကို ကြိုးစားခဲ့ပြီး နောက်ဆုံးတွင် WebRTC - Janus-gateway ပေါင်းစပ်မှုတွင် အခြေချခဲ့သည်။ အချိန်အတော်ကြာအောင် ကျွန်တော်တို့ဟာ အရာရာတိုင်းကို ပျော်ရွှင်ခဲ့ကြပေမယ့် အချို့သော အပျက်သဘောဆောင်တဲ့ ရှုထောင့်တွေက ဆက်လက်ထွက်ပေါ်လာခဲ့ပါတယ်။ ရလဒ်အနေဖြင့် သီးခြားဗီဒီယိုဦးတည်ချက်ကို ဖန်တီးခဲ့သည်။

Skyeng တွင် ဗီဒီယိုဆက်သွယ်ရေး၏ ဆင့်ကဲဖြစ်စဉ်၊ ရှာဖွေတွေ့ရှိမှု၊ ဖြေရှင်းချက်များနှင့် ချိုင်းထောက်များအကြောင်း ဆွေးနွေးရန် ဦးတည်ချက်အသစ်၏ အကြီးအကဲ Kirill Rogovoy အား ကျွန်ုပ်တောင်းဆိုခဲ့သည်။ ဝဘ်အက်ပလီကေးရှင်းမှတဆင့် ၎င်းတို့ကိုယ်တိုင် ဗီဒီယိုဖန်တီးသည့် ကုမ္ပဏီများအတွက် ဆောင်းပါးသည် အသုံးဝင်လိမ့်မည်ဟု မျှော်လင့်ပါသည်။

အနည်းငယ်သောသမိုင်း

2017 ခုနှစ် နွေရာသီတွင် Skyeng ဖွံ့ဖြိုးတိုးတက်ရေး အကြီးအကဲ Sergey Safonov က Backend Conf တွင် ကျွန်ုပ်တို့ "Skype ကို စွန့်ပစ်ပြီး WebRTC ကို အကောင်အထည်ဖော်ပုံ" အကြောင်းကို ပြောပြခဲ့ပါသည်။ စိတ်ပါဝင်စားသူများ အနေဖြင့် မိန့်ခွန်းကို မှတ်တမ်းတင် ကြည့်ရှုနိုင်ပါသည်။ link ကို (45 မိနစ်) ဤနေရာတွင် ၎င်း၏အနှစ်သာရကို အတိုချုံးဖော်ပြပါမည်။

Skyeng ကျောင်းအတွက်၊ ဗီဒီယိုဆက်သွယ်ရေးသည် ဆရာ-ကျောင်းသား ဆက်သွယ်မှု၏ ဦးစားပေးနည်းလမ်းဖြစ်သည်။ အစပိုင်းတွင် Skype ကို အသုံးပြုခဲ့သော်လည်း အကြောင်းအမျိုးမျိုးကြောင့် ကျေနပ်မှုမရှိခဲ့ဘဲ၊ အဓိကအားဖြင့် မှတ်တမ်းများမရှိခြင်းနှင့် ဝဘ်အက်ပလီကေးရှင်းသို့ တိုက်ရိုက်ပေါင်းစည်းရန် မဖြစ်နိုင်ခြင်းကြောင့်ဖြစ်သည်။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် အမျိုးမျိုးသော စမ်းသပ်မှုများကို ပြုလုပ်ခဲ့ပါသည်။

တကယ်တော့၊ ဗီဒီယိုဆက်သွယ်ရေးအတွက် ကျွန်ုပ်တို့၏လိုအပ်ချက်များသည် ခန့်မှန်းခြေအားဖြင့် အောက်ပါအတိုင်းဖြစ်သည်-
- တည်ငြိမ်မှု;
- သင်ခန်းစာတစ်ခုအတွက် စျေးနှုန်းချိုသာခြင်း။
- မှတ်တမ်းတင်သင်ခန်းစာများ;
— မည်မျှပြောသည်ကို ခြေရာခံခြင်း (စာသင်ချိန်အတွင်း ကျောင်းသားများသည် ဆရာထက် ပိုပြောတတ်ရန် ကျွန်ုပ်တို့အတွက် အရေးကြီးသည်)။
- linear အတိုင်းအတာ;
- UDP နှင့် TCP နှစ်မျိုးလုံးကို အသုံးပြုနိုင်သည်။

ပထမဆုံးကြိုးစားရန်မှာ 2013 ခုနှစ်တွင် Tokbox ကိုအကောင်အထည်ဖော်ရန်ဖြစ်သည်။ အရာအားလုံးကောင်းမွန်သော်လည်း၊ သင်ခန်းစာတစ်ခုလျှင် 113 ရူဘယ် - အလွန်စျေးကြီးပြီးအမြတ်ကိုစားခဲ့သည်။

ထို့နောက် 2015 ခုနှစ်တွင် Voximplant ကိုပေါင်းစပ်ခဲ့သည်။ ဤတွင် မည်သူမည်မျှပြောသည်ကို ခြေရာခံရန် လိုအပ်သည့် လုပ်ဆောင်ချက်ဖြစ်ပြီး တစ်ချိန်တည်းတွင် ဖြေရှင်းချက်သည် များစွာစျေးသက်သာသည်- အသံကိုသာ မှတ်တမ်းတင်ထားပါက သင်ခန်းစာတစ်ခုလျှင် ရူဘယ် 20 ကုန်ကျသည်။ သို့သော်လည်း ၎င်းသည် UDP မှတဆင့်သာ အလုပ်လုပ်ပြီး TCP သို့ပြောင်း၍မရပါ။ သို့သော် ကျောင်းသား 40% ခန့်သည် ၎င်းကို အသုံးပြုပြီးသွားကြသည်။

တစ်နှစ်အကြာတွင်၊ ကျွန်ုပ်တို့သည် ၎င်းတို့၏ကိုယ်ပိုင်သတ်မှတ်ချက်များဖြင့် ကော်ပိုရိတ်ဖောက်သည်များ စတင်ရရှိလာသည်။ ဥပမာအားဖြင့်၊ အရာအားလုံးသည် browser တစ်ခုမှအလုပ်လုပ်သင့်သည်၊ ကုမ္ပဏီသည် http နှင့် https ကိုသာဖွင့်သည်။ ဥပမာ Skype သို့မဟုတ် UDP မရှိပါ။ ကော်ပိုရိတ်ဖောက်သည်များ = ငွေ၊ ထို့ကြောင့် ၎င်းတို့သည် Tokbox သို့ ပြန်သွားသော်လည်း စျေးနှုန်းပြဿနာမှာ ပြေလည်သွားခြင်းမရှိပေ။

ဖြေရှင်းချက် - WebRTC နှင့် Janus

အသုံးပြုရန် ဆုံးဖြတ်ခဲ့သည်။ peer-to-peer ဗီဒီယိုဆက်သွယ်ရေး WebRTC အတွက် ဘရောက်ဆာပလက်ဖောင်း. ချိတ်ဆက်မှု၊ ကုဒ်ကုဒ်နှင့် ကုဒ်ထုတ်ခြင်း လမ်းကြောင်းများကို တည်ထောင်ရန်၊ လမ်းကြောင်းများကို တစ်ပြိုင်တည်းလုပ်ဆောင်ခြင်းနှင့် ကွန်ရက်ချို့ယွင်းချက်များကို ကိုင်တွယ်ခြင်းဖြင့် အရည်အသွေးထိန်းချုပ်မှုအတွက် တာဝန်ရှိသည်။ ကျွန်ုပ်တို့၏အပိုင်းတွင်၊ ကျွန်ုပ်တို့သည် ကင်မရာနှင့် မိုက်ခရိုဖုန်းမှ တိုက်ရိုက်ထုတ်လွှင့်မှုများကို ဖတ်ရှုခြင်း၊ ဗီဒီယိုဆွဲခြင်း၊ ချိတ်ဆက်မှုကို စီမံခန့်ခွဲခြင်း၊ WebRTC ချိတ်ဆက်မှုတစ်ခု ထူထောင်ခြင်းနှင့် ၎င်းထံသို့ ထုတ်လွှင့်မှုများ ထုတ်လွှင့်ခြင်းအပြင် ချိတ်ဆက်မှုတစ်ခုကို ထူထောင်ရန်အတွက် သုံးစွဲသူများအကြား အချက်ပြမက်ဆေ့ဂျ်များ ပို့ခြင်းတို့ကို သေချာစေရပါမည် (WebRTC ကိုယ်တိုင်က တစ်ခုတည်းကိုသာ ဖော်ပြပါသည်။ ဒေတာဖော်မတ်၊ သို့သော်၎င်း၏ယန္တရားလွှဲပြောင်းခြင်းမဟုတ်ပါ။) clients များသည် NAT နောက်ကွယ်တွင်ရှိနေပါက၊ WebRTC သည် STUN ဆာဗာများကိုချိတ်ဆက်သည်၊ ၎င်းသည်မကူညီပါက၊ ဆာဗာများကိုလှည့်ပါ။

တိုင်ကြားမှုများရှိပါက နောက်ထပ်ခွဲခြမ်းစိတ်ဖြာရန်အတွက် သင်ခန်းစာများကို မှတ်တမ်းတင်လိုသောကြောင့် ပုံမှန် p2p ချိတ်ဆက်မှုသည် ကျွန်ုပ်တို့အတွက် မလုံလောက်ပါ။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် relay မှတဆင့် WebRTC လမ်းကြောင်းများကို ပေးပို့ပါသည်။ Metecho မှ Janus Gateway. ရလဒ်အနေဖြင့်၊ ဖောက်သည်များသည် Janus ဆာဗာလိပ်စာကိုသာမြင်ပြီး အချင်းချင်း၏လိပ်စာများကို မသိကြပါ။ ၎င်းသည် signal server ၏လုပ်ဆောင်ချက်များကိုလည်းလုပ်ဆောင်သည်။ Janus တွင်ကျွန်ုပ်တို့လိုအပ်သောအင်္ဂါရပ်များစွာရှိသည်- client သည် UDP ကိုပိတ်ဆို့ထားပါက TCP သို့အလိုအလျောက်ပြောင်းသည်။ UDP နှင့် TCP လမ်းကြောင်းနှစ်ခုလုံးကို မှတ်တမ်းတင်နိုင်သည်။ အရွယ်မှာသုံးနိုင်သော၊ ပဲ့တင်သံစမ်းသပ်မှုများအတွက် built-in plugin တစ်ခုတောင်ရှိပါသေးတယ်။ လိုအပ်ပါက Twilio မှ STUN နှင့် TURN ဆာဗာများကို အလိုအလျောက်ချိတ်ဆက်ထားသည်။

2017 ခုနှစ် နွေရာသီတွင်၊ ကျွန်ုပ်တို့တွင် Janus ဆာဗာနှစ်ခု လည်ပတ်နေပြီး အဓိကအရာများ၏ ပရိုဆက်ဆာများကို သိမ်းပိုက်ခြင်းမခံရစေရန် မှတ်တမ်းတင်ထားသော အကြမ်းထည်နှင့် ဗီဒီယိုဖိုင်များကို လုပ်ဆောင်ရန်အတွက် နောက်ထပ်ဆာဗာတစ်ခုရှိသည်။ ချိတ်ဆက်သောအခါတွင်၊ Janus ဆာဗာများကို ထူးဆန်းသောအခြေခံ (ချိတ်ဆက်မှုနံပါတ်) ဖြင့် ရွေးချယ်ခဲ့သည်။ ထိုအချိန်တွင်၊ ၎င်းသည် ကျွန်ုပ်တို့၏ခံစားချက်များနှင့်အညီ လုံလောက်သည်၊ ၎င်းသည် ခန့်မှန်းခြေအားဖြင့် ဘေးကင်းရေးအနားသတ်လေးဆပေးသည်၊ အကောင်အထည်ဖော်မှုရာခိုင်နှုန်းမှာ 80 ခန့်ဖြစ်သည်။ တစ်ချိန်တည်းတွင်၊ သင်ခန်းစာတစ်ခုလျှင် 2 ရူဘယ်၊ စျေးနှုန်းအပြင် ဖွံ့ဖြိုးတိုးတက်မှုနှင့် ပံ့ပိုးမှုတို့ကိုပါ လျှော့ချခဲ့သည်။

ဗီဒီယို ဆက်သွယ်မှု ခေါင်းစဉ်သို့ ပြန်သွားရန်

ပြဿနာများကို အချိန်နှင့်တစ်ပြေးညီ သိရှိနိုင်စေရန်အတွက် ကျောင်းသားများနှင့် ဆရာများထံမှ တုံ့ပြန်ချက်များကို ကျွန်ုပ်တို့ အမြဲစောင့်ကြည့်နေပါသည်။ 2018 ခုနှစ် နွေရာသီတွင် ဖုန်းခေါ်ဆိုမှု အရည်အသွေးသည် တိုင်ကြားမှုများတွင် ပထမနေရာတွင် အခိုင်အမာ ရှိနေပါသည်။ တစ်ဖက်တွင်၊ ဤသည်မှာ ကျွန်ုပ်တို့သည် အခြားသော ချို့ယွင်းချက်များကို အောင်မြင်စွာ ကျော်လွှားနိုင်ခဲ့သည်ဟု ဆိုလိုသည်။ တစ်ဖက်တွင်၊ တစ်ခုခုကို အရေးတကြီးလုပ်ဆောင်ရန် လိုအပ်သည်- သင်ခန်းစာ ပြတ်တောက်သွားပါက၊ ကျွန်ုပ်တို့သည် ၎င်း၏တန်ဖိုးကို ဆုံးရှုံးနိုင်သည်၊ တစ်ခါတစ်ရံတွင် နောက်ပက်ကေ့ဂျ်ကို ဝယ်ယူရသည့် ကုန်ကျစရိတ်နှင့်အတူ တစ်ခါတစ်ရံတွင်၊ မိတ်ဆက်သင်ခန်းစာ ပြတ်တောက်သွားပါက၊ ကျွန်ုပ်တို့သည် ဖြစ်နိုင်ချေရှိသော သုံးစွဲသူတစ်ဦးကို ဆုံးရှုံးရနိုင်ချေရှိသည်။ ဘိုးတော်။

ထိုအချိန်တွင် ကျွန်ုပ်တို့၏ ဗီဒီယိုဆက်သွယ်ရေးသည် MVP မုဒ်တွင် ရှိနေသေးသည်။ ရိုးရိုးရှင်းရှင်းပြောရရင် သူတို့က စဖွင့်တယ်၊ အဲဒါက အလုပ်လုပ်တယ်၊ တခါတည်း စကေးချတယ်၊ ဘယ်လိုလုပ်ရမယ်ဆိုတာ နားလည်တယ် - ကောင်းတယ်၊ ကောင်းတယ်။ အလုပ်ဖြစ်လျှင် မပြင်ပါနှင့်။ ဆက်သွယ်ရေးအရည်အသွေးပြဿနာကို မည်သူကမှ တမင်တကာ ကိုင်တွယ်ဖြေရှင်းခြင်း မရှိပါ။ ဩဂုတ်လတွင်၊ ၎င်းသည် ဆက်လက်မလုပ်ဆောင်နိုင်တော့ကြောင်း ရှင်းရှင်းလင်းလင်း သိလာရပြီး WebRTC နှင့် Janus တွင် အမှားအယွင်းများကို ရှာဖွေဖော်ထုတ်ရန် သီးခြားဦးတည်ချက်တစ်ရပ်ကို ထုတ်ပြန်ခဲ့သည်။

ထည့်သွင်းမှုတွင်၊ ဤလမ်းညွှန်ချက်ကို လက်ခံရရှိသည်- MVP ဖြေရှင်းချက်၊ မက်ထရစ်များမရှိ၊ ပန်းတိုင်မရှိ၊ တိုးတက်မှုအတွက် လုပ်ငန်းစဉ်များမရှိ၊ ဆရာများ၏ 7% သည် ဆက်သွယ်ရေးအရည်အသွေးနှင့်ပတ်သက်၍ တိုင်ကြားထားသော်လည်း (ကျောင်းသားများတွင်လည်း ဒေတာမရှိပါ)။

ဦးတည်ချက်အသစ်တစ်ခု စတင်နေပါပြီ။

command သည် ဤကဲ့သို့ ဖြစ်သည်-

• ဌာန အကြီးအကဲ လည်း ပင်မပြုစုသူလည်း ဖြစ်သည်။
• QA သည် ပြောင်းလဲမှုများကို စမ်းသပ်ရန်၊ မတည်မငြိမ်သော ဆက်သွယ်မှု အခြေအနေများကို ဖန်တီးရန် နည်းလမ်းအသစ်များကို ရှာဖွေရန်နှင့် ရှေ့တန်းမှ ပြဿနာများကို သတင်းပို့ရန် ကူညီပေးသည်။
• အကဲခတ်သူသည် နည်းပညာဆိုင်ရာ အချက်အလက်များတွင် ဆက်စပ်မှုအမျိုးမျိုးကို အဆက်မပြတ်ရှာဖွေသည်၊ အသုံးပြုသူတုံ့ပြန်ချက်၏ခွဲခြမ်းစိတ်ဖြာမှုကို တိုးတက်စေကာ စမ်းသပ်မှုရလဒ်များကို စစ်ဆေးသည်။
• ထုတ်ကုန်မန်နေဂျာသည် စမ်းသပ်မှုများအတွက် အလုံးစုံဦးတည်ချက်နှင့် အရင်းအမြစ်များခွဲဝေပေးရာတွင် ကူညီပေးသည်။
• ဒုတိယ developer သည် ပရိုဂရမ်ရေးဆွဲခြင်းနှင့် ဆက်စပ်အလုပ်များကို ကူညီပေးလေ့ရှိသည်။

စတင်ရန်၊ ကျွန်ုပ်တို့သည် ဆက်သွယ်ရေးအရည်အသွေး အကဲဖြတ်မှုများ (ပျမ်းမျှရက်၊ ရက်သတ္တပတ်၊ လများ) တွင် အပြောင်းအလဲများကို ခြေရာခံသည့် ယုံကြည်စိတ်ချရသော မက်ထရစ်ကို တည်ဆောက်ထားပါသည်။ ထိုအချိန်က ဤအရာများသည် ဆရာများထံမှ အမှတ်များဖြစ်ပြီး နောက်ပိုင်းတွင် ကျောင်းသားများ၏ အမှတ်များကို ၎င်းတို့ထံ ထည့်ပေးခဲ့သည်။ ထို့နောက် ၎င်းတို့သည် မှားယွင်းလုပ်ဆောင်နေသည့်အရာများနှင့်ပတ်သက်၍ တွေးခေါ်မှုများကို စတင်တည်ဆောက်ကာ ပြုပြင်ပေးကာ ဒိုင်းနမစ်ပြောင်းလဲမှုများကို ကြည့်ရှုခဲ့ကြသည်။ ကျွန်ုပ်တို့သည် နိမ့်သောအသီးအတွက် သွားခဲ့ကြသည်- ဥပမာ၊ ကျွန်ုပ်တို့သည် vp8 codec ကို vp9 ဖြင့် အစားထိုးလိုက်သည်၊ စွမ်းဆောင်ရည် ပိုမိုကောင်းမွန်လာသည်။ ကျွန်ုပ်တို့သည် Janus ဆက်တင်များဖြင့် ကစားပြီး အခြားစမ်းသပ်မှုများကို လုပ်ဆောင်ရန် ကြိုးစားခဲ့သည် - ကိစ္စအများစုတွင် ၎င်းတို့သည် မည်သည့်အရာကိုမျှ မဖြစ်ပေါ်စေပါ။

ဒုတိယအဆင့်တွင်၊ အယူအဆတစ်ခု ထွက်ပေါ်လာသည်- WebRTC သည် peer-to-peer ဖြေရှင်းချက်ဖြစ်ပြီး၊ ကျွန်ုပ်တို့သည် အလယ်တွင် ဆာဗာကို အသုံးပြုပါသည်။ ပြဿနာက ဒီမှာ ရှိနေသလား။ ကျွန်ုပ်တို့ စတင်တူးဖော်ပြီး ယခုအချိန်အထိ အထူးခြားဆုံး တိုးတက်မှုကို တွေ့ရှိခဲ့သည်။

ထိုအချိန်တွင်၊ ရေကူးကန်မှဆာဗာတစ်ခုကို အတော်လေးမိုက်မဲသော အယ်လဂိုရီသမ်ကို အသုံးပြု၍ ရွေးချယ်ခဲ့သည်- တစ်ခုစီတွင် ချန်နယ်နှင့် ပါဝါပေါ်မူတည်၍ ၎င်း၏ကိုယ်ပိုင် "အလေးချိန်" ရှိပြီး၊ ကျွန်ုပ်တို့သည် အသုံးပြုသူကို မလိုအပ်ဘဲ အကြီးဆုံး "အလေးချိန်" ကို ပေးပို့ရန် ကြိုးစားခဲ့သည်။ အသုံးပြုသူသည် ပထဝီဝင်အနေအထားအရ တည်ရှိသည့်နေရာကို ဂရုပြုပါ။ ရလဒ်အနေဖြင့် စိန့်ပီတာစဘတ်မှ ဆရာတစ်ဦးသည် မော်စကိုကိုဖြတ်၍ ဆိုက်ဘေးရီးယားမှ ကျောင်းသားတစ်ဦးနှင့် ဆက်သွယ်နိုင်ပြီး စိန့်ပီတာစဘတ်ရှိ ကျွန်ုပ်တို့၏ Janus ဆာဗာမှတစ်ဆင့် ဆက်သွယ်နိုင်သည်။

အယ်လဂိုရီသမ်ကို ပြန်လည်ပြင်ဆင်ပြီးပါပြီ- ယခု၊ အသုံးပြုသူတစ်ဦးသည် ကျွန်ုပ်တို့၏ပလပ်ဖောင်းကိုဖွင့်သောအခါ၊ ကျွန်ုပ်တို့သည် Ajax ကိုအသုံးပြုသည့် ဆာဗာများအားလုံးထံ pings များစုဆောင်းပါသည်။ ချိတ်ဆက်မှုတစ်ခုကို တည်ဆောက်သည့်အခါ၊ ကျွန်ုပ်တို့သည် အနည်းဆုံးပမာဏဖြင့် pings တစ်စုံ (ဆရာ-ဆာဗာနှင့် ကျောင်းသား-ဆာဗာ) ကို ရွေးချယ်သည်။ ping နည်းသည် ဆာဗာနှင့် ကွန်ရက်အကွာအဝေး နည်းပါးခြင်းကို ဆိုလိုသည်။ ပိုတိုသောအကွာအဝေးဆိုသည်မှာ packets များဆုံးရှုံးနိုင်ခြေနည်းသည်၊ Packet ဆုံးရှုံးမှုသည် ဗီဒီယိုဆက်သွယ်မှုတွင် အကြီးမားဆုံး အနုတ်လက္ခဏာဆောင်သည့်အချက်ဖြစ်သည်။ အဆိုးမြင်မှုဝေစုသည် သုံးလအတွင်း ထက်ဝက်ကျဆင်းသွားသည် (တရားမျှတစေရန်၊ အခြားစမ်းသပ်မှုများကို ယခုအချိန်တွင် ပြုလုပ်ခဲ့သော်လည်း၊ ဤအရာသည် သက်ရောက်မှုအရှိဆုံးနီးပါးဖြစ်သည်)။

မကြာသေးမီက ကျွန်ုပ်တို့သည် ထင်သာမြင်သာမရှိသော အခြားအရေးကြီးသောအရာကို ရှာဖွေတွေ့ရှိခဲ့သည်- ထူထဲသောချန်နယ်တစ်ခုရှိ အားကောင်းသည့် Janus ဆာဗာတစ်ခုအစား ပိုမိုပါးလွှာသော bandwidth ရှိသည့် ရိုးရှင်းသောနှစ်ခုရှိခြင်းက ပိုကောင်းပါသည်။ အခန်းများစွာ (ဆက်သွယ်ရေးစက်ရှင်များ) ကို တချိန်တည်းတွင် အခန်းများ (ဆက်သွယ်ရေးစက်များ) တွင်ထည့်သွင်းရန်မျှော်လင့်ချက်ဖြင့် အားကောင်းသည့်စက်များကို ဝယ်ယူပြီးနောက် ၎င်းသည် ရှင်းလင်းလာသည်။ ဆာဗာများတွင် အခန်းအရေအတွက်သို့ တိကျစွာဘာသာပြန်ဆိုနိုင်သည့် လှိုင်းနှုန်းကန့်သတ်ချက်ရှိသည် - ဥပမာအားဖြင့် 300 Mbit/s ဖြင့် ဖွင့်နိုင်သည်ကို ကျွန်ုပ်တို့ သိပါသည်။ ဆာဗာတစ်ခုပေါ်တွင် အခန်းများစွာဖွင့်ထားသည်နှင့်တပြိုင်နက် load လျော့နည်းသွားသည်အထိ လုပ်ဆောင်ချက်အသစ်များအတွက် ၎င်းကိုရွေးချယ်ခြင်းကို ရပ်တန့်လိုက်ပါသည်။ အိုင်ဒီယာကတော့ အားကောင်းတဲ့စက်ကိုဝယ်ပြီး ချန်နယ်ကို အမြင့်ဆုံးအထိ တင်ထားမယ်၊ ဒါမှ နောက်ဆုံးမှာ ပရိုဆက်ဆာနဲ့ မှတ်ဉာဏ်က အကန့်အသတ်နဲ့မဟုတ်ဘဲ bandwidth နဲ့ဘဲ ကန့်သတ်ထားလိမ့်မယ်။ သို့သော် အချို့သော အခန်းအရေအတွက် (၄၂၀) ပြီးနောက် ပရိုဆက်ဆာ၊ မန်မိုရီနှင့် ဒစ်ခ်သည် ကန့်သတ်ချက်များနှင့် အလွန်ဝေးကွာနေသော်လည်း အပျက်သဘောဆောင်မှုသည် နည်းပညာဆိုင်ရာ ပံ့ပိုးမှုဆီသို့ စတင်ရောက်ရှိနေပြီဖြစ်သည်။ Janus အတွင်းမှာ တစ်ခုခု ပိုဆိုးလာတာ ထင်ရှားပါတယ်၊ အဲဒီမှာ ကန့်သတ်ချက်တွေလည်း ရှိကောင်းရှိနိုင်ပါတယ်။ ကျွန်ုပ်တို့ စတင်စမ်းသပ်ခဲ့ပြီး၊ bandwidth ကန့်သတ်ချက်ကို 420 Mbit/s မှ 300 Mbit သို့ လျှော့ချလိုက်ပြီး ပြဿနာများ ပျောက်ကွယ်သွားခဲ့သည်။ ယခု ကျွန်ုပ်တို့သည် ကန့်သတ်ချက်များနှင့် လက္ခဏာများနည်းပါးသော ဆာဗာအသစ်သုံးခုကို တစ်ပြိုင်နက်ဝယ်ယူခဲ့ပြီး၊ ၎င်းသည် ဆက်သွယ်ရေးအရည်အသွေးကို တည်ငြိမ်စွာတိုးတက်စေမည်ဟု ကျွန်ုပ်တို့ယူဆပါသည်။ ဟုတ်ပါတယ်၊ ငါတို့အဲဒီမှာဘာတွေဖြစ်နေပြီလဲဆိုတာကိုရှာဖွေဖို့မကြိုးစားခဲ့ဘူး၊ ငါတို့ချိုင်းထောက်တွေကအရာအားလုံးပါပဲ။ ကျွန်ုပ်တို့၏ကာကွယ်ရေးတွင်၊ ထိုခဏ၌ တင်းမာသောပြဿနာကို တတ်နိုင်သမျှ မြန်မြန်ဖြေရှင်းရန် လိုအပ်သည်၊ ၎င်းကို လှလှပပမလုပ်ဘဲ၊ ထို့အပြင် Janus သည်ကျွန်ုပ်တို့အတွက် C ဖြင့်ရေးထားသောအနက်ရောင်သေတ္တာဖြစ်သည်၊ ၎င်းကိုသုံးရန်အလွန်စျေးကြီးသည်။

ကောင်းပြီ၊ လုပ်ငန်းစဉ်တွင် ကျွန်ုပ်တို့:

• ဆာဗာပေါ်တွင်ရော ကလိုင်းယင့်တွင်ရော အပ်ဒိတ်လုပ်နိုင်သည့် မှီခိုမှုအားလုံးကို အပ်ဒိတ်လုပ်ခဲ့သည် (၎င်းတို့သည် စမ်းသပ်မှုများလည်းဖြစ်၊ ရလဒ်များကို ကျွန်ုပ်တို့ စောင့်ကြည့်ခဲ့သည်)။
• ဥပမာအားဖြင့်၊ ချိတ်ဆက်မှု ကျဆင်းသွားကာ အလိုအလျောက် ပြန်လည်မရရှိသည့်အခါတွင် သီးခြားကိစ္စများနှင့် သက်ဆိုင်သည့် ခွဲခြားသတ်မှတ်ထားသော ချွတ်ယွင်းချက်အားလုံးကို ပြုပြင်ပေးခဲ့သည်။
• ကျွန်ုပ်တို့သည် ဗီဒီယိုဆက်သွယ်ရေးနယ်ပယ်တွင် လုပ်ကိုင်နေသော ကုမ္ပဏီများနှင့် အစည်းအဝေးများစွာကို ပြုလုပ်ခဲ့ပြီး ကျွန်ုပ်တို့၏ပြဿနာများနှင့် ရင်းနှီးသော- ဂိမ်းများကို ထုတ်လွှင့်ခြင်း၊ webinars များစီစဉ်ခြင်း၊ ငါတို့အတွက် အသုံးဝင်ပုံပေါက်သမျှကို ငါတို့ကြိုးစားခဲ့ကြတယ်။
• တိုင်ကြားမှုအများဆုံးဖြစ်ခဲ့သည့် ဆရာများ၏ ဟာ့ဒ်ဝဲနှင့် ဆက်သွယ်ရေးအရည်အသွေးဆိုင်ရာ နည်းပညာဆိုင်ရာ ပြန်လည်သုံးသပ်မှုကို ပြုလုပ်ခဲ့သည်။

စမ်းသပ်မှုများနှင့် နောက်ဆက်တွဲပြောင်းလဲမှုများသည် 7,1 ခုနှစ် ဇန်နဝါရီလတွင် 2018% မှ 2,5 ခုနှစ် ဇန်နဝါရီလတွင် ဆရာများအကြား ဆက်သွယ်မှုအပေါ် မကျေနပ်မှုများကို လျှော့ချနိုင်စေခဲ့သည်။

နောက်တစ်ခုကဘာလဲ

ကျွန်ုပ်တို့၏ Vimbox ပလပ်ဖောင်းကို တည်ငြိမ်စေခြင်းသည် 2019 ခုနှစ်အတွက် ကုမ္ပဏီ၏ အဓိကပရောဂျက်များထဲမှ တစ်ခုဖြစ်သည်။ ကျွန်ုပ်တို့သည် အရှိန်အဟုန်ကို ထိန်းသိမ်းထားနိုင်ပြီး ထိပ်တန်းတိုင်ကြားမှုများတွင် ဗီဒီယိုဆက်သွယ်ရေးကို မတွေ့ရတော့မည်ဟု ကျွန်ုပ်တို့ မျှော်လင့်ထားသည်။ ဤတိုင်ကြားချက်များ၏ အရေးပါသော အစိတ်အပိုင်းသည် သုံးစွဲသူများ၏ ကွန်ပျူတာများနှင့် အင်တာနက်တွင် နောက်ကျကျန်နေခြင်းနှင့် သက်ဆိုင်ကြောင်း ကျွန်ုပ်တို့ နားလည်သော်လည်း ဤအပိုင်းကို ဆုံးဖြတ်ပြီး ကျန်များကို ဖြေရှင်းရပါမည်။ အခြားအရာအားလုံးသည် နည်းပညာဆိုင်ရာ ပြဿနာဖြစ်သည်၊ ၎င်းကို ကျွန်ုပ်တို့ ကိုင်တွယ်ဖြေရှင်းသင့်ပုံရသည်။

အဓိက အခက်အခဲကတော့ အရည်အသွေး မြှင့်တင်ဖို့ ဘယ်အဆင့်အထိ ဖြစ်နိုင်မလဲဆိုတာ မသိရသေးပါဘူး။ ဤမျက်နှာကျက်ကိုရှာဖွေခြင်းသည် အဓိကအလုပ်ဖြစ်သည်။ ထို့ကြောင့်၊ စမ်းသပ်မှုနှစ်ခုကို စီစဉ်ထားသည်-

1. တိုက်ပွဲအခြေအနေများတွင် ပုံမှန် p2p နှင့် Janus မှတစ်ဆင့် ဗီဒီယိုကို နှိုင်းယှဉ်ပါ။ ဤစမ်းသပ်ချက်ကို လုပ်ဆောင်ပြီးဖြစ်သည်၊ ကျွန်ုပ်တို့၏ဖြေရှင်းချက်နှင့် p2p အကြား ကိန်းဂဏန်းအရ သိသာထင်ရှားသော ခြားနားချက်ကို မတွေ့ရှိရပါ။
2. ဗီဒီယိုဆက်သွယ်ရေးဖြေရှင်းချက်များအတွက် သီးသန့်ငွေရှာသည့်ကုမ္ပဏီများထံမှ (စျေးကြီးသော) ဝန်ဆောင်မှုများကို ထောက်ပံ့ပေးပြီး ၎င်းတို့ထံမှ အဆိုးမြင်မှုပမာဏကို ရှိပြီးသားတစ်ခုနှင့် နှိုင်းယှဉ်ကြည့်ကြပါစို့။

ဤစမ်းသပ်ချက်နှစ်ခုသည် ကျွန်ုပ်တို့အား အောင်မြင်နိုင်သည့်ပန်းတိုင်ကို ဖော်ထုတ်နိုင်ပြီး ၎င်းကို အာရုံစိုက်နိုင်စေမည်ဖြစ်သည်။

ထို့အပြင်၊ ပုံမှန်ဖြေရှင်းနိုင်သော အလုပ်များစွာရှိပါသည်။

• ပုဂ္ဂိုလ်ရေးဆိုင်ရာ သုံးသပ်ချက်များအစား ဆက်သွယ်ရေးအရည်အသွေး၏ နည်းပညာဆိုင်ရာ မက်ထရစ်ကို ကျွန်ုပ်တို့ ဖန်တီးပါသည်။
• ကျရှုံးမှုများကို ပိုမိုတိကျစွာခွဲခြမ်းစိတ်ဖြာရန်၊ ၎င်းတို့ဖြစ်ပွားသည့်အချိန်နှင့် နေရာအတိအကျကို နားလည်ရန်နှင့် ထိုအချိန်တွင် မည်သို့မျှမသက်ဆိုင်ဟုထင်ရသော အဖြစ်အပျက်များကို သိရှိနိုင်စေရန်အတွက် ကျွန်ုပ်တို့သည် ပိုမိုအသေးစိတ်သော session မှတ်တမ်းများကို ပြုလုပ်ပါသည်။
• ကျွန်ုပ်တို့သည် သင်ခန်းစာမစမီ အလိုအလျောက်ချိတ်ဆက်မှုအရည်အသွေးစစ်ဆေးမှုကို ပြင်ဆင်ပြီး သုံးစွဲသူအား ၎င်း၏ဟာ့ဒ်ဝဲနှင့် ချန်နယ်ကြောင့် ဖြစ်ပေါ်လာသော အဆိုးမြင်မှုပမာဏကို လျှော့ချရန်အတွက် ချိတ်ဆက်မှုကို ကိုယ်တိုင်စမ်းသပ်ရန် အခွင့်အရေးပေးပါသည်။
• ကျွန်ုပ်တို့သည် မပြောင်းလဲနိုင်သော ပက်ကေ့ချ်ဆုံးရှုံးမှု စသည်တို့ဖြင့် ညံ့ဖျင်းသောအခြေအနေများတွင် ဗီဒီယိုဆက်သွယ်မှု ဝန်စမ်းသပ်မှုများကို တီထွင်ပြီး လုပ်ဆောင်ပါမည်။
• ကျွန်ုပ်တို့သည် အမှားခံနိုင်ရည်ကို တိုးမြှင့်ရန်အတွက် ပြဿနာများရှိသောအခါတွင် ဆာဗာများ၏ အပြုအမူကို ပြောင်းလဲပါသည်။
• Skype ကဲ့သို့ပင် ၎င်း၏ချိတ်ဆက်မှုတွင် တစ်စုံတစ်ရာ မှားယွင်းနေပါက သုံးစွဲသူအား သတိပေးမည်ဖြစ်ပြီး ပြဿနာမှာ ၎င်း၏ဘက်တွင်ရှိကြောင်း နားလည်စေရန်။

ဧပြီလကတည်းက ဗီဒီယိုဆက်သွယ်ရေးဦးတည်ချက်သည် Vimbox ၏တစ်စိတ်တစ်ပိုင်းမျှသာမက ၎င်း၏ကိုယ်ပိုင်ထုတ်ကုန်နှင့်ဆက်ဆံသည့် Skyeng အတွင်းရှိ ပြီးပြည့်စုံသော သီးခြားပရောဂျက်တစ်ခုဖြစ်လာသည်။ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် လူများကို စတင်ရှာဖွေနေပြီဖြစ်သည်။ အချိန်ပြည့်မုဒ်တွင် ဗီဒီယိုဖြင့် အလုပ်လုပ်သည်။. ကောင်းပြီ၊ လူကောင်းတွေ အများကြီး ရှာနေတယ်။.

ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ဗီဒီယိုဆက်သွယ်မှုများဖြင့် လုပ်ဆောင်နေသော လူများနှင့် ကုမ္ပဏီများနှင့် ဆက်လက်တက်ကြွစွာ ဆက်သွယ်နေပါသည်။ ကျွန်ုပ်တို့နှင့် အတွေ့အကြုံဖလှယ်လိုပါက ဝမ်းမြောက်မိပါသည်။ Comment မှာ ဆက်သွယ်လိုက်ပါ - အားလုံးပဲ ဖြေပေးပါ့မယ်။

source: www.habr.com