SOCKS relay တွင် full-duplex စီးဆင်းမှုနှင့် backpressure

SOCKS handshake အောင်မြင်ခဲ့သည်။ ယခု relay သည် client ထံမှ ဖတ်ပြီး ဦးတည်ရာသို့ ရေးကာ တုံ့ပြန်မှု အပြည့်အစုံကို စောင့်ပြီးမှသာ client ထံမှ ထပ်ဖတ်သည်။ ထိုအစီအစဉ်သည် လုံးဝမှန်ကန်သော application တစ်ခုကို deadlock ဖြစ်စေနိုင်သည်။

TCP tunnel တည်ဆောက်ပြီးသည်နှင့် SOCKS သည် ၎င်းအတွင်းရှိ message များကို မသတ်မှတ်ပါ။ ဦးတည်ရာက ဦးစွာ ပို့နိုင်သည်။ နှစ်ဖက်စလုံး သီးခြားစီ ပို့နိုင်သည်။ တစ်ဖက်က record တိုတိုကို ပို့ပြီး အခြားတစ်ဖက်၏ အဖြေကို စောင့်နိုင်သည်။

ခန့်မှန်းထားသော အရောင်းအဝယ်များမဟုတ်ဘဲ byte များကို ပို့ပါ

လက်ခံမှု ခေါ်ဆိုမှုသည် ၎င်း၏ flag များနှင့် socket အခြေအနေအရ ရနိုင်သော byte များကို ပြန်ပေးသည်။ ၎င်းသည် ယေဘုယျ relay အား application တုံ့ပြန်မှု ပြီးဆုံးပြီ ဟု မပြောပါ။ မည်သည့် အရွယ်အစားမဆို ကြီးမားသော buffer ပြည့်သည်အထိ စောင့်ခြင်းသည် လုပ်ဖော်ကိုင်ဖက် ဆက်လုပ်ရန် လိုအပ်သော message ငယ်ကို ပို့ခြင်းကို တားဆီးနိုင်သည်။

နှစ်ဖက်စလုံးကို ဝန်ဆောင်ရန် application ၏ ရှိပြီးသား concurrency ပုံစံကို အသုံးပြုပါ- event loop၊ asynchronous I/O သို့မဟုတ် ရည်ရွယ်ချက်ရှိရှိ ရွေးချယ်ထားသော အခြား ဒီဇိုင်း။ အရေးကြီးသော အပြုအမူမှာ တစ်ဖက်သို့ တိုးတက်မှုသည် အခြားတစ်ဖက်တွင် ဖန်တီးထားသော message နယ်နိမိတ် မလိုအပ်ခြင်း ဖြစ်သည်။

ကန့်သတ်ထားသော စောင့်ဆိုင်းနေသည့် buffer နှစ်ခုကို ထားပါ

client ထံမှ ဖတ်ထားသော data သည် ဦးတည်ရာသို့ မရောက်သေးဘဲ စောင့်ဆိုင်းနေနိုင်ပြီး ဦးတည်ရာမှ data သည် client ထံသို့ ရောက်ရန် စောင့်ဆိုင်းနေသည်။ ထို စောင့်ဆိုင်းနေသော byte များကို သီးခြား ခြေရာခံပါ။

ပို့ခြင်းသည် တောင်းဆိုသည်ထက် byte နည်းနည်း ရေးနိုင်သည်။ မရေးရသေးသော အပိုင်းကို ထိန်းထားပါ။ မပစ်ပါနှင့်၊ buffer တစ်ခုလုံးကို ပြန်မဖွင့်ပါနှင့်။ ခေတ္တ ရေး၍မရသော socket သည် မှန်ကန်သော readiness event ကို စောင့်ရန် အကြောင်းရင်းဖြစ်ပြီး အဆက်မပြတ် လှည့်ပတ်ရန် မဟုတ်ပါ။

buffer များကို ကန့်သတ်ပါ။ ဦးတည်ရာ နှေးပါက client data ကို အကန့်အသတ်မရှိ ဆက်ဖတ်နေခြင်းသည် တန်းစီမှုကို relay ၏ memory ထဲသို့ ရွှေ့လိုက်ရုံသာ ဖြစ်သည်။ backpressure ဆိုသည်မှာ သက်ဆိုင်ရာ စောင့်ဆိုင်းနေသော buffer ပြည့်သောအခါ ဖတ်ခြင်းကို ရပ်ဆိုင်းပြီး ရေးခြင်းက နေရာလွတ်ပေးသောအခါ ပြန်စတင်ခြင်း ဖြစ်သည်။

တစ်ဖက်သတ် အဆုံးသတ်မှုအတွက် မူဝါဒ တစ်ခု လိုအပ်သည်

အခြားတစ်ဖက်တွင် အသုံးဝင်သော data ရှိနေစဉ် TCP သည် ပို့သည့် ဦးတည်ချက်ကို ပိတ်နိုင်သည်။ buffer လုပ်ထားသော byte များ ကုန်ဆုံးပြီးနောက် ထို အခြေအနေကို မည်သို့ ဖြန့်ဝေမည်ကို ဆုံးဖြတ်ပြီး စနစ်တကျ ပိတ်ခြင်းကို error သို့မဟုတ် သတ်မှတ်ချိန်နှင့် ခွဲခြားပါ။

ဤအရာများထဲမှ တစ်ခုမျှ relay အား application ၏ payload ကို decrypt သို့မဟုတ် parse လုပ်ရန် မလိုအပ်ပါ။ မှန်ကန်သော stream ကိုင်တွယ်မှု လိုအပ်သည်။ buffer အရွယ်အစား တိုးခြင်းတစ်ခုတည်းဖြင့် မှားယွင်းသော ဘက်ကို စောင့်နေသော သို့မဟုတ် ဖတ်မှုတိုင်းကို တောင်းဆိုမှု တစ်ခုလုံးနှင့် ကိုက်ညီသည်ဟု ယူဆသော relay ကို ပြုပြင်၍ မရပါ။