OpenAI သည် နောက်ကျချိန်-နည်းသော အသံ AI ကို ကျယ်ကျယ်ပြန့်ပြန့် ပေးစွမ်းပုံ

အသံ AI သည် စကားပြောနှုန်းအတိုင်း စီးဆင်းမှသာ သဘာဝကျသည်ဟု ခံစားရသည်။ ကွန်ရက်က အဟန့်အတားဖြစ်လာသည့်အခါ လူတွေက အဆင်မပြေတဲ့ ခေတ္တရပ်တန့်မှုများ၊ ပြတ်တောက်သလိုဖြစ်တဲ့ ကြားဖြတ်မှုများ၊ သို့မဟုတ် နှောင့်နှေးတဲ့ ဝင်ပြောမှုများအဖြစ် ချက်ချင်း ကြားသိရပါသည်။ ၎င်းသည် ChatGPT အသံအတွက်၊ Realtime API ဖြင့် တည်ဆောက်နေသော ဆော့ဖ်ဝဲရေးသားသူများအတွက်၊ အပြန်အလှန်လုပ်ဆောင်ရသော လုပ်ငန်းစဉ်များတွင် လုပ်ဆောင်နေသည့် အေးဂျင့်များအတွက်၊ အသုံးပြုသူက ပြောနေဆဲအချိန်တွင် အသံကို စီမံလုပ်ဆောင်ရန် လိုအပ်သော မော်ဒယ်များအတွက် အရေးကြီးသည်။

OpenAI ၏ အတိုင်းအတာအရ၊ ၎င်းသည် တိကျသော လိုအပ်ချက် သုံးရပ်ကို ဆိုလိုသည်-

• အပတ်စဉ် တက်ကြွစွာအသုံးပြုသူ သန်း ၉၀၀ ကျော်အတွက် ကမ္ဘာလုံးဆိုင်ရာ လွှမ်းခြုံမှု
• ဆက်ရှင် စတင်သည်နှင့် အသုံးပြုသူ စတင်ပြောဆိုနိုင်ရန် မြန်ဆန်သော ချိတ်ဆက်မှု စနစ်ထည့်သွင်းခြင်း
• မီဒီယာ အသွားအပြန် ကြာချိန်နည်းပါးပြီး တည်ငြိမ်သည်၊ jitter နှင့် packet loss နည်းပါးသောကြောင့် လှည့်ပတ်ကြည့်ရှုခြင်းသည် ကြည်လင်ပြတ်သားသည်ဟု ခံစားရသည်

real-time AI interaction များအတွက် တာဝန်ရှိသော OpenAI မှအဖွဲ့သည် မကြာသေးမီက ကျွန်ုပ်တို့၏ WebRTC stack ကို ပြန်လည်ပြင်ဆင်ခဲ့ပြီး အတိုင်းအတာတစ်ခုအထိ ထိပ်တိုက်တွေ့လာသော ကန့်သတ်ချက်သုံးခုကို ဖြေရှင်းဖို့ကြိုးပမ်းသည်- one-port-per-session media termination သည် OpenAI infrastructure နှင့် ကောင်းစွာမကိုက်ညီခြင်း၊ stateful ICE (Interactive Connectivity Establishment) နှင့် DTLS (Datagram Transport Layer Security) ဆက်ရှင်များသည် တည်ငြိမ်သောပိုင်ဆိုင်မှုလိုအပ်ခြင်းနှင့် global routing သည် first-hop latency ကိုနိမ့်ကျအောင်ထားရန်လိုအပ်သည်။ ဤပို့စ်တွင်၊ ဖောက်သည်များအတွက် စံ WebRTC အပြုအမူကို ထိန်းသိမ်းထားစဉ် OpenAI ၏ အခြေခံအဆောက်အအုံအတွင်း ပက်ကတ် များကို လမ်းကြောင်းပြောင်းလဲပို့ဆောင်နိုင်ရန် ကျွန်ုပ်တို့ တည်ဆောက်ထားသည့် ခွဲခြားထားသော relay နှင့် transceiver အဆောက်အအုံအကြောင်း အဆင့်ဆင့် ရှင်းလင်းဖော်ပြထားပါသည်။

WebRTC သည် ဘရောက်ဇာများ၊ မိုဘိုင်းအက်ပ်များနှင့် ဆာဗာများအကြား နောက်ကျချိန်နည်းသော အသံ၊ ဗီဒီယိုနှင့် ဒေတာများကို ပေးပို့ရန်အတွက် အဖွင့်စံနှုန်းတစ်ခု ဖြစ်သည်။ ၎င်းကို peer-to-peer ခေါ်ဆိုမှုနှင့် မကြာခဏ ဆက်စပ်မြင်ကြသော်လည်း client-to-server အချိန်နှင့်တပြေးညီ စနစ်များအတွက်မှာမူလက်တွေ့ကျသော အခြေခံအုတ်မြစ်တစ်ခု ဖြစ်သည်။ အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် interactive media ၏ ခက်ခဲသော အပိုင်းများကို စံနှုန်းသတ်မှတ်ပေးသောကြောင့် ဖြစ်သည်- ချိတ်ဆက်မှု တည်ဆောက်ခြင်းနှင့် NAT (Network Address Translation) ကျော်ဖြတ်ခြင်းအတွက် ICE၊ ကုဒ်ဝှက်ထားသော ပို့လွှတ်မှုအတွက် DTLS နှင့် SRTP (Secure Real-time Transport Protocol)၊ အသံကို ချုံ့ခြင်းနှင့် ဒီကုဒ်လုပ်ခြင်းအတွက် codec ညှိနှိုင်းမှု၊ အရည်အသွေး ထိန်းချုပ်မှုအတွက် RTCP (Real-time Transport Control Protocol)၊ ထို့အပြင် echo cancellation နှင့် jitter buffering ကဲ့သို့သော client-side လုပ်ဆောင်ချက်များ ဖြစ်သည်။

