Indy-യുടെ പൂജ്യം UDP ASSOCIATE വിലാസം ഡാറ്റാഗ്രാമിന്റെ ലക്ഷ്യമല്ല

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 പിന്തുണയുണ്ടെന്ന് ഉറപ്പ് നൽകുന്നില്ല.