HTTP နှင့် Real-Time
HTTP ရဲ့ ပြဿနာကို ကျော်လွှားဖို့ ကြိုးစားခြင်း
Section titled “HTTP ရဲ့ ပြဿနာကို ကျော်လွှားဖို့ ကြိုးစားခြင်း”WebSocket မပေါ်ခင်တုန်းက Developer တွေဟာ Website တွေကို Real-time လိုမျိုး ချက်ချင်းအပြောင်းအလဲ ပြသနိုင်အောင် HTTP ရဲ့ ကိုယ်က တောင်းဆိုမှ Server က ပြန်ပို့ပေးတဲ့ စနစ် (Request/Response) ကိုပဲ အသုံးပြုပြီး နည်းလမ်းအမျိုးမျိုးနဲ့ ကြိုးစားခဲ့ကြပါတယ်။ ဒါပေမယ့် ဒီနည်းလမ်းတွေဟာ အကောင်းဆုံးနဲ့ အထိရောက်ဆုံး ဖြေရှင်းနည်းတွေတော့ မဟုတ်ခဲ့ပါဘူး။ Server ကနေ Client ဆီကို အချက်အလက်အသစ်ရတာနဲ့ ချက်ချင်းပို့ပေးဖို့ အားနည်းနေတဲ့ HTTP ရဲ့ ပြဿနာကို ကျော်လွှားဖို့ ကြိုးစားခဲ့တဲ့ နည်းလမ်းတွေပါ။ ဘယ်လို နည်းလမ်းတွေလဲဆိုတော့…
Polling (အချိန်မှန် လိုက်မေးခြင်း)
Section titled “Polling (အချိန်မှန် လိုက်မေးခြင်း)”ဒီနည်းလမ်းမှာ Client ဘက် (ကိုယ့် Browser) ကနေ Server ဆီကို အချိန်မှန်မှန်လေးတွေ သတ်မှတ်ပြီး (ဥပမာ - ၅ စက္ကန့် ဒါမှမဟုတ် ၁၀ စက္ကန့် တစ်ကြိမ်) ‘အချက်အလက်အသစ် ဘာများ ရှိလဲ’ လို့ HTTP Request တွေ ပို့ပြီး ဆက်တိုက် လိုက်မေးနေတာပါ။ (ဒါဟာ ကိုယ်က သူငယ်ချင်းတစ်ယောက်ဆီကို ‘သတင်းထူး ဘာရှိလဲ’ လို့ အချိန်တိုင်း ဖုန်းခေါ်ပြီး လိုက်မေးနေတာနဲ့ တူပါတယ်)
Polling ၏ အားနည်းချက်များ
Section titled “Polling ၏ အားနည်းချက်များ”အချက်အလက်အသစ် ဘာမှ မရှိရင်တောင် Client က Request တွေ ဆက်တိုက် ပို့နေရတဲ့အတွက် မလိုအပ်တဲ့ အင်တာနက် အသွားအလာ (Network Traffic) တွေ အရမ်းများစေတယ်၊ Server ကိုလည်း မလိုအပ်ဘဲ အလုပ်တွေ ပိုစေတယ် (Server Load များတယ်)။ နောက်ပြီး အချက်အလက်အသစ် ရောက်တာနဲ့ ချက်ချင်း မသိရဘဲ ကိုယ့်ဘက်က နောက်တစ်ကြိမ် လိုက်မေးတဲ့ အချိန်ကျမှ သိရတတ်တဲ့အတွက် အချက်အလက် ရောက်ရှိမှု နှောင့်နှေးတာ (Latency) မြင့်မားပါတယ်။
Long Polling (စောင့်ပြီးမှ ဖြေခြင်း / Comet)
Section titled “Long Polling (စောင့်ပြီးမှ ဖြေခြင်း / Comet)”ဒီနည်းလမ်းက Polling ထက်တော့ နည်းနည်း ပိုကောင်းပါတယ်။ Client က Server ဆီကို Update အသစ်အတွက် Request ပို့လိုက်ပြီး Server က အဲဒီ Update အသစ်တစ်ခုခု တကယ်ရလာတဲ့အထိ ဒါမှမဟုတ် ကြိုသတ်မှတ်ထားတဲ့ အချိန်တစ်ခု ကုန်တဲ့အထိ Connection ကို မပိတ်ဘဲ ဖွင့်ထားပေးပါတယ်။ Update ရတာနဲ့ အဲဒီ ဖွင့်ထားတဲ့ ချိတ်ဆက်မှုကနေ Response ပြန်ပို့ပြီးမှ Connection ကို ပိတ်လိုက်ပါတယ်။ Client ကလည်း Response ရတာနဲ့ နောက်ထပ် Update အသစ်ကို ထပ်စောင့်ဖို့ Connection အသစ်တစ်ခုကို ချက်ချင်း ပြန်ဖွင့်ပြီး ထပ်စောင့်ပါတယ်။ (သူငယ်ချင်းဆီ ဖုန်းခေါ်ပြီး ‘သတင်းထူးရရင် ဖုန်းမချဘဲ ကိုင်ထားနော်၊ ရတာနဲ့ ပြောပြီး လိုင်းချလိုက်၊ ငါလည်း မင်းပြောတာပြီးတာနဲ့ ချက်ချင်း ပြန်ခေါ်ပြီး နောက်ထပ် သတင်းထူးကို ထပ်စောင့်နေမယ်’ လို့ ပြောထားတာနဲ့ တူပါတယ်)
Long Polling ၏ အားနည်းချက်များ
Section titled “Long Polling ၏ အားနည်းချက်များ”Polling လိုမျိုး အမြဲတမ်း လိုက်မေးနေစရာ မလိုတော့ပေမယ့် Connection အသစ်တွေ ခဏခဏ ထူထောင်လိုက်၊ ဖြတ်တောက်လိုက် လုပ်နေရတဲ့အတွက် အလုပ်ရှုပ်ပြီး မလိုအပ်တဲ့ အားထုတ်မှုတွေ (Connection ထူထောင်ခြင်းနှင့် ဖြတ်တောက်ခြင်း Overhead) ရှိနေတုန်းပါပဲ။ Server ဘက်မှာလည်း Connection အများကြီးကို တစ်ပြိုင်နက် ဖွင့်ထားပြီး ကိုင်တွယ်ရတာ ပိုမို ရှုပ်ထွေးနိုင်ပါတယ်။ အရေးအကြီးဆုံးကတော့ ဒါဟာ တကယ်ကြီး နှစ်ဖက်ပြိုင်တူ စိတ်ကြိုက် ပြောဆိုလို့ရတဲ့ Communication (bi-directional) မဟုတ်သေးပါဘူး။ Server က Update အသစ်ရရင်တောင် Client က စောင့်နေတဲ့ Request (စောင့်နေဖို့ တောင်းဆိုထားတာ) ကို တုံ့ပြန်တဲ့အနေနဲ့ပဲ ပို့လို့ရတာဖြစ်ပါတယ်။ Server ကနေ Client ဆီကို တောင်းဆိုမှု မရှိဘဲ စပြီး အချက်အလက် တွန်းပို့ (Push) လုပ်တာမျိုး မဟုတ်သေးပါဘူး။
ပိုကောင်းသော နည်းလမ်း
Section titled “ပိုကောင်းသော နည်းလမ်း”ဒီနည်းလမ်းတွေဟာ HTTP ရဲ့ မူလ ပုံစံအရ Server ကနေ Client ဆီကို အချက်အလက်အသစ် ချက်ချင်း တွန်းပို့လို့ မရတဲ့ အားနည်းချက်ကို ကျော်လွှားဖို့ ကြိုးစားခဲ့တဲ့ နည်းလမ်းတွေပါ။ ဒီနည်းလမ်းတွေရဲ့ အားနည်းချက်တွေကြောင့် Server ကနေ Client ဆီကို Client က တောင်းဆိုမှုမရှိဘဲ အချက်အလက်အသစ် ရတာနဲ့ ချက်ချင်း ပို့နိုင်တဲ့ ပိုကောင်းတဲ့၊ ပိုမိုထိရောက်တဲ့ နည်းလမ်းတစ်ခု Real-time Application တွေအတွက် မဖြစ်မနေ လိုအပ်နေပြီဆိုတာ ပိုပြီး ပေါ်လွင်လာပါတယ်။ အဲဒီလိုအပ်ချက်ကို ဖြည့်ဆည်းပေးဖို့ WebSocket ပေါ်ပေါက်လာတာ ဖြစ်ပါတယ်။