ထိုစံသတ်မှတ်မှုသည် AI ထုတ်ကုန်များအတွက် အရေးပါသည်။ WebRTC မရှိပါက၊ ဖောက်သည်တစ်ဦးချင်းစီသည် NAT များကို ဖြတ်ကျော်၍ ချိတ်ဆက်မှုကို မည်သို့တည်ဆောက်မည်၊ မီဒီယာကို မည်သို့ကုဒ်ဝှက်မည်၊ codec များ (ပေးပို့ခြင်းနှင့် ပြန်လည်ဖြည်ချခြင်းအတွက် ရွေးချယ်ထားသော ကုဒ်ပြု-ပြန်ဖြည်ကိရိယာများ) ကို မည်သို့ညှိနှိုင်းရွေးချယ်မည်နှင့် ပြောင်းလဲနေသော ကွန်ရက်အခြေအနေများနှင့် မည်သို့လိုက်လျောညီထွေဖြစ်မည်ဆိုသည့်အတွက် မတူညီသော ဖြေရှင်းနည်းတစ်ခုစီ လိုအပ်မည်ဖြစ်သည်။ WebRTC ဖြင့်၊ ကျွန်ုပ်တို့သည် ဘရောက်ဇာများနှင့် မိုဘိုင်းပလက်ဖောင်းများတစ်လျှောက် အကောင်အထည်ဖော်ပြီးသား ပရိုတိုကော stack ကို အခြေခံ၍ တည်ဆောက်နိုင်ပြီး၊ ကျွန်ုပ်တို့၏ကိုယ်ပိုင်လုပ်ငန်းကို အချိန်နှင့်တစ်ပြေးညီ မီဒီယာကို မော်ဒယ်များနှင့် ချိတ်ဆက်ပေးသော အခြေခံအဆောက်အအုံအပေါ် အာရုံစိုက်နိုင်ပါသည်။

ကျွန်ုပ်တို့သည် WebRTC ဂေဟစနစ်ကိုယ်တိုင်အပေါ်တွင်လည်း အခြေခံ၍ တည်ဆောက်ထားပြီး၊ ထိုထဲတွင် ရင့်ကျက်ပြီးသား အခမဲ့အရင်းအမြစ် (open-source) အကောင်အထည်ဖော်မှုများနှင့် ဘရောက်ဇာများ၊ မိုဘိုင်းအက်ပ်များ၊ ဆာဗာများကို အပြန်အလှန် ချိတ်ဆက်လုပ်ဆောင်နိုင်စေသည့် စံသတ်မှတ်ရေးလုပ်ငန်းများ ပါဝင်သည်။ Justin Uberti (WebRTC ၏ မူလ ဗိသုကာပညာရှင်များထဲမှ တစ်ဦး) နှင့် Sean DuBois (Pion ကို ဖန်တီးသူနှင့် ထိန်းသိမ်းသူ) တို့၏ အခြေခံအုတ်မြစ်ချခဲ့သော လုပ်ဆောင်မှုများကြောင့် ကျွန်ုပ်တို့ကဲ့သို့သော အဖွဲ့များအနေဖြင့် အခြေခံအဆင့် သယ်ယူပို့ဆောင်ရေး၊ ကုဒ်ဝှက်ခြင်းနှင့် ကြပ်တည်းမှုထိန်းချုပ်ရေး အပြုအမူများကို အသစ်တဖန် တီထွင်ရန်မလိုဘဲ၊ လက်တွေ့အသုံးပြုမှုတွင် စမ်းသပ်အတည်ပြုပြီးသော မီဒီယာ အခြေခံအဆောက်အအုံပေါ်တွင် တည်ဆောက်နိုင်ခဲ့ပါသည်။ Justin နှင့် Sean နှစ်ဦးစလုံးသည် ယခု OpenAI တွင် ကျွန်ုပ်တို့၏ လုပ်ဖော်ကိုင်ဖက်များ ဖြစ်လာကြပြီး၊ WebRTC နှင့် အချိန်နဲ့တစ်ပြေးညီ AI ကို ပိုမိုနီးကပ်စွာ ပေါင်းစည်းလာအောင် မည်သို့ ဆောင်ရွက်မည်ကို လမ်းညွှန်ကူညီနေကြသည့်အတွက် ကျွန်ုပ်တို့ ကံကောင်းပါသည်။

AI အတွက် အရေးအကြီးဆုံး လက္ခဏာမှာ အသံသည် မပြတ်တောက်သော စီးဆင်းမှုတစ်ခုအဖြစ် ရောက်ရှိလာခြင်းဖြစ်သည်။ ပြောဆိုနိုင်သော အေးဂျင့်တစ်ခုသည် အပြည့်အဝ အပ်လုဒ်လုပ်ပြီးသည်အထိ စောင့်မနေဘဲ၊ အသုံးပြုသူက ပြောနေဆဲအချိန်တွင်ပင် စာသားမှတ်တမ်းပြုလုပ်ခြင်း၊ ကျိုးကြောင်းသင့်လျော်စွာ စဉ်းစားခြင်း၊ ကိရိယာများကို ခေါ်သုံးခြင်း သို့မဟုတ် စကားအသံ ဖန်တီးခြင်းတို့ကို စတင်နိုင်သည်။ အဲဒါက သဘာဝကျကျ အပြန်အလှန် စကားပြောနေသလို ခံစားရတဲ့ စနစ်တစ်ခုနဲ့ push-to-talk (ခလုတ်နှိပ်ပြီးမှ ပြောရတဲ့) စနစ်တစ်ခုလို ခံစားရတဲ့ စနစ်တစ်ခုကြားက ကွာခြားချက်ပါ။

WebRTC ကို ရွေးချယ်ပြီးနောက်၊ နောက်ထပ်မေးခွန်းမှာ ၎င်းကို မည်သည့်နေရာတွင် အဆုံးသတ်မည် (ဥပမာ edge တွင် WebRTC ချိတ်ဆက်မှုကို— ကျွန်ုပ်တို့က လက်ခံပြီး တာဝန်ယူထိန်းချုပ်မည့်နေရာ) နှင့် ထို ဆက်ရှင်များကို အချက်အလက်အဖြေထုတ်လုပ်ဆောင်မှု backend သို့ မည်သို့ချိတ်ဆက်မည် ဖြစ်သည်။ အဆုံးသတ်ခြင်းသည် အရေးကြီးသည်၊ အကြောင်းမှာ ၎င်းက အချိန်နှင့်တပြေးညီ ဆက်ရှင်အခြေအနေ၊ မီဒီယာ ပို့ဆောင်မှု၊ လမ်းကြောင်းချခြင်း၊ နှောင့်နှေးချိန်နှင့် ချို့ယွင်းမှု သီးခြားခွဲထုတ်ခြင်းတို့ကို ကျွန်ုပ်တို့ မည်သို့ ကိုင်တွယ်မည်ကို သတ်မှတ်ပေးသောကြောင့် ဖြစ်သည်။

