XDNS finalmask: apply sockopt to outgoing sockets for resolvers.

[26X23]

Policy-based routing with XDNS was broken in v26.4.13. Since then XDNS creates new sockets for resolvers and doesn't apply sockopt (and mark). Also sendThrough isn't used.

There is no need to create new sockets for every resolver. One preconfigured raw net.PacketConn may be used for all resolvers.

[Fangliding]

这样肯定不行 太丑了

[Fangliding]

#5872 从一开始就是AI slop想法自己打破封装 在finalmask里乱搞就算了别霍霍别的包

[RPRX]

可以接受应用 sockopt 但不能改这么多文件

[26X23]

Another way to partially fix is to use the raw net.PacketConn parameter rather than creating a new socket when there is only one resolver and there is no BindAddress (more correct would be to specify many addresses on the transport level and wrap them all in the finalmask, similar to how multiple ports are defined on the inbound level and then used in the dokodemo-door's portMap).
Yet another way is to copy predefined set of sockopts from raw net.PacketConn to resolverConns.
Or perhaps if we pass the list of internet.Controllers plus another one controller capturing SocketConfig to the WrapPacketConnClient there will be no import cycle.
Do you think this would be better than modifying so many files?

[Fangliding]

而且udp本来就可以对着设置好的packet conn writeto readfrom 不知道那玩意为什么还得自己单开连接

[26X23]

@Fangliding please review the new version of this PR (it's better to view without whitespace changes). Only 2 files changed now. New sockets for resolvers are not created anymore.

[RPRX]

@LjhAUMEM XDNS 目前只支持 UDP，我觉得是可以先改成 WriteTo 而不是创建一堆新 sockets，你看下这个 PR 可以合并不

[LjhAUMEM]

@LjhAUMEM XDNS 目前只支持 UDP，我觉得是可以先改成 WriteTo 而不是创建一堆新 sockets

开新 socket 不是你说的吗 #5872 (comment)

你看下这个 PR 可以合并不

完全不能，现在非常反感 ai 人，标题说的应用 socketopt 现在又只有改回单 conn 的修改

[RPRX]

那我确实说过，但现在有没应用 sockopt 这个问题。。。这个好修不，你改一下开个 PR 吧

[Fangliding]

说实话不好动 单socket反而简单点

[LjhAUMEM]

想了想改回单 conn 后就没有应用 sockopt 的问题了，不过改回单 conn 可能也不通过，ipv4 也 as16 不会出问题吗

那我确实说过，但现在有没应用 sockopt 这个问题。。。这个好修不，你改一下开个 PR 吧

只是改到单 conn 吧，那我来开个吧，到时候再加 co-authored，审完的精力自己早都写好了

[Fangliding]

ipv4 也 as16 不会出问题吗

As16 对ipv4可以用 一个很经典的坑 返回一个 ipv4 mapped ipv6 在标准库里很多地方都视为是一样的 但是也导致了很多麻烦 比如在需要的时候区分不出真的 ipv4 和 mapped ipv4 以及一些标准库函数返回哪种 ip 还在左右脑互搏

[26X23]

只是改到单 conn 吧

Yes. I switched back to a single PacketConn.

ipv4 也 as16 不会出问题吗

normalizeAddrPort is used only to compare the address of the received packet with the address of the resolver from the configuration. This normalized address isn't used for sending or anything else. So I don't think it will cause any problems. Without normalization addresses were sometimes incomparable. One was [::ffff.1.2.3.4]:53, and the other was 1.2.3.4:53

[LjhAUMEM]

@26X23 用我那一版吧，你现在这个除了改回单 conn 还相当于把单个 resolver 的 domain 和 ip 绑定了，然后还没改完，writeto 和 sendloop 那里还是乱序的

[RPRX]

但是 u1s1 单 conn 只能暂时解决问题，这以后支持个 example.com+https:// 咋整

[Fangliding]

那就不叫udp mask了 跟我之前吐槽的那样实质性变成第二层transport

[RPRX]

这 udp 的意思是适用于 udp 而不是一定还是以 udp 的形式发出，不然你让 XICMP 咋办

某种程度上来说它确实是又一层 transport，除了第二层还有负一层呢，以后要加个 pre

[26X23]

@LjhAUMEM I tested your PR (8bd1c92), it seems to work.

还相当于把单个 resolver 的 domain 和 ip 绑定了

I compare the pair (domain, IP-address) to match current behavior. Because one IP-address could be used with multiple domains (e.g.: t1.xdns.com+udp://1.1.1.1:53, t2.xdns.com+udp://1.1.1.1:53, t3.xdns.com+udp://8.8.8.8:53). In your PR domain isn't used to increment resolverSend, therefore first domain (t1.xdns.com) will be selected more frequently than second (t2.xdns.com) in the condition if c.resolverSend[c.resolverAddrs[c.resolverIdx].String()].Load() < curSend { break }.