Java DatagramSocket kaj SOCKS5 UDP-plusendado
Komprenu kial Java UDP-ingo bezonas SOCKS5 UDP-realigon eĉ kiam TCP-konektoj jam uzas SOCKS.
Via Java HTTP-peto funkcias tra SOCKS, sed UDP-funkcio ankoraŭ sendas trafikon rekte aŭ malsukcesas. Agordi la SOCKS-ecojn de la JVM ne donas al DatagramSocket SOCKS5 UDP-realigon.
La DatagramSocket-API sendas kaj ricevas datagramojn adresitajn al retaj finpunktoj. Ĝia metodo connect() elektas kunulon por tiu ingo. Ĝi ne faras SOCKS-intertraktadon kun la kunulo.
SOCKS5 UDP-vojo postulas plian laboron
SOCKS5 difinas UDP-asocion starigitan super TCP-kontrolkonekto. Poste la kliento interŝanĝas enkapsulitajn datagramojn kun la plusendada adreso liverita de la prokura servilo. Ĉiu enkapsulita mesaĝo indikas sian celon. Klienta realigo devas trakti tiun kadrigon kaj la vivodaŭron de la kontrolkonekto.
Direkti ordinaran UDP-ingon al la TCP-aŭskultporto de la prokura servilo preterlasas tiujn paŝojn. Sendi la krudajn datagramojn de via aplikaĵo al tiu adreso ne anstataŭas la asocion.
Elektu bibliotekon aŭ aplikaĵan funkcion, kiu eksplicite subtenas SOCKS5 UDP-plusendadon, kaj konfirmu, ke ankaŭ la servilo subtenas ĝin. Biblioteko, kiu reklamas SOCKS-subtenon, eble realigas nur TCP CONNECT. La protokola specifo distingas la komandojn.
La UDP-plusendado ankaŭ bezonas useblan vojon
Sukcesa TCP-konekto al la prokura servilo starigas nur la kontrolvojon. Fajroŝirmiloj aŭ NAT-konduto ankoraŭ povas ĝeni datagramojn senditajn al la plusendado. Kolektu la redonitan plusendadan finpunkton kaj ajnan plusendadan eraron antaŭ ol konkludi, ke la aplikaĵa celo estas senkonekta.
Fine, SOCKS-transporta subteno ne aldonas livergarantiojn al UDP. La propraj tempolimoj de via aplikaĵo, traktado de perdoj kaj limigoj pri mesaĝgrando ankoraŭ validas post kiam la vojo ŝanĝiĝas.