SFU (selective forwarding unit ဟုလည်းခေါ်သည်) သည် ပါဝင်သူတစ်ဦးစီထံမှ WebRTC စီးကြောင်းတစ်ခုစီကို လက်ခံပြီး အခြားသူများထံ စီးကြောင်းများကို ရွေးချယ်၍ ပို့လွှတ်ပေးသော မီဒီယာ ဆာဗာတစ်ခု ဖြစ်သည်။ ဤမော်ဒယ်တွင် SFU သည် ပါဝင်သူတိုင်းအတွက် သီးခြား WebRTC ချိတ်ဆက်မှုတစ်ခုစီကို အဆုံးမှတ်အဖြစ် ကိုင်တွယ်ပြီး AI သည် ဆက်ရှင်အတွင်း နောက်ထပ် ပါဝင်သူတစ်ဦးအဖြစ် ပါဝင်သည်။ ၎င်းသည် အဖွဲ့လိုက် ခေါ်ဆိုမှုများ၊ စာသင်ခန်းများ သို့မဟုတ် ပူးပေါင်းဆောင်ရွက်သည့် အစည်းအဝေးများကဲ့သို့ သဘာဝအားဖြင့် ပါဝင်သူအများအပြား ပါဝင်သည့် ထုတ်ကုန်များအတွက် သင့်တော်နိုင်ပါသည်။ ၎င်းသည် အော်ဒီယို codec များ၊ RTCP မက်ဆေ့ချ်များ၊ ဒေတာချန်နယ်များ၊ မှတ်တမ်းတင်ခြင်းနှင့် stream တစ်ခုချင်းစီအလိုက် မူဝါဒတို့ကို တစ်နေရာတည်းတွင် စုစည်းထားသည်။¹

client-to-AI ထုတ်ကုန်များတွင်ပင် SFU သည် signaling၊ media routing၊ recording၊ observability နှင့် လူသားထံ လွှဲပြောင်းခြင်း သို့မဟုတ် ပါဝင်သူများ ပိုမိုထည့်သွင်းခြင်းကဲ့သို့သော နောင်တိုးချဲ့မှုများအတွက် သက်သေပြပြီးသော စနစ်တစ်ခုတည်းကို အဖွဲ့များ ပြန်လည်အသုံးပြုနိုင်စေသောကြောင့် မကြာခဏ စတင်ရန် ပုံမှန်ရွေးချယ်မှု ဖြစ်နေတတ်သည်။

ကျွန်ုပ်တို့၏ လုပ်ငန်းတာဝန်များသည် ကွဲပြားပါသည်။ ဆက်ရှင်အများစုသည် 1:1 ဖြစ်သည်—အသုံးပြုသူတစ်ဦးက မော်ဒယ်တစ်ခုနှင့် စကားပြောခြင်း သို့မဟုတ် အပလီကေးရှင်းတစ်ခုက အချိန်နှင့်တပြေးညီ အေးဂျင့်တစ်ခုနှင့် ဆက်သွယ်ခြင်းဖြစ်ပြီး—အလှည့်တိုင်းတွင် latency ကို အထူးအရေးထားရသည်။ ထို traffic ပုံစံအတွက် ကျွန်ုပ်တို့သည် transceiver မော်ဒယ်တစ်ခုကို ရွေးချယ်ခဲ့သည်- WebRTC edge service တစ်ခုက ဖောက်သည် ချိတ်ဆက်မှုကို အဆုံးမှတ်အဖြစ် လက်ခံပြီးနောက် မီဒီယာနှင့် ဖြစ်ရပ်များကို မော်ဒယ် အချက်အလက်အဖြေထုတ်လုပ်ဆောင်မှု၊ စာသားမှတ်တမ်းပြုလုပ်ခြင်း၊ စကားပြောသံ ထုတ်လုပ်ခြင်း၊ ကိရိယာအသုံးပြုခြင်းနှင့် လုပ်ငန်းစဉ်ညှိနှိုင်းစီမံခြင်းတို့အတွက် ပိုမိုရိုးရှင်းသော အတွင်းပိုင်း ပရိုတိုကောလ်များအဖြစ် ပြောင်းလဲပေးသည်။

ဤဒီဇိုင်းတွင် transceiver သည် ICE ချိတ်ဆက်နိုင်မှု စစ်ဆေးမှုများ၊ DTLS handshake၊ SRTP encryption keys နှင့် ဆက်ရှင် အသက်စက်ဝန်းတို့ အပါအဝင် WebRTC ဆက်ရှင်အခြေအနေကို ပိုင်ဆိုင်ပြီး ထိန်းသိမ်းသော တစ်ခုတည်းသော ဝန်ဆောင်မှု ဖြစ်သည်။ ဤနေရာတွင် “Termination” ဟုဆိုသည်မှာ transceiver သည် အဆိုပါ handshake လုပ်ငန်းစဉ်များကို အပြီးသတ်ပြီး မီဒီယာကို စာဝှက်ခြင်း သို့မဟုတ် စာဝှက်ဖြည်ခြင်း ပြုလုပ်သည့် အဆုံးမှတ်ဖြစ်သည်ဟု ဆိုလိုသည်။ ထိုအခြေအနေ တစ်နေရာတည်းမှာ ထားရှိခြင်းက session ownership ကို ပိုမိုလွယ်ကူစွာ နားလည်သုံးသပ်နိုင်စေခဲ့ပြီး၊ backend services များကို ၎င်းတို့ကိုယ်တိုင် WebRTC peers များအဖြစ် လုပ်ဆောင်ရမည့်အစား သာမန်ဝန်ဆောင်မှုများကဲ့သို့ အတိုင်းအတာတိုးချဲ့နိုင်စေခဲ့သည်။

transceiver မော်ဒယ်ကို ရွေးချယ်ပြီးနောက်၊ ကျွန်ုပ်တို့၏ ပထမဆုံး အကောင်အထည်ဖော်မှုမှာ Pion ကို အခြေခံ၍ တည်ဆောက်ထားသည့် Go service တစ်ခုတည်းဖြစ်ပြီး ၎င်းက signaling နှင့် media termination နှစ်ခုလုံးကို ကိုင်တွယ်ခဲ့သည်။ ၎င်းသည် ChatGPT အသံ၊ Realtime API ၏ WebRTC အဆုံးမှတ်နှင့် သုတေသနပရောဂျက်များစွာကို စွမ်းအားပေးထားသည်။

လုပ်ငန်းလည်ပတ်မှုအရ၊ ထရန်စီဗာ ဝန်ဆောင်မှုသည် တာဝန်နှစ်ခုကို လုပ်ဆောင်ပါသည်-

