Java DatagramSocket dhe ridërgimi UDP përmes SOCKS5
Kuptoni pse një socket UDP në Java kërkon një zbatim SOCKS5 UDP edhe kur lidhjet TCP përdorin tashmë SOCKS.
Kërkesa juaj HTTP në Java funksionon përmes SOCKS, por një veçori UDP ende dërgon trafik drejtpërdrejt ose dështon. Vendosja e vetive SOCKS të JVM-së nuk i jep DatagramSocket një zbatim SOCKS5 UDP.
API DatagramSocket dërgon dhe pranon datagrame të adresuara drejt pikave fundore të rrjetit. Metoda e tij connect() zgjedh një homolog për atë socket. Ai nuk kryen një negocim SOCKS me homologun.
Një rrugë UDP përmes SOCKS5 kërkon punë shtesë
SOCKS5 përcakton një asociim UDP të vendosur mbi një lidhje kontrolli TCP. Më pas klienti shkëmben datagrame të inkapsuluara me adresën e ridërgimit që jep proxy-i. Çdo mesazh i inkapsuluar tregon destinacionin e tij. Një zbatim klienti duhet të trajtojë atë kornizim dhe jetëgjatësinë e lidhjes së kontrollit.
Drejtimi i një socket UDP të zakonshëm te porta e dëgjimit TCP e proxy-it i anashkalon ato hapa. Dërgimi i datagrameve të papërpunuara të aplikacionit tuaj në atë adresë nuk e zëvendëson asociimin.
Zgjidhni një bibliotekë ose veçori aplikacioni që mbështet në mënyrë të qartë ridërgimin UDP përmes SOCKS5 dhe konfirmoni se edhe serveri e mbështet. Një bibliotekë që reklamon mbështetje SOCKS mund të zbatojë vetëm TCP CONNECT. Specifikimi i protokollit i dallon këto komanda.
Ridërgimi UDP kërkon gjithashtu një rrugë të përdorshme
Një lidhje TCP e suksesshme me proxy-in vendos vetëm rrugën e kontrollit. Muret e zjarrit ose sjellja e NAT mund të ndërhyjnë ende me datagramet e dërguara te ridërgimi. Mblidhni pikën fundore të ridërgimit të kthyer dhe çdo gabim ridërgimi përpara se të konkludoni se destinacioni i aplikacionit është jashtë linje.
Së fundi, mbështetja e transportit SOCKS nuk shton garanci dorëzimi për UDP. Afatet kohore të vetë aplikacionit tuaj, trajtimi i humbjeve dhe kufizimet e madhësisë së mesazheve vazhdojnë të zbatohen pasi rruga ndryshon.