之前的dht.udp_send_queue_threshold设置1的时候效果巨好，一旦触发全局udp队列就会丢包不做回复。那等你改了后看看能不能实现需求吧
你这命名有点奇怪，out代表流出，流入不应该是in吗？怎么用了个pass
感谢反馈，已找到代码bug，下一版修复
Beta14 已发布，欢迎试用
你现在是所有包都回了啊，ping、Get_peers、Find_node全啥都回了ip字段，这不对啊
按照上面说的参考BEP5，只对接收到Announce_peer包并且对方明确使用implied_port=1的时候，才回复ip字段比较好吧？
不过可以改成所有收到Announce_peer包都回ip字段，可以不管对方是否发了implied_port=1
别人只是发Get_peers查找节点或者peer，其它包回ip字段就是浪费流量
Beta14 界面上显示的Infohash现在正确了
这一版有问题，统计里数据都对不上了，总共发包60万次，但是统计里面全部加起来也才25万次
没统计到看了下是你之前Connection改动导致的，你改成了每分钟重发一次Connection，这个包没统计进去到udp tracker分类里
而且不知道为什么连接一次tracker会一次性发送10个udp包
你试一下，比如发现是域名返回10个A记录的原因，所以一次性发送了10个查询包到同一个目标ip上，应该只发送1个包才对
udp://tracker1.itzmx.com:8080/announce
http tracker没有问题，只有udp tracker出bug了，试了下以前版本就有这个问题
dht.passive_reply_pending_limit设置1后成功了，达到了以前dht.udp_send_queue_threshold一样的效果了
B依旧用户列表看不到PEX，列表上是空的，肯定是被你隐藏起来了，不要隐藏啊，这里保持和2.20一样显示出来
不会影响peer添加到用户列表里吧？这个不太好测试
https://download.bitcomet.com/beta/BitCometBeta_20260615_setup.exe
https://download.bitcomet.com/beta/BitCometBeta_20260615.zip
磁力分载点： magnet:?xt=urn:btih:a206889bc2843eeb6d08e2fc8112e93fe4d45063&xt=urn:btmh:122034ff5159bcb8740e207e5fcadc267738bd2bdfbfa765102b639e866b6221d6da&dn=BitComet%20V2.21%20Beta13%20%5B20260615%5D
按照beta14，180秒强制断开out Find_node的话，计算了下遇到限制的运营商1000连接数做三七分，限制为每分钟最多产生140个dht数据包
也就是说大家测试的时候可以这样填写高级设置，不影响客户端只运行一个任务的情况下去搜索peer，明天晚上我用nat4网络进一步确认
dht.outbound_pending_request_limit 200
dht.outbound_pps_limit 2
dht.passive_reply_pending_limit 1
dht.passive_reply_pps_limit 500
下方计算300是因为运营商限制每5分钟的连接数，300秒内超过1000个数据包就做丢包处理
dht.outbound_pps_limit 2 这个数值如何得出？上面介绍过了，1000数据包*0.7/300=2
dht.passive_reply_pps_limit 500 这个数值如何得出？这是默认值，保持默认即可（nat4下基本不会接收到他人请求的流量）
如果是种子服务器，或者没有被连接数限制的运营商可以保持out默认值
磁力分载点： magnet:?xt=urn:btih:707147d535218dc791b0cf50910db6dd96e08398&xt=urn:btmh:1220dbd572fa3aaeb162c7ed6ead1fbc64df7a2d4206d40ec093691e3a8a04bd10cc&dn=BitComet%20V2.21%20Beta14%20%5B20260616%5D
beta14试了一晚上，这一版基于DHT网络的NAT1打洞一直不成功
上一版怎么样都正常
抓包看了下原来之前版本已经实现的打洞功能直接被你破坏了
上一版是正常的，beta14的DHT NAT1打洞就烂了，抓包对比，beta14发送Announce_peer包的时候，implied_port=1直接丢失了
beta13
beta14
也许和Windows的 PPPoE 有关使用路由器拨号时应该不太会出现此问题
与之相似的问题倒是在系统意外关机后会出现
意外关机后首次启动 会导致BC无法监听原来的端口
改为其他端端口后可以正常监听 监听其他端口后在监听先前端口依然失败
再次重启Windows后 一切恢复正常
IPv6的UDP端口似乎总是 未观察到？
我们复现的是端口在系统上能看到正常监听，但是tcp端口被软件应用层永久阻塞不可访问
1個讚
在有连接数限制的环境下，这份dht设置成功，可以正常开启dht开关去下载，不会触发限制
我好像找到问题了，因为我在默认禁止UTP的时候连接上了DHT网络，比特彗星只有在启用UTP后才会发送implied_port，导致了别人记录了我的tcp监听端口。
后续启用UTP在去连接DHT网络，虽然此时Announce_peer携带了implied_port，但是对方DHT节点存储的还是之前的监听端口导致的，所以一直搜不到真实的对外端口
重启光猫更换ip后，用DHT的新用户身份重新在去测试就正常了，这样对方DHT节点会重新记录peer
这个不是问题，因为处于TCP的情况下，肯定是要监听端口的，不然TCP就废了，那这里就不用改了
所以这是BC自身的问题？
YES。。。。
对的，比特彗星代码层出现竞争死锁导致的，这几个版本都在尝试更新修复，beta14目前暂时还没遇到丢端口
好的，下一版改成这样。之前按照BEP42，是所有包都要加ip字段的。
看了一下，是UDP tracker 向DNS多个返回结果都发了包，但只统计了一次。下一版修复。
确实是域名返回10个A记录的原因。下一版优化一下，最多发3个
发一个就好了，dns本身会自动轮询的，每次通过api找到的域名ip地址都是不一样的，没必要同时向域名多个ip一起发包，同时对多个ip发包也不利于多台服务器实现均衡负载了，和http一样，只发一个
没错，只用处理Announce_peer回包的情况添加ip字段就可以了，BEP42上面提到的做法就是浪费流量，服务器一般每秒几千个左右DHT接收包要回复，假设一个ip字段算20字节，1000个包就是20KB/s流量浪费
而且国内广电网络之类一些运营商，出口ip都是乱跳的。或者用了tz或者tor匿名软件会有多ip出口，那么BEP42检测令牌额外做的安全ID验证的做法就把自己弄废了
