အဓိကအစိတ်အပိုင်း သုံးခု၊ ရည်ရွယ်ချက်တစ်ခု
Timmy ကို လက်တွေ့ကျကျ ဒီလိုတည်ဆောက်ထားပါတယ်— Flutter အက်ပ်အတွက်၊ WebRTC အချိန်နှင့်တစ်ပြေးညီ အသံနှင့်ဗီဒီယိုအတွက်၊ နှင့် Firebase ချိတ်ဆက်ညှိနှိုင်းရန်အတွက် ဖြစ်ပါတယ်။ အရာအားလုံးကို cloud ကတစ်ဆင့်ပို့တဲ့ ပလက်ဖောင်းကြီးတစ်ခု မတည်ဆောက်ချင်ခဲ့ပါဘူး။ အစိတ်အပိုင်းတစ်ခုစီက အချက်အလက်အနည်းဆုံးသာ သိပြီး တခြားအစိတ်အပိုင်းများနဲ့ ယုံကြည်စိတ်ချစွာ အလုပ်လုပ်နိုင်ရပါမယ်။
WebRTC: တိုက်ရိုက်ချိတ်ဆက်မှု၊ ပုံသေအားဖြင့် ကုဒ်ဝှက်ထားခြင်း
WebRTC (Web Real-Time Communication) က ကလေးစက်နှင့် မိဘစက်ကြား အသံနှင့်ဗီဒီယိုကို ပို့ဆောင်ပေးပါတယ်။ အကောင်းဆုံးအခြေအနေမှာ ဒေတာက စက်နှစ်လုံးကြား တိုက်ရိုက်၊ peer-to-peer နည်းဖြင့် ကြားခံ media server မပါဘဲ စီးဆင်းပါတယ်။
WebRTC ချိတ်ဆက်မှုတိုင်းမှာ DTLS-SRTP ကို ပုံသေအားဖြင့် သုံးပါတယ်။ တစ်စုံတစ်ယောက်က ကွန်ရက် packet များကို ဖမ်းယူခဲ့ရင်လည်း ဖတ်လို့ရတဲ့ အသံ သို့မဟုတ် ဗီဒီယိုကို မရနိုင်ပါဘူး။ ဒီကုဒ်ဝှက်မှုက protocol ရဲ့ အစိတ်အပိုင်းဖြစ်ပြီး WebRTC မှာ လွယ်လွယ်နဲ့ ပိတ်လို့မရပါဘူး။
ဒါက ကျွန်ုပ်အတွက် အရေးကြီးတဲ့အချက်ပါ—ကလေးခန်းက မီဒီယာဟာ ကျွန်ုပ်၏ဆာဗာပေါ်မှာ မရှိသင့်ပါဘူး။ သင့်စက်နှစ်လုံးကြားမှာပဲ ရှိနေပါတယ်။
Firebase Firestore မှတစ်ဆင့် Signaling
WebRTC မစတင်မီ စက်နှစ်လုံးက တစ်ခုကိုတစ်ခု ရှာတွေ့ပြီး ဘယ်လိုချိတ်ဆက်မလဲဆိုတာ ညှိနှိုင်းရပါတယ်။ ဒီအပိုင်းကို signaling လို့ခေါ်ပါတယ်။ Timmy က ဒီအတွက် Google ၏ cloud database ဖြစ်တဲ့ Firebase Firestore ကို သုံးပါတယ်။
နည်းပညာဆိုင်ရာ ချိတ်ဆက်ဒေတာသာ ဖလှယ်ပါတယ်—
- SDP offers နှင့် answers: စက်များ၏ လုပ်ဆောင်နိုင်စွမ်းများကို ဖော်ပြပေးသည် (ထောက်ပံ့သော codecs၊ resolution များ စသည်)။
- ICE candidates: စက်နှစ်လုံး အချင်းချင်း ဆက်သွယ်ရောက်ရှိနိုင်သည့် ဖြစ်နိုင်ခြေရှိသော ကွန်ရက်လမ်းကြောင်းများ။
အသံနဲ့ဗီဒီယိုက Firebase ထဲကို မရောက်ပါဘူး။ Firestore က နည်းပညာဆိုင်ရာ ချိတ်ဆက်ဒေတာကိုသာ ပို့ဆောင်ပေးပါတယ်။ Timmy က ဒီ signaling layer ကိုလည်း ကုဒ်ဝှက်ထားတာကြောင့် Firestore ဟာ SDP နဲ့ ICE အတွက် စာသားအတိုင်း ဖတ်လို့ရတဲ့ တွေ့ဆုံရာနေရာ မဖြစ်ပါဘူး။
TURN ဆာဗာများ: တိုက်ရိုက်လမ်းကြောင်း အလုပ်မလုပ်သည့်အခါ
တချို့ကွန်ရက်တွေ—ဥပမာ စည်းကျပ်တဲ့ firewall တွေ သို့မဟုတ် မိုဘိုင်းဝန်ဆောင်မှုပေးသူအချို့—က တိုက်ရိုက်ချိတ်ဆက်မှုကို ပိတ်ထားပါတယ်။ အဲဒီအခါ WebRTC မှာ TURN relay (Traversal Using Relays around NAT) လိုအပ်ပါတယ်။
Timmy က local TURN server ကို အရင်စမ်းပြီး local relay မရနိုင်တာ သို့မဟုတ် ဝန်လွန်နေရင် Cloudflare ကို အရန်အဖြစ် သုံးပါတယ်။ Relay က ကုဒ်ဝှက်ထားတဲ့ packet တွေကိုသာ ဆက်ပို့ပေးပါတယ်။ အသံ သို့မဟုတ် ဗီဒီယိုအတွက် key တွေ မရပါဘူး။ WebRTC ကုဒ်ဝှက်မှုက မပြောင်းလဲဘဲ ရှိနေပါတယ်။
TURN အသုံးပြုခွင့်အထောက်အထားများကို Firebase Cloud Function က ထုတ်ပေးပြီး 24 နာရီသာ သက်တမ်းရှိပါတယ်။ ကလေးစောင့်ကြည့်အက်ပ်ထဲမှာ အမြဲတမ်းသုံးနိုင်တဲ့ အသုံးပြုခွင့်အထောက်အထားတွေ ထည့်ထားတာက ကျွန်ုပ်အတွက် အန္တရာယ်များလွန်းပါတယ်။
အနီးအနား ချိတ်ဆက်မှုများ: စက်များက အချင်းချင်း အလိုအလျောက် ရှာတွေ့ခြင်း
ကလေးစက်နဲ့ မိဘစက်ကို ချိတ်ဆက်ရာမှာ အဆင့်များမရှုပ်စေရန် Timmy က Nearby Connections ကို သုံးပါတယ်။ Google က ဒီရှာဖွေမှုအလွှာကို Bluetooth နဲ့ WiFi မှတစ်ဆင့် ပံ့ပိုးပေးပါတယ်။
Timmy ရှိ အလိုအလျောက် ချိတ်ဆက်ခြင်း က ကိုယ်တိုင် code ရိုက်ထည့်စရာမလိုဘဲ အလုပ်လုပ်ပါတယ်—စက်တွေက တစ်ခုကိုတစ်ခု ရှာတွေ့ပြီး key ဖလှယ်ရန် တူညီတဲ့ တွေ့ဆုံရာကို ရှာတွေ့ပါတယ်။ အဆင်မပြေရင် ရိုက်ထည့်လို့ရတဲ့ စာလုံး 4 လုံးပါ code ရှိပါတယ်။ ချိတ်ဆက် code က စက်ထဲကနေ ဘယ်တော့မှ မထွက်ပါဘူး; Firestore က document identifier အဖြစ် cryptographic hash (SHA-256) ကိုသာ မြင်ရပါတယ်။
အမည်မဖော် အထောက်အထားစိစစ်ခြင်း
Timmy က Firebase Anonymous Authentication ကို သုံးပါတယ်။ ပထမဆုံးဖွင့်တဲ့အခါ စက်တစ်လုံးစီက ယာယီ၊ အမည်မဖော် ID တစ်ခု ရပါတယ်။ အကောင့်၊ အီးမေးလ်လိပ်စာ၊ စကားဝှက် မလိုပါဘူး။ ဒီ ID က Firestore စည်းမျဉ်းတွေကို လိုက်နာစေဖို့သာ ဖြစ်ပြီး အတည်ပြုပြီးသားစက်တွေကသာ session data ကို ဖတ် သို့မဟုတ် ရေးနိုင်ပါတယ်။
ဖွဲ့စည်းပုံ: ဘယ်သူပို့၊ ဘယ်သူလက်ခံ
Timmy မှာ mode နှစ်မျိုးရှိပါတယ်—
- ကလေး Mode (ပို့သူ): ဒီစက်က microphone နဲ့ အသံဖမ်းပြီး WebRTC ကတစ်ဆင့် မိဘစက်ဆီ ပို့ပါတယ်။ လိုအပ်ရင် ကင်မရာကို ဖွင့်နိုင်ပြီး ဗီဒီယိုကိုလည်း တိုက်ရိုက်ပို့ပေးပါတယ်။
- မိဘ Mode (လက်ခံသူ): ဒီစက်က အသံနဲ့ဗီဒီယိုကို လက်ခံပြီး ကင်မရာ stream ကို ပြသကာ ကလေးစက်သို့ အသံတိုတို မက်ဆေ့ခ်ျပို့ရန် push-to-talk ကိုလည်း ပေးထားပါတယ်။
push-to-talk နဲ့ ကင်မရာဖွင့်/ပိတ်လို ထိန်းချုပ်မှုတွေက DataChannel ကို သုံးပါတယ်။ ဒါက စက်နှစ်လုံးကြား ကုဒ်ဝှက်ထားတဲ့ မက်ဆေ့ခ်ျတိုလေးတွေကို တိုက်ရိုက်ပို့တဲ့ နောက်ထပ် WebRTC channel တစ်ခုပါ။
ဘာကြောင့် Flutter လဲ?
Flutter က platform မျိုးစုံအတွက် အက်ပ်တည်ဆောက်ရာမှာ သုံးတဲ့ Google ၏ framework ပါ။ Timmy အတွက်ဆိုရင် logic အများစုကို တစ်ကြိမ်ရေးပြီး Android နဲ့ iOS နှစ်ခုစလုံးမှာ သုံးနိုင်ပါတယ်။ Timmy ကို Android မှာ ရရှိနိုင်ပြီး iOS version လည်း မကြာခင် ဖြန့်ချိတော့မှာပါ။ Code ထပ်ရေးရတာ နည်းလေ၊ bug ဝင်နိုင်တဲ့နေရာလည်း နည်းလေပါပဲ။
အနှစ်ချုပ်
နည်းပညာဆိုင်ရာ စည်းမျဉ်းက ရိုးရှင်းပါတယ်—Timmy က တကယ်လိုအပ်တဲ့ ဒေတာကိုသာ ကိုင်တွယ်သင့်ပါတယ်။ WebRTC က media ကို ကာကွယ်ပေးတယ်၊ Firebase က ချိတ်ဆက်မှုစတင်ခြင်းကို ညှိနှိုင်းပေးတယ်၊ TURN က ကုဒ်ဝှက်ထားတဲ့ packet တွေကိုသာ မြင်တယ်၊ Nearby Connections က ချိတ်ဆက်ရာက အခက်အခဲကို လျှော့ပေးတယ်။
ကောင်းတဲ့နည်းပညာက နေ့စဉ်ဘဝထဲမှာ သိပ်မထင်ရှားဘဲ အလုပ်လုပ်ပေးပါတယ်။ ကလေးခန်းကို cloud project တစ်ခုလို မဖြစ်စေဘဲ အဆင်ပြေစေပါတယ်။