2.21测试版

欢迎下载测试版,尝试新功能。请大家多提反馈意见,感谢各位支持~

v2.21 Beta13 [20260615]
界面改进:BT peer 列表加 uTP Port 列,默认隐藏
核心改进:取消观测到的 uTP 端口信息超时重置
核心改进:uTP 双向都发送“对端在本连接中的远端 UDP endpoint”
核心改进:高级设置项 bittorrent.advertise_external_utp_port 去掉NAT类型检测确认为NAT1的限制条件
核心改进:观测 uTP 端口时区分 LAN 和 WAN 两种情况
核心修复:恢复之前的DHT请求方式,仅优化UDP包削峰延迟发送的排队算法
WebUI:BT peer 列表加 uTP Port 列,默认隐藏

https://download.bitcomet.com/beta/BitCometBeta_20260615_setup.exe
https://download.bitcomet.com/beta/BitCometBeta_20260615.zip

v2.21 Beta12 [20260613]
界面改进:新增高级设置项:bittorrent.advertise_external_utp_port,在NAT1环境下通过PEX通告自己的外网uTP端口,默认true
界面改进:统计页面增加uTP外网端口监测信息
核心改进:BT握手扩展协议增加yourport字段,当接收到连入的uTP连接时,向对方返回观察到的对方外网uTP端口
核心改进:用户手动进行NAT类型检测后,记录检测到的自己外网UDP端口
核心改进:向已连接的peer发送PEX通告时,满足条件则附带上已检测到的自己外网uTP端口
核心修复:优化DHT发包控制,取消任务启动时首次announce的延迟
WebUI:修复统计页面未能正确显示信息的问题
安装包:签名证书过期,暂时取消数字签名

v2.21 Beta11 [20260612]
界面改进:新增高级设置项:dht.outbound_pps_limit,默认200
界面改进:统计页面UDP传输状态里增加DHT发包状态信息
核心改进:优化DHT发包控制,降低高峰值UDP发包率及session数量对网络设备的冲击
核心修复:TCP发起连接数过高时,TCP端口有丢包现象

v2.21 Beta10 [20260611]
核心改进:完善BT协议及长效上传协议TCP、UDP连入时IP过滤器断开处理

v2.21 Beta9 [20260610]
界面改进:新增高级设置项 network.udp_socket_buffer_size_mb,默认为8MB
界面改进:高级设置项 network.max_connecting_connections_per_tracker 默认值改为 0 (自动)
界面改进:全局统计里的HTTP Tracker 连接数分成 pending 与 half-open 两项统计
核心改进:BT连接的IP过滤器处理移到BT握手之前socket刚连接建立时
核心改进:连入的uTP连接如果被IP过滤器处拦截,按IP限量回复ST_RESET
核心改进:UDP长效上传加上IP过滤器处理
核心改进:优化发起连接的算法,提升pending队列转入half-open队列的处理速度,及处理不同连接类型的均衡性
核心修复:HTTP Tracker避免在连接pending时重复发起连接
核心修复:BT任务磁盘缓存达到上限后,向多个peer上传时,磁盘读取速度远大于上传速度
WebUI:文件列表右键菜单增加"复制下载链接"命令
WebUI:流量图里的CPU使用率统计增加“BT传输线程”、“DHT线程”、“uTP线程”类别

v2.21 Beta8 [20260607]
核心修复:uTP SYN flood 防御算法导致无法接收大量连入的uTP连接
核心修复:TCP发起连接数过高时,TCP端口有丢包现象
WebUI:视频播放窗口右键菜单新增"复制视频下载链接"

v2.21 Beta7 [20260605]
界面改进:远程访问页面增加选项:本地客户端绕过认证、IP白名单里的客户端绕过认证
界面改进:增加命令行参数:profile,可指定程序配置文件目录,用于独立测试
界面改进:BT任务用户列表添加peer对话框支持 # 和 // 内联注释
核心改进:tracker announce 最大间隔改为180分钟,并允许±3分钟抖动
核心修复:大量uTP同时发起连接会导致无法建立连接
WebUI:远程访问页面增加选项:本地客户端绕过认证、白名单里的客户端绕过认证
WebUI:修复HTTP + IP访问页面时,无法复制信息到系统剪贴板的问题

v2.21 Beta6 [20260601]
界面改进:完善窗口深色模式切换机制
界面修复:远程桌面重连后,流量图面板工具栏显示位置错乱
核心改进:完善uTP LEDBAT 拥塞控制算法
核心改进:设置 OS 的 UDP socket发送/接收缓冲区大小为 8MB
WebUI:修复HTTP + IP访问页面时,无法复制信息到系统剪贴板的问题

v2.21 Beta5 [20260526]
界面改进:流量图里的CPU使用率统计增加“uTP线程”类别
核心改进:UDP tracker 完善 Connection ID 超时更新及错误处理
核心改进:优化 UDP 长效上传速率

v2.21 Beta4 [20260524]
核心改进:优化 uTP 上传速度,降低CPU占用率
核心改进:uTP 连接超时降低到10秒
核心修复:增强工作线程进行BT传输加密解密运算的稳定性

v2.21 Beta3 [20260520]
核心修复:增强工作线程进行BT传输加密解密运算的稳定性

v2.21 Beta2 [20260519]
核心改进:优化工作线程进行BT传输加密解密运算的代码,降低CPU占用率
核心改进:优化 uTP 传输代码,降低CPU占用率
核心改进:优化 uTP 数据包 MTU 发送端动态调整算法

v2.21 Beta1 [20260426]
界面改进:增加高级选项 bittorrent.transfer_thread_pool,使用工作线程进行BT传输加密解密运算,默认关闭
界面改进:流量图里的CPU使用率统计增加“BT传输线程”类别
界面改进:BT任务用户列表添加peer对话框支持行首//注释
WebUI:优化任务列表和文件列表的分页加载

