Adireshin sifili na UDP ASSOCIATE a Indy ba shine makasudin datagram ba
Rarrabe adireshin haɗin abokin ciniki, SOCKS relay da aka mayar, da makasudin da aka lissafa a kowane fakitin UDP.
0.0.0.0:0 a cikin buƙatar Indy UDP ASSOCIATE na iya zama da gangan. Wannan buƙatar tana bayyana ƙarshen UDP da ake tsammani a gefen abokin ciniki, kuma RFC 1928 yana ba da izinin sifili idan ba a sani ba. Ba ya zaɓar sabis na ƙarshe.
BND.ADDR/BND.PORT na amsar suna nuna relay ɗin da abokin ciniki ke aika datagram ɗin da aka lulluɓe zuwa gare shi.
TCP control: client → SOCKS5 proxy → UDP association reply
UDP payload: client → returned relay address → target serviceA cikin Indy, TIdUDPClient.Connect yana kiran OpenUDP na wakilin bayyananne. TIdSocksInfo yana bayar da filayen haɗin sifili. Daga baya, SendBuffer yana ba da sabis ɗin da ake so ga SendToUDP, wanda ke gina kanun manufa na SOCKS UDP kafin bayanan aikace-aikacen.
Idan haɗin ya yi nasara amma zirga-zirga ya kasa, duba relay ɗin da aka mayar, makasudin da aka lissafa da hanyar amsar UDP. NAT/ganuwar wuta na iya ba da izinin musayar TCP yayin da suke toshe UDP.
Riƙe haɗin sarrafa TCP a buɗe; rufe shi yana kawo ƙarshen haɗin. SOCKS4/4a ba su da wannan aiki, kuma sunan SOCKS5 kawai ba ya tabbatar da cewa uwar garke tana goyon bayan UDP.