• အချက်ပြခြင်း- SDP ညှိနှိုင်းမှု၊ codec ရွေးချယ်မှု၊ ICE အထောက်အထားများနှင့် ဆက်ရှင်သတ်မှတ်ခြင်း
• မီဒီယာ- နောက်ဆက်တွဲ WebRTC ချိတ်ဆက်မှုများကို အဆုံးသတ်ခြင်းနှင့် ခန့်မှန်းထုတ်ယူခြင်းနှင့် စီမံခန့်ခွဲမှု (orchestration) အတွက် backend ဝန်ဆောင်မှုများသို့ ရှေ့ဆက် upstream ချိတ်ဆက်မှုများကို ဆက်လက်ထိန်းသိမ်းခြင်း

ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုကို ကျွန်ုပ်တို့၏ အခြေခံအဆောက်အအုံ၏ အခြားအစိတ်အပိုင်းများကဲ့သို့ပင် Kubernetes ပေါ်တွင် လည်ပတ်စေလိုခဲ့သည်။ ထိုနေရာတွင် workload များသည် လိုအပ်ချက် ပြောင်းလဲလာသည်နှင့်အမျှ ချဲ့ထွင်ခြင်းနှင့် လျှော့ချခြင်း ပြုလုပ်နိုင်ပြီး host များအကြား ရွှေ့ပြောင်းနိုင်သည်။ သို့သော် သမားရိုးကျ WebRTC မော်ဒယ်သည် တစ်ခုလျှင် ပေါ့တ်တစ်ခုသာ အသုံးပြုသောကြောင့် ထိုပတ်ဝန်းကျင်နှင့် ကောင်းစွာ မကိုက်ညီပါ၊ အကြောင်းမှာ ၎င်းသည် ပေါ့ဒ်များကို ထည့်သွင်းခြင်း၊ ဖယ်ရှားခြင်း သို့မဟုတ် ပြန်လည်စီစဉ်ခြင်းအခါတွင် ထုတ်ဖော်ဖွင့်ပေးရန်၊ လုံခြုံအောင်ပြုလုပ်ရန်နှင့် ဆက်လက်ထိန်းသိမ်းရန် ခက်ခဲသော အများပြည်သူသုံး UDP ပေါ့တ် အကွာအဝေးကြီးများပေါ်တွင် မှီခိုနေသောကြောင့် ဖြစ်သည်။²

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

• Cloud load balancers နှင့် Kubernetes service များကို service တစ်ခုလျှင် public UDP ports သောင်းချီ အသုံးပြုမည့်ပုံစံကို အခြေခံ၍ ဒီဇိုင်းထုတ်ထားခြင်း မဟုတ်ပါ။ ထပ်မံထည့်သွင်းသော range တစ်ခုချင်းစီသည် load balancer config၊ ကျန်းမာရေး စစ်ဆေးမှု၊ firewall policy နှင့် rollout ဘေးကင်းရေးတို့တွင် လုပ်ငန်းလည်ပတ်မှုဆိုင်ရာ ရှုပ်ထွေးမှုကို တိုးစေသည်။³
• ကျယ်ပြန့်သော UDP port range များကို လုံခြုံအောင် ထိန်းသိမ်းရန် ခက်ခဲပါသည်၊ အဘယ်ကြောင့်ဆိုသော် ၎င်းတို့သည် ပြင်ပမှ ရောက်ရှိနိုင်သည့် ထိတွေ့နယ်ပယ်ကို တိုးချဲ့စေပြီး ကွန်ရက် မူဝါဒကို စစ်ဆေးသုံးသပ်ရန် ပိုမိုခက်ခဲစေသောကြောင့် ဖြစ်ပါသည်။
• ၎င်းတို့သည်လည်း အလိုအလျောက် စကေးချိန်ညှိခြင်းအတွက် မသင့်တော်ပါ။ Kubernetes တွင် Pod များကို အဆက်မပြတ် ထည့်သွင်းခြင်း၊ ဖယ်ရှားခြင်းနှင့် ပြန်လည်စီစဉ်ချထားခြင်းများ ပြုလုပ်နေပါသည်။ Pod တစ်ခုချင်းစီကို ကြီးမားပြီး တည်ငြိမ်သော port အပိုင်းအခြားတစ်ခုအဖြစ် သီးသန့်ချန်ထားကာ ကြော်ငြာဖို့ လိုအပ်စေခြင်းသည် ထိုဆန့်ကျုံ့နိုင်စွမ်းကို ကျိုးပြတ်စေသည်။⁴

ဤအကြောင်းကြောင့် WebRTC စနစ်အများအပြားသည် ဆာဗာတစ်ခုလျှင် UDP port တစ်ခုတည်းသာ အသုံးပြုသည့်ပုံစံသို့ ဦးတည်လာကြပြီး ထို port နောက်ကွယ်တွင် application-level demultiplexing ကို ဆောင်ရွက်ကြသည်။⁵

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

ICE နှင့် DTLS တို့သည် အခြေအနေကို ထိန်းသိမ်းထားသော ပရိုတိုကောများ ဖြစ်သည်။ ဆက်ရှင်တစ်ခုကို ဖန်တီးခဲ့သော လုပ်ငန်းစဉ်သည် ချိတ်ဆက်နိုင်မှု စစ်ဆေးချက်များကို အတည်ပြုနိုင်ရန်၊ DTLS handshake ကို ပြီးမြောက်စေရန်၊ SRTP ကို ကုဒ်ဖြည်နိုင်ရန်နှင့် ICE ပြန်လည်စတင်မှုများကဲ့သို့သော နောက်ပိုင်း ဆက်ရှင်ပြောင်းလဲမှုများကို စီမံဆောင်ရွက်နိုင်ရန် ထိုဆက်ရှင်၏ ပက်ကက်များကို ဆက်လက်လက်ခံနေရန် လိုအပ်သည်။ တူညီသော ဆက်ရှင်အတွက် ပက်ကက်များသည် မတူညီသော လုပ်ငန်းစဥ်တစ်ခုပေါ်သို့ ရောက်ရှိသွားပါက၊ ပြင်ဆင်မှု မအောင်မြင်နိုင်သည် သို့မဟုတ် မီဒီယာ ပျက်ယွင်းနိုင်သည်။