1個讚

bittorrent.transfer_thread_pool 不起作用?而且感觉比2.20卡多了,还随便操作几下就崩溃了两次,难道是错觉?我重启服务器试试

好吧,不行,感觉界面卡卡的,而且2.21beta1一直崩溃,无法正常使用,发送了10几份崩溃报告上去了

错误报告已收到,看了一下,是触发了新加的工作线程里进行加解密运算的状态检查保护代码,在某些情况下还需要做额外的处理。下一版修复

建议在UTP选项后添加 实验性 字样以防止用户意外开启



添加个提示,不如直接把utp的问题给解决修复了,从根源上解决问题(拖更好久了)

能解决当然是最好的 但是现在的问题找不到卡住CPU的原因

居然还没找到吗?之前讨论时不是发现是一直在低效复制数据吗,应该是 KeSynchronizeExecutionKiCheckForKernelApcDelivery 的问题


也可能是在循环阻塞等待,应该有数据返回时才继续循环,这样才不占用cpu

````````````````````````````````````````-`````````````````````````````````````````````````````
还有之前提到的,定时器虽然优化了不少,但是也可以放在工作线程

等验证吧 说不定还有别的的问题呢

磁力分载点:magnet:?xt=urn:btih:X2WVYH5SBFPYH2VOWLLT2ZE3TJRSQTZL&xt=urn:btmh:1220004faff13de05e7af250aea84b0dd6151e47dd1864a2bbd4d33114224d862953&dn=BitComet%20V2.21%20Beta1%20%5B20260426%5D

1個讚

請問長時間下載后 BC占用大量内存不釋放

目前除了重啓BC還有更好的辦法嗎

經常看到全部任務都關閉后内存占用都還是在4G以上

是否可以新增 seedleech 這兩個欄位?觀察到許多網站其實都能輕鬆顯示這些資訊。

网站上显示这个是tracker服务器返回的,该功能已有,切换到服务器选项卡就可以查看了
https://bbs.itzmx.com/thread-111853-1-1.html

可能是长时间运行累计较多的种子市场数据,切换到统计分类看看内存是什么原因占用,如果是种子市场可以限制一下最大数量100000,避免消耗太多的内存

v2.21 Beta1你们能正常使用吗?我不论默认关闭bittorrent.transfer_thread_pool的情况,还是开启,都会一直崩溃

可以參考網頁版的呈現方式,直接在種子清單中顯示相關資訊。(彗星)目前僅能在下載或上傳任務中,逐一切換至追蹤器頁面查詢,使用上較不直觀且效率偏低。此外,現有的「熱門」標示缺乏數字化指標,無法清楚反映實際熱度,相較之下不如直接顯示 seed、leech 數量來得直覺明確。

彗星下載 http 功能, 檔案會漏資料是什原因?

目前使用版本

測試連結: https://archive.org/compress/jacky-cheung-gold-collection-k2hd/formats=FLAC&file=/jacky-cheung-gold-collection-k2hd.zip

下載續傳顯示正常

使用 7zip 解壓縮

就會出現錯誤

檔案也會不全?

若使用 Chrome 瀏覽器直接下載

檔案解壓縮是正常

那可以让官方在种子市场做个帖子上介绍的scrape功能
设置个scrape服务器用于查询,tcp或者udp均可
比如给某个tracker服务器打"星标"代表使用这台服务器作为scrape

udp查scrape的话,毕竟没有utp那种自动mtu检测,考虑到穿透mullvad或者的类似软件
使用udp查询scrape,确保组合一次发送≤66个hash查询,udp包内容在1352内(1360-udp包8=1352实际数据),20字节一个hash+scrape包头16字节,66个hash的情况下=1336字节

使用tcp查询,由于url长度限制2048,确保发送≤25个hash查询,每个hash占用71字节,路径与协议包头开销20字节,剩下的253字节预留给域名dns长度

感觉是多线程的问题的 我这边只协商到单线程 下载的文件没有问题
浏览器下载是单线程的也没有问题

你这个链接复现解压不了的情况

单独使用302跳转后的域名去多线程下载没有问题,任选其中一个直接去多线程下载都正常
https://ia800107.us.archive.org/zip_dir.php?path=/0/items/jacky-cheung-gold-collection-k2hd.zip&formats=FLAC
https://ia600107.us.archive.org/zip_dir.php?path=/0/items/jacky-cheung-gold-collection-k2hd.zip&formats=FLAC

但是用主域名链接 archive.org 去下载就出问题了

下了个 Beyond Compare 比较了下数据,左侧失败,右侧解压正常,看起来缺少一些字符

看了您的建議,感覺會增加開發者麻煩並非自己本意,主要是我對「熱門」欄位的呈現方式還不太理解。實際使用上,大部分情況似乎都不會有燈號顯示。

我想釐清的是:這個燈號本身是否具有「是否可下載」的參考價值?還是只是補充資訊?另外是否有進一步優化的空間?

我有稍微測試過,隨機下載一個標示為熱門的項目,但卻沒有燈號顯示;

進一步查看 tracker 資訊後,實際上是有不少 seed 的。

在 BitTorrent 生態裡,其實使用者最直覺在意的只有一件事:「這個東西能不能下載?」

而不是精確到有 137 個還是 142 個 seed。

因此我覺得「熱門燈號」本身是很好的概念,也很直覺易懂。若能強化至關重要給出第一顆燈號的判斷(例如是否可下載 / 是否存活),會更有實際意義;至於燈號數量多寡,則比較偏向影響下載速度的參考資訊。