Java DatagramSocket og SOCKS5 UDP-vidaresending
Forstå kvifor ein Java UDP-socket treng ein SOCKS5 UDP-implementasjon sjølv når TCP-tilkoplingar allereie brukar SOCKS.
Java HTTP-førespurnaden din fungerer gjennom SOCKS, men ein UDP-funksjon sender framleis trafikk direkte eller feilar. Å setje SOCKS-eigenskapane til JVM-en gir ikkje DatagramSocket ein SOCKS5 UDP-implementasjon.
DatagramSocket-API-et sender og tek imot datagram adresserte til nettverksendepunkt. Metoden connect() vel ein part for den sockelen. Han gjer inga SOCKS-forhandling med parten.
Ein SOCKS5 UDP-rute krev ekstra arbeid
SOCKS5 definerer ein UDP-assosiasjon som blir etablert over ei TCP-kontrolltilkopling. Deretter bytjar klienten innkapsla datagram med vidaresendingsadressa som proxyen oppgir. Kvar innkapsla melding identifiserer målet sitt. Ein klientimplementasjon må handtere denne innramminga og levetida til kontrolltilkoplinga.
Å peike ein vanleg UDP-socket mot TCP-lytteporten til proxyen hoppar over desse trinna. Å sende rå datagram frå applikasjonen din til den adressa er ikkje ei erstatning for assosiasjonen.
Vel eit bibliotek eller ein applikasjonsfunksjon som uttrykkeleg støttar SOCKS5 UDP-vidaresending, og stadfest at tenaren òg støttar det. Eit bibliotek som annonserer SOCKS-støtte implementerer kanskje berre TCP CONNECT. Protokollspesifikasjonen skil mellom kommandoane.
UDP-vidaresendinga treng òg ein brukbar veg
Ei vellukka TCP-tilkopling til proxyen etablerer berre kontrollvegen. Brannmurar eller NAT-åtferd kan framleis forstyrre datagram sende til vidaresendinga. Samle inn vidaresendingsendepunktet som blir returnert og eventuelle vidaresendingsfeil før du konkluderer med at målet til applikasjonen er fråkopla.
Til slutt legg SOCKS-transportstøtte ikkje til leveringsgarantiar for UDP. Dei eigne tidsavbrota til applikasjonen din, tapshandtering og grenser for meldingsstorleik gjeld framleis etter at ruta er endra.