2.04测试版

对单任务就行

问题应该是出现在彗星上

在内网彗星互传没有任何问题
但是内网测试中和qb之间传输存在问题

qb上传bc下载没有问题
bc上传qb下载存在问题
qb可以获取元数据 但无法进行下载


从图上的标志位来看似乎是qb希望下载但bc不同意上传


手动复制文件使qb完成任务进入上传状态
一些外网的客户端可能通过DHT获取到了这个种子并尝试下载
但出现了进度卡在0%的情况

从qb的标志位上看
qb同意上传但对方(bc)不想下载


又进行了简单的抓包
看一下和这些不愿意下载的客户端之间有什么信息交换

虽然不能完全看懂到抓包获得的信息
但可以确定是它们都没有 发送 Request 消息
这应该就是为什么会在标志位或状态会显示 不愿下载 或 不感兴趣的原因

怀疑是还是元数据下载的问题

其中一则 Extended Continuation data 消息似乎在传递元数据
卡进度的BC客户端不发送下载请求的原因可能就藏在
其他的 Extended Continuation data 消息中

抓包结果:
链接
密码:bc

bc_2文件是bc做种时和其他卡进度客户端之间传输的内容
qb_2文件是qb做种时和其他卡进度客户端之间传输的内容

0000   c4 09 38 ea 2c b9 00 0c 29 96 7f 1f 08 00 45 00   ..8.,...).....E.
0010   03 f2 be e4 40 00 80 06 00 00 c0 a8 05 6b 31 d5   ....@........k1.
0020   e4 c4 f4 d0 5b 9f 72 4b 9f 15 e7 21 38 55 50 10   ....[.rK...!8UP.
0030   03 ff e0 91 00 00 00 00 02 95 14 01 64 38 3a 6d   ............d8:m
0040   73 67 5f 74 79 70 65 69 31 65 35 3a 70 69 65 63   sg_typei1e5:piec
0050   65 69 30 65 31 30 3a 74 6f 74 61 6c 5f 73 69 7a   ei0e10:total_siz
0060   65 69 36 31 36 65 65 64 39 3a 66 69 6c 65 20 74   ei616eed9:file t
0070   72 65 65 64 31 34 3a 70 65 65 72 5f 73 68 61 72   reed14:peer_shar
0080   65 73 2e 64 62 64 30 3a 64 34 3a 65 64 32 6b 31   es.dbd0:d4:ed2k1
0090   36 3a 0c d7 54 fa b3 8f 6b 0c 66 ef e9 7b 04 4e   6:..T...k.f..{.N
00a0   7c cb 38 3a 66 69 6c 65 68 61 73 68 32 30 3a 7e   |.8:filehash20:~
00b0   cf eb f4 9d a4 2f 04 70 10 5c 55 92 60 4d 4d b2   ...../.p.\U.`MM.
00c0   d7 a6 bc 36 3a 6c 65 6e 67 74 68 69 35 31 35 39   ...6:lengthi5159
00d0   39 33 32 39 32 38 65 31 31 3a 70 69 65 63 65 73   932928e11:pieces
00e0   20 72 6f 6f 74 33 32 3a 41 06 57 3a 37 23 5e b7    root32:A.W:7#^.
00f0   cf c4 07 c7 3c b0 16 5d 3d 31 fc d2 4c b9 67 3a   ....<..]=1..L.g:
0100   b5 89 c1 77 73 7e d4 3b 65 65 32 39 3a e4 bb 96   ...ws~.;ee29:...
0110   e4 ba ba e5 85 b1 e4 ba ab 28 32 30 36 39 33 38   .........(206938
0120   34 36 29 2e 62 63 5f 62 61 6b 64 30 3a 64 34 3a   46).bc_bakd0:d4:
0130   65 64 32 6b 31 36 3a 83 d8 ba f7 53 0c 0a ca ac   ed2k16:....S....
0140   2f 3f 7d 6c bc 5b a2 38 3a 66 69 6c 65 68 61 73   /?}l.[.8:filehas
0150   68 32 30 3a 7b 39 01 81 5a c0 f4 c9 ad c2 bf a1   h20:{9..Z.......
0160   44 3c d9 87 24 82 28 d3 36 3a 6c 65 6e 67 74 68   D<..$.(.6:length
0170   69 32 37 31 34 39 30 33 37 34 38 65 31 31 3a 70   i2714903748e11:p
0180   69 65 63 65 73 20 72 6f 6f 74 33 32 3a c6 4a 0e   ieces root32:.J.
0190   23 a5 8a 4c 8d 17 ed bb bf fc f9 e0 11 8a 24 51   #..L..........$Q
01a0   3f c8 37 c7 f7 76 8d 9a bf 62 5f e1 ae 65 65 65   ?.7..v...b_..eee
01b0   31 32 3a 6d 65 74 61 20 76 65 72 73 69 6f 6e 69   12:meta versioni
01c0   32 65 34 3a 6e 61 6d 65 33 35 3a e7 a7 8d e5 ad   2e4:name35:.....
01d0   90 e5 b8 82 e5 9c ba 2d e4 bb 96 e4 ba ba e5 85   .......-........
01e0   b1 e4 ba ab 28 32 30 36 39 33 38 34 36 29 31 30   ....(20693846)10
01f0   3a 6e 61 6d 65 2e 75 74 66 2d 38 33 35 3a e7 a7   :name.utf-835:..
0200   8d e5 ad 90 e5 b8 82 e5 9c ba 2d e4 bb 96 e4 ba   ..........-.....
0210   ba e5 85 b1 e4 ba ab 28 32 30 36 39 33 38 34 36   .......(20693846
0220   29 31 32 3a 70 69 65 63 65 20 6c 65 6e 67 74 68   )12:piece length
0230   69 31 30 34 38 35 37 36 65 39 3a 70 75 62 6c 69   i1048576e9:publi
0240   73 68 65 72 34 3a 69 65 31 32 31 33 3a 70 75 62   sher4:ie1213:pub
0250   6c 69 73 68 65 72 2d 75 72 6c 33 32 3a 68 74 74   lisher-url32:htt
0260   70 73 3a 2f 2f 77 77 77 2e 63 6f 6d 65 74 62 62   ps://www.cometbb
0270   73 2e 63 6f 6d 2f 74 2f 38 38 37 37 31 31 39 3a   s.com/t/8877119:
0280   70 75 62 6c 69 73 68 65 72 2d 75 72 6c 2e 75 74   publisher-url.ut
0290   66 2d 38 33 32 3a 68 74 74 70 73 3a 2f 2f 77 77   f-832:https://ww
02a0   77 2e 63 6f 6d 65 74 62 62 73 2e 63 6f 6d 2f 74   w.cometbbs.com/t
02b0   2f 38 38 37 37 31 31 35 3a 70 75 62 6c 69 73 68   /8877115:publish
02c0   65 72 2e 75 74 66 2d 38 34 3a 69 65 31 32 65 00   er.utf-84:ie12e.
02d0   00 00 59 a4 00 00 49 a2 d8 ce c6 25 0d ff 2e e9   ..Y...I....%....
02e0   29 cd 47 34 b8 20 3b 34 fe 06 50 11 ca 97 22 ee   ).G4. ;4..P...".
02f0   b9 23 7b b7 a3 78 fc 49 fa 00 15 35 e6 d2 eb 11   .#{..x.I...5....
0300   a4 b2 2e 03 44 9f 06 18 e5 19 33 04 9f 63 8b ae   ....D.....3..c..
0310   08 4d f0 f7 88 6d 96 e5 a6 c1 d9 c9 65 af 27 b0   .M...m......e.'.
0320   1f 18 77 10 6a 96 9b e2 35 34 00 37 00 00 00 5d   ..w.j...54.7...]
0330   a2 00 00 00 00 00 00 00 1c 2d 42 43 30 32 30 34   .........-BC0204
0340   2d 5a 4e 3a 8b 0d 14 89 fc df 6e 49 92 00 00 00   -ZN:......nI....
0350   00 17 70 00 00 2d 42 43 30 31 39 38 2d 2b 8d f4   ..p..-BC0198-+..
0360   4a 1c d4 0e 6e 95 fb 28 b1 31 d5 e4 c4 5b 9f 1c   J...n..(.1...[..
0370   00 2d 42 43 30 32 30 33 2d f2 74 a2 ec c1 96 c9   .-BC0203-.t.....
0380   08 f5 a4 e5 28 01 af 3d 24 31 19 1c 00 00 00 00   ....(..=$1......
0390   79 a2 00 00 00 00 00 00 00 1c 2d 42 43 30 32 30   y.........-BC020
03a0   34 2d 5a 4e 3a 8b 0d 14 89 fc df 6e 49 92 00 00   4-ZN:......nI...
03b0   00 00 17 70 00 00 2d 42 43 30 31 39 38 2d 2b 8d   ...p..-BC0198-+.
03c0   f4 4a 1c d4 0e 6e 95 fb 28 b1 31 d5 e4 c4 5b 9f   .J...n..(.1...[.
03d0   1c 00 2d 42 43 30 32 30 33 2d f2 74 a2 ec c1 96   ..-BC0203-.t....
03e0   c9 08 f5 a4 e5 28 01 af 3d 24 31 19 1c 00 2d 42   .....(..=$1...-B
03f0   43 30 31 39 38 2d 07 f6 24 56 7a 13 ab 6e 71 b3   C0198-..$Vz..nq.

种子包含非常多的文件夹、文件夹内又包含非常多的文件的情况下,在任务文件列表里找其中的某个文件会很麻烦。
因为添加任务后,这些文件夹是默认展开的,那么要找列表内某个文件夹内的某个文件,就非常困难,进度条非常长,手动挨个折叠文件夹然后去找目标文件夹/文件也很麻烦。
所以可否在档案清单中加个开关之类的,一键折叠全部文件夹;或者添加任务后默认折叠文件夹,而不是默认全部展开?
目前qbit添加任务后是默认折叠的,这样:

算了,右键里就有,不过能默认折叠就更好了。

beta3 已改进

beta3 已改进

测试了一下,未能重现。beta3增加了peer log,可以显示peer之间发送的消息,可以分析一下

你发的是beta3…我下载beta3试试

测试完成
下载方客户端版本不更新,保持现状不变,使用2.03
做种方客户端使用2.04 bate3,现在分块哈希一秒传输上涨大约200,比以前1秒固定传输4个分块来的快多了,基本上可以说0%进度现象不在存在了,并且下载方无需更换版本,只需要做种方升级即可解决

界面小问题
元数据下载过程中无法编辑tracker服务器,只能选中BT任务后右键属性里面去改,下方选项卡中无法编辑

测试过程发现一个比较严重bug
v2种子还有个优势,元数据很小,此时可以直接在未获得分块哈希的情况下,直接通过长效种子下载到文件,但是这个时候数据是虚空的,,,只有下载大小产生,下载进度不会增涨(因为分块哈希还未获取完成)

在v2种子未获取分块哈希完成的时候,我认为不应当触发查询长效tracker,避免产生长效下载流量,以此来避免产生网络ddos现象。此时客户端使用长效下载了几个G的流量,会发现进度依旧是0%。
类似之前的某人的tracker中毒事件,但是这个触发条件比较苛刻,需要v2种子并且分块哈希还未下载完成时可触发

各位测试的时候如果日志提示如下,需要在高级设置中开启 log.bt_peer
2023-10-01 02:55:05 No log found for this peer. (globally disabled)

但是测试后无法获取peer信息,永远是这个提示
2023-10-01 03:01:32 No log found for this peer.

做种方也没有看到任何下载方的分块哈希下载进度,可以观察到下载方正在下载分块哈希期间一直0%,分块哈希传输期间只能看到上传速率

下载方升级到2.04 bate3版本,观察下载方的用户列表,下载方可以看到单个peer的分块哈希下载状态,不过peer日志里依旧是那个提示无法获取peer信息
image
总体来看,,,分块哈希的下载过程依旧很慢,希望还能进一步改善一下速率,理想1w的分块哈希能在1秒内完成

同样无法复现,测试版本2.03,随便制作个v2种子,通过特征码进行下载,qb成功下载到

你这个种子的0%应该是其它原因,因为在peer列表中看不到上传速度,可以看我上面的测试图,在传输分块哈希的时候,会产生上传速度给对方

我进行测试了。这个纯V2种子是上个月用2.03客户端创建的,大小是7.53GB,现在我用2.04最新测试版进行做种,我这里看到的是这样。


image

感谢反馈,下一版修复

感谢反馈,界面开放了此功能,内核忘了启用了,下一版修复

似乎只有在文件非常小的时候才会出现这种问题
确切的说是文件小于16kb的时候
均为纯v2种子

BC2.04做种qb会无法下载
BC2.03下载是正常的


但是反过来 qb做种bc下载却没有问题
似乎只会出现在纯v2下 纯v1和混合种子都没有问题

有没有办法,加强一个功能,在任务属性高级设置中加个选项,不允许外部远程连入

某个BT做种任务不想上传给内网ip的用户,只想上传给公网ip的用户,让公网的人帮忙上传分流

本地客户端收到来自远程连入的用户就拉黑ip 10分钟,拉黑的时间不能太长,因为如果对方客户端发起请求连接到自身客户端,此时虽然对方是公网ip但是本地客户端还是会收到他的远程连入的
或者不要做拉黑ip,只拒绝连接更加科学一些!

已知在设置选项中,关闭端口监听可以达到这个效果,但是只想对某个BT任务起效果,而不是全局所有任务生效

發現下大檔案發現, 網路磁碟寫入過慢, 且下載速度超過 8MB/s , 磁盤寫操作緩衝區會快速飆高, 導致記憶體使用不足崩潰…

建議可否多一組參數, 控制緩衝到 2G 自動調控任務下載速度, 消化完再提升速度…

另外一個無法理解是PC有啟用 smb3 多通道, 透過三網卡可跑 3G, 實際測試寫入可以達 200MB/s, 為何彗星下載速度超過 8MB/s 以上就吃不消?

目前暫時解決方法, 就是該任務限速就不會產生磁碟操作緩衝… @@"

这种700GB大文件下载并且连接的人数比较多的话,建议给多一些磁盘缓存,2G肯定不够的,这会导致爆内存后频繁读写磁盘,引起4K随机寻址导致速率变慢。硬盘速度一旦变慢了,就会引起写入变慢然后就积累在磁盘写缓存区中了,2.04版本会增加一个通知提示,不过目前没有在右下角的操作中心弹出不够明显,等待下一版改进界面

右下角那個小鈴鐺通知有什麼用的?

能否在无人值守的情况下修改BC的监听端口?

正在尝试通过STUN开通端口的自动化
由于BT需要向Tracker提交监听端口,因此STUN得到的公网端口需要在BT软件中应用才起到意义
这操作可以由用户手动完成,但STUN的公网端口会意外变更,实际应用中需要用户值守
若能通过脚本等方式实现自动化,可用性能大幅提升

目前在OpenWrt下已经实现前置步骤的自动化,可以获得公网端口并进行映射
已尝试通过SMB修改BitComet.xml中的<ListenPort>,但需要重启程序才生效
有方法在不退出正在运行的进程的前提下反映BitComet.xml的配置吗?
又或者有其他思路能达到这个目的?
我注意到目前的WebUI可以通过浏览器(JavaScript?)实时修改下载和上传速度,或者能通过它来修改监听端口

又或者添加一个高级设置,强制一定的间隔读取BitComet.xml中的配置
除了STUN的自动化之外,应该还有别的场景下能用到

目前版本可以通过hosts设置http tracker域名的ip为127.0.0.1,然后使用kangle来监听tracker所用的端口,使用url_rewrite模块操作来实现修改汇报端口
这样就能实现客户端端口号不变的情况下,通知tracker其他的端口号

例子

^(.*)&port=(.*)$

直接修改比特彗星的xml理论上也可以,可以让官方加一个命令行参数,例如 .exe -r来重载配置文件

也许直接加一个 -ListenPort 参数会更简单一些
http://wiki-zh.bitcomet.com/bitcomet命令行

我觉得吧
如果BC能内置STUN,自动检测及汇报NAPT后的公网端口,那么连端口映射都可以免了
只要运营商和路由器能提供NAT1,那么跟公网几乎同等了
内置STUN的话,还可以解决第三方工具只能TCP和UDP二选一的问题

目前BC已经有NAT检测工具,只要在这基础上增加一个保活操作就能变成一个STUN工具
第三方STUN需要把流量转发给应用程序,对操作系统或路由器造成一定的负担
而BC内置STUN的话,流量会发到自身,不需要转发

当检测到外部端口和监听端口一致时,什么都不用做
当检测到外部端口跟监听端口不同时,修改tracker汇报端口为外部端口
这过程中甚至不需要考虑是NAT1还是NAT3,因为NAT3的话无论汇报的是哪个端口都无法接受连接,那么可以乐观地默认本机是NAT1

对于运营商提供NAT1,但是路由器强制NAT3的情况,只需要添加一个常规的映射规则即可突破

即使运营商提供NAT3,对tracker汇报NAPT后的公网端口也有利于BEP055的打洞


关于NAPT导致的监听端口和外部端口不一致的问题,2年前的帖子中也有提过
附有libtorrent的实现方案

要是能在这基础上再优化向tracker汇报的外部端口,内网问题可以最大限度地解决了

可以将现有的 NAT检测工具改造成为stun穿透功能
再加入一个 NAT 层数探测功能
毕竟现在的NAT基本都不止一层
直接的NAT类型检测并不准确

可以用路由追踪来实现
再加上NAT判断功能 毕竟私有地址范围是确定的
可以看看这个:


BEP055应该也可以用于穿透 光猫或者路由器的IPv6防火墙
在IPv6中实现穿透可能会更简单
因为端口不会改变

现在很多家庭宽带已经有了IPv6
但是光猫里的IPv6防火墙很难关闭
即使桥接光猫绕过光猫中的IPv6防火墙
路由器中的IPv6防火墙又是一道坎

现在版本中如果希望充当中继节点协助穿透必须要打开utp吗?


不知道BEP055穿透能不能跨任务
如果可以的话 那就能通过”断头档“来相对稳定的保持用户之间的连接
使用公网用户协商打洞
这样就无需设置服务器充当中继节点

问题的原因找到了
可以复现了

@zhuxiaoying85309 @wxhere15

是种子市场或者种子存档的问题

在种子存档或种子市场中纯v2任务的哈希值似乎存在问题

应该是没有适配v2哈希的长度
导致存储在种子存档或种子市场中
的v2哈希值被截断 当成的v1哈希


但这样竟然能成功添加任务
而且还能连接到其他用户

但是无法下载元数据 更无法正常下载

正常的v2哈希值

0585b27c0d3788dc7c69b29e741c0637c03a096145120182835957a90c4a5aeb

被截断的错误v2哈希值

0585b27c0d3788dc7c69b29e741c0637c03a0961

评论区也是这样的问题
似乎除了核心功能以外的部分都没有适配v2哈希


用你的特征码复现了,持续在下载,但是红X错误,一直提示 Torrent 文件打开失败。

在qb做种,使用qb下载复现了这个小文件无法开始下载的问题,qb下载方与qb做种方两者互相握手后就断开了连接,应该是qb自身的原因。