It nul-UDP ASSOCIATE-adres fan Indy is net it datagramdoel

Skied it assosjaasje-adres fan de klant, de weromjûne SOCKS-relay en it doel dat yn elk UDP-pakket kodearre is.

0.0.0.0:0 yn in Indy UDP ASSOCIATE-oanfraach kin opsetlik wêze. Dy oanfraach beskriuwt it ferwachte UDP-einpunt oan klantside, en RFC 1928 lit nullen ta as it ûnbekend is. It kiest net de definitive tsjinst.

De BND.ADDR/BND.PORT fan it antwurd jout de relay oan wêrnei de klant ynkapsele datagrammen stjoert.

TCP control: client → SOCKS5 proxy → UDP association reply
UDP payload: client → returned relay address → target service

Yn Indy ropt TIdUDPClient.Connect de OpenUDP fan 'e transparante proxy oan. TIdSocksInfo leveret de nul-assosjaasjefjilden. Letter jout SendBuffer de winske tsjinst troch oan SendToUDP, dy't de SOCKS UDP-bestimmingskop foar de applikaasjegegevens bout.

As de assosjaasje slagget mar it ferkear mislearret, ûndersykje dan de weromjûne relay, it kodearre bestimming en it UDP-antwurdpaad. NAT/firewalls kinne de TCP-útwikseling tastean wylst se UDP blokkearje.

Hâld de TCP-kontrôleferbining iepen; it sluten einiget de assosjaasje. SOCKS4/4a misse dizze operaasje, en de namme SOCKS5 allinnich garandearret net dat in server UDP stipet.

Relatearre artikelen