በ Indy UDP ASSOCIATE ጥያቄ ውስጥ 0.0.0.0:0 ሆን ተብሎ ሊሆን ይችላል። ያ ጥያቄ የሚጠበቀውን የደንበኛ በኩል UDP መጨረሻ ነጥብ ይገልጻል፣ RFC 1928 ደግሞ በማይታወቅ ጊዜ ዜሮዎችን ይፈቅዳል። የመጨረሻውን አገልግሎት አይመርጥም።

የመልሱ BND.ADDR/BND.PORT ደንበኛው የተጠቀለሉ ዳታግራሞችን የሚልክበትን ሪሌይ ይለያል።

TCP control: client → SOCKS5 proxy → UDP association reply
UDP payload: client → returned relay address → target service

በ Indy TIdUDPClient.Connect የግልጽ ፕሮክሲውን OpenUDP ይጠራል። TIdSocksInfo የዜሮ ማህበር መስኮችን ያቀርባል። በኋላ SendBuffer የሚፈለገውን አገልግሎት ለ SendToUDP ያስተላልፋል፣ እሱም የ SOCKS UDP መድረሻ አርዕስትን ከመተግበሪያ ጭነት በፊት ይገነባል።

ማህበሩ ከተሳካ ግን ትራፊክ ካልተሳካ፣ የተመለሰውን ሪሌይ፣ የተቀመጠውን መድረሻ እና የ UDP መልስ መንገድ ይመርምሩ። NAT/ፋየርዎል የ TCP ልውውጥን ፈቅዶ UDP ሊዘጋ ይችላል።

የ TCP ቁጥጥር ግንኙነቱን ክፍት ያድርጉ፤ መዝጋቱ ማህበሩን ያበቃል። SOCKS4/4a ይህ ክወና የለባቸውም፣ የ SOCKS5 ስም ብቻ ሰርቨር UDP ይደግፋል ብሎ አያረጋግጥም።

ተዛማጅ ጽሑፎች