ping也包没显示，而且也没应用到dht.outbound_pps_limit限制中，限制2但是一直每秒6个包左右
这个一直没改过，每个peer一行，分未连接、连接中、已连接三组。你说的没显示的peer是具体哪一个呢？A/B? IPv4/IPv6?
你看图，图上右侧是v2.20版本，B显示A传到B的PEX，内容为B自身的ip和真实外部端口
https://www.cometbbs.com/uploads/default/original/3X/5/8/587aba87725cb4aef3d4214ee117052bb0aec617.png
beta12开始，B收到A传来的是一串十六进制的信息，解码转换十进制后是A自身的ip和端口，而不是B的ip和端口
https://www.cometbbs.com/uploads/default/original/3X/f/a/fa065209ed3c94203c7602ce9cdc9d2b81a30872.png
是被你从beta12改坏的，能不能看懂，不能我录个屏
目前announce_peer 和 ping都没做排队限额丢包处理，只有 get_peers/find_node 是真正的启动突发源，做了排队限额
ping包也很多，一分钟跑了1000多个包，可能是每三十分钟维护节点产生的ping包
我用beta14和v2.20测试了一下：
1、BitComet旧版B连新版A，新版A会通过EXT_PEERS回传旧版的外网IP:port，旧版B收到后没有验证peer_id，会把自己的外网IP:port显示为单独的新peer了，但正真进行uTP连接后，会连接失败。新版A也会通过EXT_PEERS回传自己的外网IP:port，旧版B接收后判断，如果与已连接的A一致，会去重忽略掉，不额外显示，不一致才会额外显示。
2、BitComet新版B连新版A，新版A会通过EXT_PEERS回传对方的外网IP:port，新版B收到后会验证peer_id，直接将返回的port记为自己的uTP port，不会新增一个peer。新版A也会通过EXT_PEERS回传自己的外网IP:port，新版B接收后判断，如果与已连接的A一致，会去重忽略掉，不额外显示，不一致才会额外显示。
beta15修改方案：
1、BitComet新版不再通过PEX向BitComet旧版及其他客户端回传对方的外网IP:port，避免旧版把该端点误当成普通 peer；但会回传自己的外网IP:port；
2、BitComet新版之间连接时，通过新增的yourport字段回传对方的外网 uTP 端口，通过PEX回传自己的外网IP:port信息。
3、BitComet新版收到新版回传的自己外网IP:port信息后，只要外网IP和peer_id一致，就不会单独一行显示，而是更新本机的uTP端口信息。
Beta15已发布，欢迎试用
1個讚
果然被你偷偷隐藏起来了，等会让我试试新版能不能显示出来了
随机不太好吧？下发ttl为600的情况也会无视dns缓存，每次右键更新会分到不同的服务器去请求
和http那样只取第一个就行了啊，DNS服务器都会自动轮询的
例如配置 IP 192.168.1.1 和 192.168.1.2，每次解析均返回两个 IP，
但顺序交替（如首次返回 [192.168.1.1, 192.168.1.2]，
下次返回 [192.168.1.2, 192.168.1.1]）。
而且看起来你还A和AAAA同时发了等于2个请求去了这样不好（我还没测会不会发送2个，现在测试环境网络没ipv6）
这是tracker管理员去负责的事情，分成2个二级域名来分别提供A和AAAA
特别是在私有tracker的时候，客户端发送双倍重复流量是绝对不允许的
我发现这个奇怪的 64:ff9b::2666:7f06 是怎么从A传给对方B的了，服务器并没有ipv6，不是B解析错误，是A传错了
你在beta13还是beta12里面不知道做了什么，导致显示出一个错误的对外ip，应该是和你改动了dht有关，之前版本不会错误显示出这个ipv6的
哦，我用v2.20作为A，beta15作为B，双方关闭DHT网络测试，A依旧获得了这个奇怪的 64:ff9b::2666:7f06，确定是B发给A的
每30分钟依旧会断网一次，确定原因就是那个DHT网络定时大量发起的ping包，需要把ping包列入dht.outbound_pps_limit限制中
这个正常了，现在只有收到announce_peer去回ip字段
Beta15 该版本依旧被隐藏了没有显示出来
而且这一版改的会不会破坏原有的ABC打洞还要稍后测试
你看看高级选项 network.preferred_network_adapter_ipv6 的下拉菜单，有没有ipv6的网络接口呢？
另外 bittorrent.peer_dual_ip 关掉试试看
行，那就只发给第一个解析的记录
测试环境双方都没有公网ipv6的
种子服务器的
自己电脑的
双方用v2.20就没这个问题
这样就对了，DNS负责自动轮询就行了
返回A就连接A，返回AAAA就连接AAAA，而不是同时发两个包请求
这里存储的100个info_hash做好了peer上限吗？会不会数值突破几千上万的情况
抓取dht网络本地回复对方请求的Get_peers包，并且包内要求包含peer响应
bt-dht and frame contains "valuesl6:"
info_hash数量上限100，每个info_hash的peer数量上限500
好的，把 announce_peer 和定时维护 ping 也纳入dht.outbound_pps_limit限制
dht下每存储一个peer要求格式 6:+ip+端口 ，存储一个用户共8字节
现在是一次返回存储的500个？还是从池子里随机挑选
dht本地回复对方Get_peers产生的协议头共93字节
等于存储5个peer需要93+8*5=133实际内容字节，133+8+20=161mtu
为了控制1352实际内容，1380的mtu可有效安全通过vpn隧道软件
那么ipv4下一次最多返回157个peer
如果是ipv6那么每存储一个peer是消耗21字节，一次最多返回59个peer
如果返回500个那么可能会丢包，我没info_hash上没这么多peer不清楚是否会发生，你看看有做单次请求的最大返回数量吗
每次最多返回50个
那个A传给B的奇怪的 64:ff9b::2666:7f06 到底是A报告的自己的IP，还是A回传的B的外网IP？我看截图里，A和B的监听端口都是22223，不好区分
首先应该是beta12开始，A自身统计里面就能看到这个错误的ip信息，不知道怎么冒出来的，先把这个解决看看，之前版本都没这个现象
这个值我用ai翻译过，是ipv4的十六进制转换出来的
怀疑是这几个版本改动dht网络导致的，通过dht拿到了错误的ipv6显示，我把开关禁用看看还会不会出现
如果对他人Get_peers请求后续打算加上返回8个nodes节点（每个26字节），那么ipv6下估计就不能返回50个了，要改成49个
当前协议头共93字节
预计加上8个nodes节点，那么协议头大小预计会从93字节变成320字节左右