Beta10 已发布，欢迎试用
目前edge/chrome/firefox的扩展也会用到这个OCX控件来和BitComet通信。如果要去掉的话，改动比较大
wnd_size显示还是1M的1048576，也不知道这个选项起效果了没有
那么UTP还比较慢的原因肯定就是cwnd这个了，因为这个看起来比qbittorrent的小
要不然就是rtt延迟
要是优化不了就算了 这速度也算能用了
Beta10效果不错，BT任务tcp黑名单提升到了FIN，ACK之前，成功蒸发掉了3个数据包
长效种子UDP黑名单也正常回403了
[stop_error] peer error 403 [bytes 0/0] [pkg retry = 0%]
长效种子tcp黑名单也成功从8个数据包缩减到5个数据包，应该是应用层上实现黑名单的完美了
上一版beta9是
[stop_timeout] error, retry stopped after 0 retries. (error code 5: connection closed by remote)
这一版beta10是
[stop_timeout] error, retry stopped after 0 retries. (error code 10053: 你的主机中的软件中止了一个已建立的连接。)
右键菜单批量替换tracker的时候，界面会无响应十秒
启动和停止卡可能是处理自动添加tracker耗时比较长
stop_to_run avg: 3ms(x2912), max: 16ms total: 0:00:10.672
这个操作早期我记得改成异步了的，可能因为自动添加tracker功能导致异步后台操作失效了
反复停止开始好像会崩溃，但是我没复现了，只发送了一份崩溃报告
CrashRpt-Log-20260611-030051-{2916d254-f2e1-4608-b366-4c373b8009ba}.txt
磁力分载点： magnet:?xt=urn:btih:8a95aa753e65c7fcede5149141192b86a38efd37&xt=urn:btmh:1220c0b35e38c85141c49f63bbf49776333d4780385598edc969593cb1f1349faee8&dn=BitComet%20V2.21%20Beta10%20%5B20260611%5D
原来其他浏览器也在用啊 那还是留着吧
关于 DHT网络的疑问
现在utp基本上修的差不多了 需要换个方式来对DHT加以控制
使用控制总UDP发包量的方式来限制DHT会影响utp的传输速度
感谢反馈，崩溃报告看到了，错误已修复，和近期TCP端口丢包修复不完善有关
近期来完善一下DHT发包控制
1個讚
主要就是控制DHT启动时，和每30分钟定时发的节点数量，改成8-1000可设置就好了
除非双方都是比特彗星，才可以公网A反向回连NAT1的peer，不然现在AB两者打洞只能靠DHT
ABC的PEX打洞最少需要其中一人是公网身份
当然AB双方都是NAT1两人都没有公网的情况下，就必须要DHT打洞，因为没有成功建立连接自然没办法PEX
不知道你看懂了没有，就是给AB的PEX打洞，B通过PEX给自己加一下列表，这样B可以回给A一下自己的真实端口
现在是A覆盖B的端口信息去反向回连，可以保持现状不用改，额外加一下功能让B回给A的PEX就行了
Beta11 已发布，欢迎试用
beta11 BT种子任务停止重新开始也彻底连不上dht了，一直提示这段英文，除非手动右键菜单里点击更新
DHT announce delayed 00:36 to smooth batch task startup.
而且因为统计页面加了新东西，webui炸掉了
英文显示好像要等36分钟后才能连接到DHT
哦，试了一下是秒而不是分钟，应该改成00:00:36这样显示比较好 ，不过能不能把这个延迟限制去掉？和以前版本那样瞬间直接缓存里取结果多好
这不对吧，，，都要下完了，任务延迟还没连上DHT，dht.outbound_pps_limit改成0也不行
总结：beta11永远无法连上DHT网络，找不到任何peer
还有那个延迟的话可以去掉，或者做成和tracker那样差分，下一次查询的间隔±3分钟，而不是任务启动后延迟去get_peers
我感觉是bug了，禁用启用右下角的DHT开关，抓包也只能看到几个find_node请求，所以导致后续任务get_peers找不到人
反正这一版肯定不行，彻底连不上dht网络了
同一个任务，退版本到beta10就很正常，就是启动后会发发3万个dht包，没想到居然有一万多个session会话数
beta10任务启动瞬间返回400多个peer，也没有延迟这个东西
beta11永远连不上dht网络，找不到任何peer
beta11抓包软件基本抓不到任何发出去的dht流量，设置0也没用！！！等于变成了dht快乐灯了，彻底失去dht作用，只是亮灯但是没有工作
现在beta11肯定有问题的，彻底连不上了
反正utorrent几个包就连上dht网络找到人了
磁力分载点： magnet:?xt=urn:btih:c0e26a8800fedee4a604b5af40c9f9c9ed603e8b&xt=urn:btmh:1220acade95cc94258b306eb0ae830755aa2c33b080f68c7a18b224f3ddf388934b2&dn=BitComet%20V2.21%20Beta11%20%5B20260612%5D&xl=87930616
Beta12 已发布，欢迎试用。
新增的高级设置项 bittorrent.advertise_external_utp_port 用于控制 BitComet 是否允许通过标准 PEX（ut_pex）通告本机外网可访问的 uTP 端口。
该选项开启后，BitComet 并不会无条件通告本地 UDP 监听端口；只有同时满足以下条件时，才会把 (外网 IP, 外网 uTP 端口) 作为一条 PEX self endpoint 通告给已连接 peer：
- 已经通过对端反射或 NAT 检测观察到本机外网 UDP 端口；
- 已手动完成 NAT 类型检测，且检测结果确认为 NAT1 / full cone；
- NAT 检测绑定的是 BitComet 当前实际使用的 uTP/DHT UDP 监听端口；
- 该观测结果未过期；
bittorrent.advertise_external_utp_port = true，且 uTP 未被禁用。
这样可以增强 NAT1 用户通过 uTP 被其他客户端反向连接的能力，同时避免在非 NAT1、端口映射不稳定、未知 NAT 类型，或检测端口与实际 uTP/DHT 监听端口不一致的情况下错误通告无效端口。
测试时可按以下步骤观察：
- 在高级设置中确认
bittorrent.advertise_external_utp_port = true。 - 启用 uTP，并确认 BitComet 已成功监听 UDP 端口。
- 启动 BT 任务，让本机至少建立一个出站 uTP 连接；这一步可帮助 BitComet观察到外网 UDP 端口。
- 手动执行 NAT 类型检测。当前实现不会自动周期性执行 NAT 检测，因此如果不手动检测，PEX self endpoint 通告通常不会被启用。
- 在统计页面查看
BitTorrent Listen Port (UDP)的 IPv4/IPv6 明细：- 如果显示
Observed UDP port: <port> (not advertised until NAT1 is confirmed)，表示已经观察到外网 UDP 端口，但尚未确认 NAT1，因此不会通过 PEX 通告。 - 如果只显示
Observed UDP port: <port>，表示该端口已确认可作为 NAT1 外网 uTP endpoint，可被 PEX 通告。
- 如果显示
- 用三机环境验证效果：A 为公网或普通下载端，B 为 NAT1 且启用本选项，C 为另一下载端。B 确认 NAT1 后连接 A，A 应能通过 PEX 获得 B 的外网 uTP 端口；随后 A 或 C 可尝试按该端口反向建立 uTP 连接。
- 关闭该选项后重复测试，预期 BitComet 不再向
ut_pex追加本机外网 uTP self endpoint，可作为对照组。
1個讚
Beta12 的webui正常了，但是手机端不行？有2套ui吗？
dht现在没有那个延迟了，下一次宣告时间也起作用了，不过应该是±3分钟，差分共6分钟，，现在是差分到12分钟去了，应该和tracker统一用±3分钟
dht依旧有问题，还是搜不到peer，也没办法通过DHT找到自己的服务器ip地址
beta11和beta12怎么样都搜不到peer，任务也找不到自己的服务器ip
双方用2.20版本就瞬间找到一个peer是自己服务器的ip，肯定是代码哪里改错了
测试，双端为比特彗星
B删除用户A，B被A反向回连成功。B收到了来自A的远程访问，但是B统计中还是显示 未观察到
实测后得到，前提条件，只有通过菜单栏NAT类型检测后，才会显示出来
bittorrent.advertise_external_utp_port显示在统计页面后的测试
被加入到统计显示后，现有版本的PEX打洞已经被破坏，B看不到A发送的PEX消息。
不利于B查看A是否把自己的PEX发送给C，应该是beta12把收到A发来给B的PEX给隐藏或者删除了，不要把A发给B的信息给隐藏起来，和上图还没加入统计显示的时候一样，B把收到A的PEX显示出来
实测C连上A后能通过PEX获得B，等于ABC打洞还是好的
我提到的这个打洞最主要是为了加强AB两者PEX互连，在不破坏现有的打洞前提下，增强一下
核心改进：发起uTP连接时，优先使用之前连入过的远程端口（可以实现AB互相打洞，A为公网，B为NAT1的情况，B异常原因断开连接后A可以直接回连到B，而不需要傻傻的等待B后续远程连入到A）
没看出来你实现了什么，测试后唯一看到的就是B把来自A的PEX给隐藏了，和把NAT类型检测的结果在统计页面显示 这两点变化
beta12依旧无法让A获得B的真实nat1端口，没达到最终要实现的目的
大概30分钟，统计里会变回 未被观察到 应该是过期了？
为什么会过期呢，只要不重启光猫，NAT1后这个端口就大概率不会变化。过期后还需要重新去菜单栏做一次检测NAT类型
收到后UTP连入请求后，通过yourport返回的信息不正确，未正确返回nat1背后的真实端口
A通过39332端口连接到B，B给A返回了22223的监听端口
感觉你把东西搞复杂了，比特彗星A用PEX发给B后，B收到A的PEX里面包含自己的ip和NAT1后的端口，那么就把这份列表加入到B自身，B在发回A就可以实现NAT1打洞增强了。
而且因为已经在自己的PEX列表中，那么B直接把这个端口用PEX可以发给C或者D的其它客户端
虽然直接通过NAT类型检测后，可以进一步加强，实现A不是比特彗星也能反向回连
如果A不是比特彗星，那么A就不会发送真实的端口给B，其它客户端不具备NAT1打洞能力
我想的是在完全不靠DHT和检测服务器的前提下，对PEX加强
现有的AB反向回连
对方必须是比特彗星，且对方启用UTP
我提到的AB反向回连增强
我的这套方案，任务中的所有用户里，必须要有一个peer是比特彗星，且对方启用UTP，然后B自己就能获取NAT1背后的端口发给C、D，随后B和C、D实现反向回连
好吧，今天晚上还是突然出现永久丢端口了，启动彗星没几分钟就丢了，而且出现了2次
也就是我之前那套复现方式，全选启动任务大概率复现，正常运行复现看缘分
或许可以加个工作线程来每分钟定时ping 127.0.0.1端口，检测到持续故障5次，就自动化解决一下
注意webui端口也要检测，访问f5刷新几下后，也是经常永久丢端口
不然就要和另一位反馈的人一样，要么写个bat脚本去定时重启，或者人工登录服务器来处理，或者正在发起改成600肯定没问题，我测试过稳定一个月没出过问题
对于DHT网络的implied_port 参数，比特彗星回复别人Announce_peer的时候没有携带NAT1后端口，是否要支持下？
现在只是请求别人的时候带了，和对方回复后拿NAT1后端口，但是比特彗星DHT没有给其它人回implied_port 后的信息
专家模式Get_peers记录在左侧的infohash值有错误
正确infohash值是 f3538f9a6d7c09a20fcd8bdb5ee6cb6e0d9fdb44
但是错误记录成 0000161eacff741fa5865577830d455cc472a133
好像知道原因了，beta12高级设置0无限制或者5000都没作用，每次右键更新只发送3个Get_peers，等待10秒后，每间隔5秒在发送1个Announce_peer，总共3个包
而且发给这3个人的包，都没有收到回包，等于白发了Get_peers，虽然随机挑选的是replied，但是对方可能已经离线了
我想的是应该每种包至少发8个，3个包肯定是不太够的
不对！！！我重启了几次客户端，然后发现你根本不是随机挑选，每次更新都是这个3个人，永久固定的，然后对方也不回包，所以就一直连不上DHT搜不到人
2.20版本每次发134个Get_peers和10个Announce_peer，所以瞬间找到人了
这beta版本每次只发3个，而且还是固定3个节点永远不会变的，对方也不回包，就永远搜不到人
最应该限制的是启动后和每30分钟定时一次的大量Find_node包，而不是去限制Get_peers和Announce_peer
beta只能连3个永久固定的节点就很离谱，至少也得8个吧，而且不要永久固定连接这3个，应该随机挑选
或者高级选项默认限制的是200，应该给200个吧，不理解为什么是3个
总结：这两版beta的dht都是废的，无法正常工作
Announce_peer包也不要做5秒间隔延迟，对同一个ip和端口发起udp请求并不会占用运营商的连接数（session，就和UTP传输一样，对同一个ip地址传数据每秒10万包都只算一个连接数）
5秒间隔也不利于快速把自己的端口发送出去，影响nat1打洞效率
webui只有一套，手机上打开页面有什么问题吗？
好的，下一版改成 ±3分钟
announce/通告列表里的infohash才是本机BT任务的infohash，值列表里的infohash是保存的其他peer announce的其他BT任务的infohash
感谢反馈，下一版恢复之前的DHT请求方式，仅优化UDP包削峰延迟发送的排队算法
1個讚