អាសយដ្ឋានសូន្យ UDP ASSOCIATE របស់ Indy មិនមែនជាគោលដៅ datagram ទេ

បែងចែកអាសយដ្ឋានសមាគមអតិថិជន រីឡេ SOCKS ដែលត្រឡប់មកវិញ និងគោលដៅដែលបានអ៊ិនកូដក្នុងពេល UDP នីមួយៗ។

0.0.0.0:0 ក្នុងសំណើ Indy UDP ASSOCIATE អាចជាចេតនា។ សំណើនោះពិពណ៌នាចំណុចបញ្ចប់ UDP ដែលរំពឹងទុកនៅខាងអតិថិជន ហើយ RFC 1928 អនុញ្ញាតលេខសូន្យ នៅពេលវាមិនស្គាល់។ វាមិនជ្រើសរើសសេវាចុងក្រោយទេ។

BND.ADDR/BND.PORT នៃការឆ្លើយតបបង្ហាញរីឡេ ដែលអតិថិជនផ្ញើ datagram ដែលបានរុំទៅ។

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 ទេ។

អត្ថបទពាក់ព័ន្ធ