ထိုအရာက ကျွန်ုပ်တို့အတွက် တိကျသော ရည်မှန်းချက်တစ်ခုကို ပေးခဲ့သည် - သေးငယ်ပြီး ပုံသေသတ်မှတ်ထားသော UDP (User Datagram Protocol) ထိတွေ့ဧရိယာတစ်ခုကို အများပြည်သူသုံး အင်တာနက်သို့ ဖော်ထုတ်ထားရန်၊ တစ်ချိန်တည်းမှာ သက်ဆိုင်ရာ WebRTC session ကို ပိုင်ဆိုင်သည့် transceiver ဆီသို့ ပက်ကတ်တိုင်းကို ဆက်လက် လမ်းကြောင်းသွင်းပို့ရန် ဖြစ်သည်။

ထိုရည်မှန်းချက်ကို ရောက်ရှိရန် နည်းလမ်းအမျိုးမျိုးကို ကျွန်ုပ်တို့ အကဲဖြတ်ခဲ့ပြီး၊ ၎င်းတွင် TURN (NAT ပတ်ပတ်လည်တွင် ရီလေးများကို အသုံးပြု၍ Traversal ပြုလုပ်ခြင်း) လည်း ပါဝင်ပါသည်။ ၎င်းတွင် edge relay တစ်ခုက ဖောက်သည် လျာထားမှုများကို အဆုံးပိုင်းအဖြစ် လက်ခံဆောင်ရွက်ပြီး ၎င်းတို့ကိုယ်စား traffic ကို ဆက်လက်ပေးပို့ပါသည်။²

ကျွန်ုပ်တို့ ထုတ်ပေးခဲ့သော ဗိသုကာဖွဲ့စည်းပုံသည် ပက်ကတ်လမ်းကြောင်းပို့ခြင်းကို ပရိုတိုကော အဆုံးသတ်လုပ်ဆောင်ခြင်းမှ ခွဲထုတ်ထားသည်။ ဆက်ရှင်တည်ဆောက်မှု (session setup) အတွက် အချက်ပြဆက်သွယ်မှု (signaling) သည် ထုတ်လွှင့်/လက်ခံစက် (transceiver) ထံသို့ ဆက်လက်ရောက်ရှိနေသေးသော်လည်း၊ မီဒီယာဒေတာသည် ပထမဦးစွာ ကြားခံ ရီလေးမှတစ်ဆင့် ဝင်ရောက်လာသည်။ ရီလေးသည် အများပြည်သူဘက်သို့ ဖော်ထုတ်ထားမှု နည်းပါးသော ပေါ့ပါးသည့် UDP forwarding layer တစ်ခုဖြစ်ပြီး၊ transceiver သည် ၎င်း၏ နောက်ကွယ်ရှိ အခြေအနေထိန်းသိမ်းထားသော WebRTC အဆုံးမှတ် ဖြစ်သည်။

ရီလေးသည် မီဒီယာကို စာဝှက်ဖြည်ခြင်း၊ ICE state machine များကို လည်ပတ်စေခြင်း၊ သို့မဟုတ် codec ညှိနှိုင်းမှုတွင် ပါဝင်ခြင်း မပြုပါ။ ၎င်းသည် ဦးတည်ရာတစ်ခုကို ရွေးချယ်ရန် ပက်ကတ် မက်တာဒေတာကို လုံလောက်သလောက် ဖတ်ပြီး၊ ထို့နောက် ပက်ကတ်အား ဆက်ရှင်ကို ပိုင်ဆိုင်ထားသော ထရန်စီဗာထံသို့ ပေးပို့သည်။ ထရန်စီဗာသည် ပုံမှန် WebRTC စီးဆင်းမှုတစ်ခုကို ဆက်လက်မြင်တွေ့နေပြီး ပရိုတိုကောအခြေအနေအားလုံးကိုလည်း ဆက်လက်ပိုင်ဆိုင်ထားနေသည်။ ဖောက်သည်၏ ရှုထောင့်မှ ကြည့်လျှင် WebRTC ဆက်ရှင်နှင့်ပတ်သက်၍ ဘာမှ မပြောင်းလဲပါ။

ပထမပက်ကက် လမ်းကြောင်းသတ်မှတ်ခြင်းသည် ဤပြင်ဆင်မှုတွင် အဓိကအဆင့်ဖြစ်သည်။ ရီလေးတစ်ခုသည် external lookup service တွင် ခေတ္တရပ်ခြင်းဖြင့် မဟုတ်ဘဲ packet path ပေါ်တွင် မည်သည့် ဆက်ရှင်မှ မတည်ရှိမီ ဖောက်သည်မှ ပထမဆုံး packet ကို လမ်းကြောင်းပြောင်းပေးရမည်။

WebRTC session တိုင်းတွင် protocol-native routing hook တစ်ခုပါရှိပြီးဖြစ်သည်- ICE အသုံးပြုသူအမည် အပိုင်းအစ သို့မဟုတ် ufragဖြစ်ကာ၊ ၎င်းသည် session setup အတွင်း ဖလှယ်ပြီး STUN ချိတ်ဆက်မှုစစ်ဆေးမှုများတွင် ပဲ့တင်ထပ်သည့် short identifier တစ်ခုဖြစ်သည်။ ကျွန်ုပ်တို့သည် server-side ufrag ကို ထုတ်လုပ်သောကြောင့် ရီလေးတွင် destination cluster နှင့် owning transceiver ကို ရည်ညွှန်းနိုင်စေရန် လုံလောက်သော routing metadata ပါဝင်ပါသည်။

Signaling ပြုလုပ်နေစဉ်အတွင်း transceiver သည် session state ကို ခွဲဝေသတ်မှတ်ပြီး SDP အဖြေထဲတွင် မျှဝေထားသော ရီလေး VIP နှင့် UDP port ကို ပြန်လည်ပေးပို့သည်။ VIP ဆိုသည်မှာ relay fleet ရှေ့တွင်ရှိသော virtual IP address တစ်ခုဖြစ်သည်။ port နှင့်ပေါင်းစပ်လိုက်သောအခါ relay instance အများအပြားရှိသော်လည်း ဖောက်သည်ထံ `203.0.113.10:3478` ကဲ့သို့သော တည်ငြိမ်သော destination တစ်ခုကို ပေးပါသည်။ ဖောက်သည်၏ ပထမဆုံး media-path packet သည် များသောအားဖြင့် STUN (NAT အတွက် Session Traversal Utilities) binding request ဖြစ်ပြီး၊ ၎င်းကို ICE က packet များသည် ကြေညာထားသော လိပ်စာသို့ ရောက်ရှိနိုင်ကြောင်း အတည်ပြုရန် အသုံးပြုသည်။

