د SOCKS پراکسي پیغامونه لوډولی شي خو په تلیفوني اړیکو کې ناکامېږي
د Dante لارښود او د SOCKS5 د UDP غوښتنو په کارولو سره تشریح کوي چې ولې یو فعال TCP لار د یوې اپلیکیشن د اړیکو ټرافیک ملاتړ نه ثبوتوي.
متني پیغامونه د SOCKS پراکسي له لارې رارسېږي، خو غږیزه اړیکه هېڅکله نه نښلېږي. دا اړینه نه ده چې پراکسي په بشپړ ډول خراب وي. کېدای شي اپلیکیشن د اړیکو لپاره بله لېږد وکاروي.
بریالۍ TCP غوښتنه د هغې عملیې لپاره د TCP لار ثبوتوي. SOCKS5 هم د UDP تړاو تعریفوي، خو کلاینټ، د SOCKS خدمت، د شبکې قواعد او د اپلیکیشن تنظیمات باید ټولې هغه UDP لار ملاتړ وکړي.
له TCP اورېدونکي څخه ډېر څه شته
د Dante لارښود د پروتوکول او امر قواعد جلا کوي، په شمول connect, udpassociate او udpreply. هغه قاعده چې یوازې هغه TCP اړیکه اجازه ورکوي چې تاسو دمخه ازمویلې، اړینې UDP اجازې نه رامنځته کوي.
د UDP تړاو د لېږد پای ټکی او بیرته راتلونکی ټرافیک هم شاملوي. اور وژونکي او د پتې ژباړه باید هغه ریښتینې لار اجازه ورکړي. د SOCKS د TCP اورېدونکي پرانیستل د هغې د UDP لېږدوونکي د لاسرسي وړ کولو سره برابر نه دي.
د اپلیکیشن اوسني پراکسي اسناد او تنظیمات وګورئ. بېلابېلې نسخې کېدای شي پیغامونه، رسنۍ او اړیکې په بېلابېلو لارو اداره کړي. د زاړه کلاینټ لپاره د فورم یو ترکیب باید د دې ثبوت په توګه وړاندې نه شي چې هر اوسنی کلاینټ اړیکې د SOCKS له لارې لېږي.
د لومړني تشخیص په توګه د هر UDP پورټ پرانیستل ترسره مه کوئ. د لېږد چلند او د کلاینټانو پلان شوې حوزه وټاکئ، بیا یې مناسبه محدوده شبکه پالیسي پلي کړئ. همدارنګه، د اړیکو لپاره د پراکسي تنظیم غیر فعالول کېدای شي اړیکه په مستقیم لېږلو سره کار وکړي، چې بهرنۍ لار بدلوي نه دا چې د پراکسي شوې لار ترمیم کړي.
د هرې عملیې لپاره بریا ثبت کړئ: پیغامونه، د رسنیو لېږد او اړیکې. یوه فعاله غوښتنه یا بدله شوې براوزر IP نشي ثبوتولی چې د بل اپلیکیشن هر برخه ورته د پراکسي وتل شریکوي.