Hi, > > I think you're right. Unless you're hosting some UDP server, the > communication involves only one remote peer in most cases. ACL selection > does become easier, but route selection is done in the kernel on a > per-packet basis, so route lookup won't get optimized.
The route selection I mean here is sometimes we need to bind the local socket to IP addresses from different ISP on the same host, that's the case I care the most for a fixed remote peer, as for cdn domains, we need to decide which ISP should be used before resolving. > > > > So I suggest to add a new udp connect command, with the address and port > > in socks request to be the target udp address and port. > > I think adding a Remote Peer option (containing the address and port) to > the already-existing UDP ASSOCIATE command would be a more elegant > solution. Some protocols, like RTP, still require control over the > source port, so we also need the Associate semantics for Connect either way. > > > To complement this new option, a null SOCKS address type could be added. > The actual "null" address should be empty, i. e. not take any space. If > the remote peer negotiation is successful, the client can go ahead and > use null addresses for its datagrams. > > > I can see some other benefits: > > * The datagram header becomes smaller. > > * If the remote host is known by hostname, rather than by IP address, > the client no longer has to do a DNS query beforehand. (It's also > possible to place the hostname into each datagram header, but that's > impractical.) I have thought about this method this morning, and yes it's better than adding a new command. > > A new option > > is also recommended to be added to tell the proxy server the address > > and port > > of the client, so port reuse for the client-proxy udp connections can > > be enabled > > when the proxy server setup the client side udp socket. > > That is no longer an issue in SOCKS 6. Now all UDP flows go to the same > port, 1080 by default for plain UDP and TBD for DTLS. Oh, I have missed this point in socks6. The following is not about the protocol, but just some thoughts about the implementation: I haven't experienced with UDP traffic multiplexing, it seems to be the same way as QUIC. But I still have some worry, as at the app layer we need to receive packets one per syscall, will it be enough for more than 60000 sessions? Port binding per cpu and large send/recv buffer are needed. I have thought using XDP+ring on linux to decrease the recv/send syscall used, or is there any better ways? _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