ရီလေးသည် server ufrag ကို ဖတ်ရန်၊ routing hint ကို ကုဒ်ဖြည်ရန်နှင့် packet ကို ၎င်းအား ပိုင်ဆိုင်သော transceiver ထံသို့ ပို့ပေးရန်အတွက် ပထမဆုံး STUN packet ကို လိုအပ်သလောက်သာ ခွဲခြမ်းစိတ်ဖြာသည်။ Transceiver တစ်ခုစီသည် မျှဝေထားသော UDP ဆော့ကတ်တစ်ခုပေါ်တွင် နားထောင်သည်၊ ဆိုလိုသည်မှာ ဆက်ရှင်တစ်ခုလျှင် ဆော့ကတ်တစ်ခုစီ မဟုတ်ဘဲ internal IP:port တစ်ခုသို့ bind လုပ်ထားသော operating system အဆုံးမှတ် တစ်ခုဖြစ်သည်။ ရီလေးသည် ဖောက်သည်၏ source IP:port မှ ထို transceiver destination သို့ ဆက်ရှင်တစ်ခု ဖန်တီးပြီးနောက်၊ နောက်ဆက်တွဲ DTLS၊ RTP နှင့် RTCP packets များသည် ufrag ကို ထပ်မံ decode မလုပ်ဘဲ ဆက်ရှင်အတွင်း စီးဆင်းသွားသည်။

ရီလေး၏ ဆက်ရှင်ကို ရည်ရွယ်ချက်ရှိရှိ အနည်းဆုံးသာ ထားရှိထားပြီး၊ packet forwarding ကို လမ်းညွှန်ရန်အတွက် memory အတွင်းရှိ ဆက်ရှင်တစ်ခုသာ ပါဝင်သည်။ ထို့အပြင် စောင့်ကြည့်မှုအတွက် လိုအပ်သော counters များနှင့် ဆက်ရှင် သက်တမ်းကုန်ဆုံးခြင်းနှင့် ရှင်းလင်းဖယ်ရှားခြင်းအတွက် timers များလည်း ပါဝင်သည်။ ဤဒီဇိုင်းရွေးချယ်မှုသည် packet routing ကို packet path ပေါ်တွင် တိုက်ရိုက်ရှိနေစေရန် ထိန်းသိမ်းပေးသည်။ ရီလေးတစ်ခု ပြန်လည်စတင်ပြီး ဆက်ရှင်ကို ဆုံးရှုံးသွားပါက၊ နောက်ထပ် STUN ပက်ကတ်သည် ufrag လမ်းကြောင်းညွှန်ပြချက်မှ ဆက်ရှင်ကို ပြန်လည်တည်ဆောက်သည်။ ပိုမိုယုံကြည်စိတ်ချရစေရန်၊ လမ်းကြောင်းကို တည်ဆောက်ပြီးသည်နှင့် <client IP + Port, transceiver IP + Port> ၏ မက်ပင်းကို သိမ်းထားရန် Redis ကက်ရှ်ကို အသုံးပြုထားသည်၊ ထို့ကြောင့် နောက် STUN ပက်ကတ် မရောက်လာမီ ပိုမိုစောစီးစွာ ၎င်းကို ပြန်လည်ရယူနိုင်ပါသည်။

အများပြည်သူသို့ ဖွင့်ထားသော UDP surface ကို တည်ငြိမ်သော လိပ်စာများနှင့် ပေါ့တ်များ အနည်းငယ်သာ ဖြစ်အောင် လျှော့ချပြီးနောက်၊ ကျွန်ုပ်တို့သည် တူညီသော relay pattern ကို ကမ္ဘာတစ်ဝန်း တပ်ဆင်အသုံးပြုနိုင်ခဲ့ပါသည်။ Global Relay သည် တူညီသော packet-forwarding အပြုအမူကို အကောင်အထည်ဖော်ထားသည့်၊ ပထဝီဝင်အရ ဖြန့်ဝေထားသော ရီလေး အဝင်အမှတ်များ၏ စုစည်းကွန်ရက်ဖြစ်သည်။

ပထဝီဝင်အရ ကျယ်ပြန့်စွာ ဖြန့်ကျက်ထားသော ဝင်ရောက်မှတ်များသည် ပထမဆုံး client မှ OpenAI သို့သွားရာ hop ကို တိုစေသည်။ အကြောင်းမှာ ပက်ကက်တစ်ခုသည် အဝေးဒေသတစ်ခုဆီသို့ အများသုံးအင်တာနက်ကို ဖြတ်သန်းရန်မလိုဘဲ၊ ပထဝီဝင်အရသာမက ကွန်ရက် topology အရပါ အသုံးပြုသူနှင့် နီးကပ်သော ရီလေးတစ်ခုမှ ကျွန်ုပ်တို့၏ ကွန်ရက်ထဲသို့ ဝင်ရောက်နိုင်သောကြောင့် ဖြစ်သည်။ လက်တွေ့အားဖြင့်ဆိုရလျှင်၊ ၎င်းသည် ဒေတာအသွားအလာ ကျွန်ုပ်တို့၏ backbone ကွန်ရက်သို့ မရောက်ရှိမီ တုံ့ပြန်မှုအချိန် ပိုမိုနည်းပါးခြင်း၊ jitter ပိုနည်းခြင်းနှင့် ရှောင်လွှဲနိုင်သော ဆုံးရှုံးမှု burst များ ပိုမိုနည်းပါးခြင်းတို့ကို ဆိုလိုသည်။⁶

အချက်ပြဆက်သွယ်မှုအတွက် ကျွန်ုပ်တို့သည် Cloudflare ၏ geo steering နှင့် proximity steering ကို အသုံးပြုသောကြောင့် ကနဦး HTTP (သို့မဟုတ်) WebSocket တောင်းဆိုမှုသည် အနီးရှိ transceiver cluster တစ်ခုသို့ ရောက်ရှိစေပါသည်။ တောင်းဆိုချက်၏ context သည် ဆက်ရှင်၏ တည်နေရာနှင့် ဖောက်သည်ထံ ကြေညာပြသမည့် Global Relay ingress point ကို သတ်မှတ်ပေးပါသည်။ SDP အဖြေသည် Global Relay လိပ်စာကို ပေးဆောင်ပြီး၊ ufrag တွင် Global Relay က မီဒီယာကို သတ်မှတ်ထားသော cluster သို့ route လုပ်နိုင်ရန်နှင့် ရီလေးက destination transceiver သို့ route လုပ်နိုင်ရန် လုံလောက်သော အချက်အလက်များ ပါဝင်သည်။

