Indy se zero UDP ASSOCIATE-adres is nie die datagram-teiken nie

Skei die kliënt-assosiasieadres, die teruggekeerde SOCKS-relais en die teiken wat in elke UDP-pakket geënkodeer is.

0.0.0.0:0 in 'n Indy UDP ASSOCIATE-versoek kan opsetlik wees. Daardie versoek beskryf die verwagte kliëntkant-UDP-eindpunt, en RFC 1928 laat nulle toe wanneer dit onbekend is. Dit kies nie die finale diens nie.

Die antwoord se BND.ADDR/BND.PORT dui die relais aan waarheen die kliënt ingekapselde datagramme stuur.

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

In Indy roep TIdUDPClient.Connect die deursigtige proxy se OpenUDP aan. TIdSocksInfo voorsien die zero-assosiasievelde. Later gee SendBuffer die gewenste diens aan SendToUDP deur, wat die SOCKS UDP-bestemmingsopskrif voor die toepassingsdata bou.

As die assosiasie slaag maar verkeer misluk, ondersoek die teruggekeerde relais, geënkodeerde bestemming en UDP-antwoordpad. NAT/brandmure kan die TCP-uitruiling toelaat terwyl UDP geblokkeer word.

Hou die TCP-beheerverbinding oop; as dit sluit, eindig die assosiasie. SOCKS4/4a het nie hierdie bewerking nie, en SOCKS5-handelsmerk alleen waarborg nie dat 'n bediener UDP ondersteun nie.

Verwante artikels