Java DatagramSocket en SOCKS5 UDP-herleiding
Verstaan waarom 'n Java UDP-socket 'n SOCKS5 UDP-implementering nodig het, selfs wanneer TCP-verbindings reeds SOCKS gebruik.
Jou Java HTTP-versoek werk deur SOCKS, maar 'n UDP-funksie stuur steeds verkeer direk of misluk. Om die JVM se SOCKS-eienskappe te stel gee nie aan DatagramSocket 'n SOCKS5 UDP-implementering nie.
Die DatagramSocket-API stuur en ontvang datagramme wat aan netwerk-eindpunte geadresseer is. Sy connect()-metode kies 'n eweknie vir daardie socket. Dit voer nie 'n SOCKS-onderhandeling met die eweknie uit nie.
'n SOCKS5 UDP-roete verg ekstra werk
SOCKS5 definieer 'n UDP-assosiasie wat oor 'n TCP-beheerverbinding geskep word. Die kliënt ruil dan ingekapselde datagramme met die herleidingsadres uit wat die instaanbediener verskaf. Elke ingekapselde boodskap identifiseer sy bestemming. 'n Kliëntimplementering moet daardie raamwerk en die leeftyd van die beheerverbinding hanteer.
Om 'n gewone UDP-socket na die instaanbediener se TCP-luisterpoort te rig, slaan daardie stappe oor. Om jou toepassing se rou datagramme na daardie adres te stuur, is nie 'n plaasvervanger vir die assosiasie nie.
Kies 'n biblioteek of toepassingsfunksie wat SOCKS5 UDP-herleiding uitdruklik ondersteun, en bevestig dat die bediener dit ook ondersteun. 'n Biblioteek wat SOCKS-ondersteuning adverteer, mag slegs TCP CONNECT implementeer. Die protokolspesifikasie onderskei die opdragte.
Die UDP-herleiding het ook 'n bruikbare pad nodig
'n Suksesvolle TCP-verbinding na die instaanbediener vestig slegs die beheerpad. Vuurmure of NAT-gedrag kan steeds inmeng met datagramme wat na die herleiding gestuur word. Versamel die teruggekeerde herleidings-eindpunt en enige herleidingsfout voordat jy aflei dat die toepassingsbestemming vanlyn is.
Laastens, SOCKS-vervoerondersteuning voeg nie leweringswaarborge by UDP nie. Jou toepassing se eie tydverstrykings, verlieshantering en beperkings op boodskapgrootte geld steeds nadat die roete verander het.