ပေါင်းစည်းအသုံးပြုသောအခါ၊ ပထဝီအခြေခံ လမ်းကြောင်းညွှန်ထိန်းချုပ်မှုနှင့် Global Relay တို့သည် setup နှင့် media နှစ်မျိုးလုံးကို အနီးအနားရှိ ဝင်ရောက်လမ်းကြောင်းပေါ်တွင် ထားရှိပေးပြီး၊ session ကို transceiver တစ်ခုတည်းတွင် anchor လုပ်ထားစေသည်။ ၎င်းသည် signaling နှင့် ပထမဆုံး ICE ချိတ်ဆက်မှု စစ်ဆေးမှုအတွက် အသွားအပြန် ကြာချိန်ကို လျှော့ချပေးသည်၊ ထို့ကြောင့် စကားပြောဆိုမှု စတင်နိုင်မီ အသုံးပြုသူ စောင့်ဆိုင်းရမည့်အချိန်ကို တိုက်ရိုက် လျှော့ချပေးသည်။

ကျွန်ုပ်တို့သည် ရီလေးဝန်ဆောင်မှုကို Go တွင် ရေးသားခဲ့ပြီး အကောင်အထည်ဖော်မှု၏ အကျယ်အဝန်းကို ရည်ရွယ်ချက်ရှိရှိ ကန့်သတ်ထားခဲ့သည်။ Linux တွင် kernel ၏ ကွန်ရက်ဆိုင်ရာ stack သည် စက်၏ ကွန်ရက် အင်တာဖေ့စ်မှ UDP ပက်ကတ်များကို လက်ခံရယူပြီး ဆော့ကတ်တစ်ခုသို့ ပို့ဆောင်ပေးသည်။ ထိုဆော့ကတ်သည် process တစ်ခုက IP:Port တစ်ခုကို bind လုပ်ပြီးနောက် ဖတ်ယူသော လည်ပတ်မှုစနစ် အဆုံးမှတ်ဖြစ်သည်။ ရီလေးသည် userspace တွင် လည်ပတ်သောကြောင့် ပုံမှန် Go process တစ်ခုက ထိုဆော့ကတ်မှ packet headers များကို ဖတ်ရှုပြီး flow state အနည်းငယ်ကို အပ်ဒိတ်လုပ်ကာ WebRTC ကို terminate မလုပ်ဘဲ packets များကို ဆက်လက် ပို့ပေးသည်။ ပိုမိုမြင့်မားသော packet နှုန်းများအတွက် userspace process တစ်ခုအား network queues များကို တိုက်ရိုက် poll လုပ်ခွင့်ပေးမည်ဖြစ်သော်လည်း လည်ပတ်ရေးဆိုင်ရာ ရှုပ်ထွေးမှုကိုလည်း အပိုဆောင်း ဖြစ်စေမည့် kernel-bypass framework မည်သည့်တစ်ခုကိုမျှ ကျွန်ုပ်တို့ မလိုအပ်ခဲ့ပါ။

အဓိက ဒီဇိုင်းရွေးချယ်မှုများ-

• ပရိုတိုကောကို အဆုံးသတ်ခြင်းမရှိ- ရီလေးသည် STUN headers/ufrag များကိုသာ parse လုပ်သည်; နောက်ဆက်တွဲ DTLS, RTP နှင့် RTCP အတွက် ကက်ရှ်လုပ်ထားသော state ကို အသုံးပြုပြီး packets များကို မမြင်နိုင်အောင် မှုန်ဝါးဝါးလုပ်ပေးသည်။
• ခဏတာ အခြေအနေ- ၎င်းသည် စီးဆင်းမှု အခြေအနေနှင့် စောင့်ကြည့်လေ့လာနိုင်မှုအတွက် ဖောက်သည်လိပ်စာမှ transceiver ဦးတည်ရာသို့ ချိတ်ဆက်သတ်မှတ်ထားသော သေးငယ်ပြီး timeout ကာလတိုရှိသည့် in-memory map တစ်ခုကို ထိန်းသိမ်းထားသည်။
• အလျားလိုက် တိုးချဲ့နိုင်စွမ်း- relay အင်စတန့်စ်များစွာသည် load balancer တစ်ခု၏ နောက်ကွယ်တွင် တစ်ပြိုင်နက်တည်း လည်ပတ်သည်။ အခြေအနေသည် hard WebRTC state မဟုတ်သောကြောင့် ပြန်လည်စတင်မှုများသည် traffic ကျဆင်းမှုကို အနည်းဆုံးသာ ဖြစ်စေပြီး စီးဆင်းမှုကို လျင်မြန်စွာ ပြန်လည်ကောင်းမွန်စေသည်။

ထိရောက်မှု အစီအမံများ-

• SO_REUSEPORT သည် စက်တစ်ခုတည်းပေါ်ရှိ relay worker များစွာကို တူညီသော UDP port ကို bind လုပ်ခွင့်ပြုသည့် Linux socket option တစ်ခုဖြစ်ပါသည်။ ထို့နောက် kernel သည် ဝင်လာသော packet များကို ထို workers များတစ်လျှောက် ဖြန့်ဝေပေးသောကြောင့် read-loop bottleneck တစ်ခုတည်းကို ရှောင်ရှားနိုင်သည်။
• runtime.LockOSThread သည် UDP ဖတ်နေသော goroutine တစ်ခုချင်းစီကို သတ်မှတ်ထားသော OS thread တစ်ခုနှင့် ပုံသေချိတ်တွဲထားသည်။ SO_REUSEPORT နှင့် ပေါင်းစပ်အသုံးပြုပါက၊ ၎င်းသည် တူညီသော flow မှ packets များကို (ရင်းမြစ်နှင့် ဦးတည်ရာ IP:Port အပြင် protocol ပါဝင်သော) တူညီသော CPU core ပေါ်တွင် ထိန်းထားရန် အလားအလာရှိပြီး၊ cache locality ကို တိုးတက်စေကာ context switching ကို လျှော့ချပေးသည်။
• ကြိုတင်ခွဲဝေထားသော buffer များနှင့် ကူးယူမှုကို အနည်းဆုံးထားခြင်းက Go တွင် garbage collection ကို ရှောင်ရှားနိုင်ရန် parsing နှင့် allocation overhead ကို နည်းပါးစေသည်။

ဤအကောင်အထည်ဖော်မှုသည် ကျွန်ုပ်တို့၏ ကမ္ဘာလုံးဆိုင်ရာ အချိန်နှင့်တပြေးညီ မီဒီယာအသွားအလာကို relay footprint အနည်းငယ်ဖြင့် ကိုင်တွယ်ခဲ့သောကြောင့် kernel bypass route ကို အသုံးပြုမည့်အစား ရိုးရှင်းသောဒီဇိုင်းကို ထိန်းသိမ်းထားခဲ့ပါသည်။

ဤဗိသုကာဖွဲ့စည်းပုံသည် UDP port ထောင်ပေါင်းများစွာကို ဖွင့်ပြရန် မလိုဘဲ Kubernetes တွင် WebRTC မီဒီယာကို ကျွန်ုပ်တို့ လည်ပတ်နိုင်စေသည်။ ထိုအချက်သည် အရေးကြီးသည်၊ အကြောင်းမှာ သေးငယ်ပြီး တည်ငြိမ်သတ်မှတ်ထားသော UDP မျက်နှာပြင်သည် လုံခြုံရေးနှင့် load balance ပြုလုပ်ရန် ပိုမိုလွယ်ကူစေပြီး၊ ကြီးမားသော public port range များကို သီးသန့်ကြိုတင်ထားရန် မလိုဘဲ အခြေခံအဆောက်အအုံကို အရွယ်အစားတိုးချဲ့နိုင်စေသည်။ Kubernetes မှ ပိုမိုကောင်းမွန်သော အခြေခံစနစ် ပံ့ပိုးမှုနှင့် တိုက်ခိုက်ခံရနိုင်သည့် မျက်နှာပြင်ဧရိယာ ပိုသေးခြင်းကြောင့် လုံခြုံရေး ပိုမိုမြင့်မားမှုတို့နှင့်အတူ၊ ဤဒီဇိုင်းသည် clients များအတွက် စံ WebRTC အပြုအမူကိုလည်း ထိန်းသိမ်းပေးပြီး၊ SFU (Selective Forwarding Unit) မပါသော ဒီဇိုင်းသည် ကျွန်ုပ်တို့၏ workload အတွက် မှန်ကန်သော မူရင်းရွေးချယ်မှုဖြစ်ခဲ့ကြောင်း အတည်ပြုပါသည်။ ကျွန်ုပ်တို့၏ ဆက်ရှင်အများစုသည် point-to-point ဖြစ်ပြီး latency ကို အထူးဂရုပြုရသည့် အမျိုးအစားဖြစ်ကာ inference services များသည် WebRTC peers များကဲ့သို့ လုပ်ဆောင်ရန် မလိုသည့်အခါ တိုးချဲ့ရန် ပိုမိုလွယ်ကူသည်။

ပိုမိုကျယ်ပြန့်သော သင်ခန်းစာမှာ ရှုပ်ထွေးမှုကို ထည့်သွင်းရန် အကောင်းဆုံးနေရာသည် backend service တိုင်းတွင်မဟုတ်ဘဲ custom client behavior တွင်လည်း မဟုတ်ပါ။ ပါးလွှာသော routing layer တွင်ဖြစ်သည်။ လမ်းကြောင်းချ metadata ကို ပရိုတိုကော၏ ကိုယ်ပိုင် field တစ်ခုအတွင်း encode ပြုလုပ်ခြင်းက ကျွန်ုပ်တို့အား သတ်မှတ်နိုင်သော ပထမ packet လမ်းကြောင်းချခြင်း၊ သေးငယ်သော public UDP ထိတွေ့မျက်နှာပြင်နှင့် ကမ္ဘာတစ်ဝန်းရှိ အသုံးပြုသူများအနီးတွင် ingress ထားရှိနိုင်ရန် လုံလောက်သော လိုက်လျောညီထွေမှုကို ပေးခဲ့သည်။

ရွေးချယ်မှုအချို့မှာ အထူးပင် အရေးပါခဲ့ပါသည်-

• အစွန်းပိုင်းတွင် ပရိုတိုကော၏ အဓိပ္ပာယ်သဘောတရားကို ဆက်လက်ထိန်းသိမ်းပါ။ ဖောက်သည်များသည် စံ WebRTC ဖြင့် ဆက်လက်ဆက်သွယ်နေသောကြောင့် ဘရောက်ဇာနှင့် မိုဘိုင်းတို့အကြား စနစ်အချင်းချင်း ချိတ်ဆက်အသုံးပြုနိုင်မှုကို မပျက်မကွက် ထိန်းသိမ်းထားနိုင်ပါသည်။
• ခက်ခဲသော ဆက်ရှင်အခြေအနေများကို တစ်နေရာတည်းတွင် စုစည်းထားပါ။ Transceiver သည် ICE၊ DTLS၊ SRTP နှင့် ဆက်ရှင် လုပ်ငန်းစဉ်ကို တာဝန်ယူထိန်းချုပ်သည်။ ရီလေးသည် ပက်ကက်များကိုသာ ဆက်လက်ပို့ပေးသည်။
• သတ်မှတ်ခြင်းတွင် ရှိပြီးသား အချက်အလက်များအပေါ် အခြေခံ၍ လမ်းကြောင်းကို သတ်မှတ်သည်။ ICE ufrag သည် hot-path lookup dependency တစ်ခုကို ထပ်မံမထည့်သွင်းဘဲ first-packet routing hook တစ်ခုကို ကျွန်ုပ်တို့ ရရှိစေခဲ့သည်။
• kernel bypass ကို သုံးရန် မစဉ်းစားမီ အများအားဖြင့် ဖြစ်လေ့ရှိသော ကိစ္စရပ်အတွက် အကောင်းဆုံးဖြစ်အောင် ပြုလုပ်ပါ။ SO_REUSEPORT ကို သတိထားအသုံးပြုခြင်း၊ thread pinning နှင့် လျာထားမှု-နည်းသော parsing ပါဝင်သည့် ကျဉ်းမြောင်းသော Go အကောင်အထည်ဖော်မှုတစ်ခုသည် ကျွန်ုပ်တို့၏ workload အတွက် လုံလောက်ခဲ့သည်။

အခြေခံအဆောက်အအုံက နှောင့်နှေးမှုကို မမြင်ရအောင် ပြုလုပ်ထားမှသာ အချိန်နှင့်တပြေးညီ အသံ AI က အလုပ်လုပ်ပါသည်။ ကျွန်ုပ်တို့အတွက်၊ ၎င်းဆိုလိုသည်မှာ ဖောက်သည်များက WebRTC ကိုယ်တိုင်ထံမှ မျှော်လင့်ထားသည့်အရာကို မပြောင်းလဲစေဘဲ ကျွန်ုပ်တို့၏ WebRTC ဖြန့်ကျက်မှု ပုံစံကို ပြောင်းလဲရန် ဖြစ်ခဲ့သည်။