1.95测试版

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

v1.95 Beta10 [20220930]
界面改进:程序启动时,窗口最大化状态有可能没有恢复在上次退出时的显示器上
界面改进:高级设置项 network.max_udp_pkt_per_sec 上限从一万提高到一百万
界面改进:统计列表增加CPU占用率及存储空间信息
界面改进:远程下载网页界面显示完整的统计信息

https://download.bitcomet.com/beta/BitCometBeta_20220930_setup.exe
https://download.bitcomet.com/beta/BitCometBeta_20220930.zip

v1.95 Beta9 [20220924]
核心修正:私有种子不启用PEX的情况下进行UDP打洞

v1.95 Beta8 [20220922]
界面改进:流量图可显示的数据增加长效上传CPU占用率
核心修正:BT任务连接Peer后尽快发送PEX报文
核心修正:改进websocket tracker停止时的错误处理

v1.95 Beta7 [20220920]
核心改进:新增高级选项,bittorrent.private_torrent_peer_hole_punch 允许私有种子不启用PEX的情况下进行UDP打洞
核心改进:BT任务连接Peer后尽快发送PEX报文
核心修正:改进websocket tracker停止时的错误处理

v1.95 Beta6 [20220919]
界面修正:beta5版BT任务peer列表远程端口显示有误
核心修正:BT任务停止时websocket tracker断开超时处理

v1.95 Beta5 [20220918]
核心改进:发起uTP连接时,优先使用之前连入过的远程端口
核心修正:BT任务停止时websocket tracker断开超时处理

v1.95 Beta4 [20220917]
界面修正:RSS源更新数据后,已修改的名称会恢复原始名称

v1.95 Beta3 [20220916]
核心修正:websocket超时断开处理

v1.95 Beta2 [20220915]
界面改进:开启专家模式后,BT任务用户列表显示uTP MTU大小
核心改进:uTP建立连接后自动调整MTU大小

v1.95 Beta1 [20220914]
界面改进:RSS列表添加右键菜单项:重命名
界面改进:增强选项窗口里的RSS自动下载过滤器,可设置每个RSS源的名称及对应的任务标签
核心修正:websocket超时断开处理

已经更新了

这么快出新版了。。。还以为能在1.94优化好utp

1個讚

种子市场删除某些种子后仍收到其他用户分享的以删除内容
RSS种子获取不到评分热门等信息
RSS种子获取不到发布时间及文件大小,但实际是有的

<title>
[Tsundere-Raws] One Piece - 1004.5 VOSTFR (CR) [WEB 1080p x264 AAC].mp4
</title>
<link>https://nyaa.si/download/1578602.torrent</link>
<guid isPermaLink="true">https://nyaa.si/view/1578602</guid>
<pubDate>Wed, 14 Sep 2022 14:25:54 -0000</pubDate>
<nyaa:seeders>0</nyaa:seeders>
<nyaa:leechers>0</nyaa:leechers>
<nyaa:downloads>0</nyaa:downloads>
<nyaa:infoHash>54c5c8be351941fbb1369d0754c68bf136bb4ae3</nyaa:infoHash>
<nyaa:categoryId>1_3</nyaa:categoryId>
<nyaa:category>Anime - Non-English-translated</nyaa:category>
<nyaa:size>1.4 GiB</nyaa:size>

RSS市场右键添加到种子分享灰色无法点击

版本号刷的快不够用了,,,就要2.00版本了


20220914版本实测没修复。。

而且依旧解析不出peer,两台机器使用同一个tracker,响应peer为0,这个要不要考虑做一下获取peer。。。不然感觉连上ws tracker也没多大用处

好快啊~最近彗星更新越来越快了~

经常新建rss后,,,显示不完整,点刷新按钮也没用,必须重启比特彗星

感觉目前比较重要的问题
同时启动几百个BT/PT做种上传任务的时候无速度,统计里展开TCP连接显示元数据下载卡顿超久的问题。
WS tracker超时问题
UTP包太小,提高包大小来优化传输速率
上版本说的AB两者PEX交互优化NAT1打洞(可用于私有种子交互自身UDP远程端口),在私有种子下不知道和第三者C交互PEX用于打洞符合私有种子协议规范吗?如果不行那就做AB两者吧,如果符合PT规范的话,那能做ABC三者到私有种子中。能做到ABC三者来说,,,就更好了,这样PT下也可以用NAT1打洞了
上个版本说了,,,这个抄一下PEX响应自身IPV4/IPV6地址的代码,,实现应该不难吧。毕竟现有版本已经可以在BT种子下借助第三者实现打洞了。

1個讚

能否只显示选定大小,而不是:选定大小(所有文件大小)
2022-09-15 07.59.01

感谢反馈

目前是没有请求时每60秒发一次ping-pong,之后60秒超时等待。如果底层TCP连接已失效,最多120秒应该会断开websocket连接。

之前好像说过,ws tracker返回的peer不使用TCP/uTP协议,而是以WebRTC Data Channels做底层传输协议,目前彗星还不支持。参见 webtorrent/bep_webrtc.rst at beps · yciabaud/webtorrent · GitHub

beta2 已改进

改是能改,不过麻烦确认一下是每次都这样,还是新任务首次启动会这样?

不是很明白你说的算法。一开始如果不存在C,A和B即使知道对方外网IP:port直接发起uTP连接,由于缺少第三者协助打洞,一般都无法建立连接;如果存在C,A和B都连上C后,可通过C的PEX可以获取A、B对方的外网IP:port,再加上C的打洞协助,自然就可以完成打洞了。再来看打洞成功后A和B的uTP连接意外中断的情况,他们自身都会立即尝试重连,但往往因为NAT打洞已失效而无法重连成功。这种情况下虽然A、B都已知道对方外网IP:port,但还是需要C的协助来重新打洞,因为有了C的协调A、B可以同时向对方发起打洞连接,这样才能打洞成功。

PEX交换自身IPV4/IPV6地址后建立的双连接不需要打洞操作,所以A、B自己就能完成,无需第三方C参与。

是觉得显示内容太多不好看吗?可是如果只显示选定大小,容易造成误导

没看出来有超时,全都是连不上的,然后卡在TCP连接里面。如下图

举个例子,,A是公网映射型做种,B是NAT1型,B可以在不借助C的情况下直接连接到A,然后因为没有AB两者PEX,导致A拿不到B的NAT1后的端口号就无法回连了,这样说一个例子,能明白了吗,因为A本身就是公网,可以充当C的身份,也就无需要第三者了,A需要PEX直接拿到B的ip端口才可以回连。
还有这套A、B两者PEX交互等你实现后,能同时做到PT私有种子里支持?便于打洞。。目前PT种子里是拿不到任何UTP发起为远程连接的请求,PT里能同时也ABC三者互相PEX交互就更好了。。算了先别管PT了,先把BT的AB两者PEX弄成功在说。

要的就是A、B建立连接成功后,,同时返回PEX一个自身ip + NAT1打洞后的远程端口给对方,而不是全部的peer用户列表。
所以我觉得现有的这个功能加强一下,就能实现。

确认了,每次都是这样,任务列表所有任务都是做种任务。只要停止任务后,在开始,就会显示元数据下载。

重命名后,更新rss源会导致又被覆盖回去。

实测有效,效果很不错,需要做种方升级为1.95 beta2版本,要是做种方为旧版本则不起效果还是为548的小包传输
下载方测试可以是任意版本的比特彗星。

不过下载接收方显示的MTU不准,,做种上传方的才准,抓包值为1457,可能这个地方显示的是本地对他人peer上传时候使用的MTU,那么双方显示不一致是正确的现象,可以改善语言界面一下,显示成 本地上传MTU = xxxx

5

不过还是有问题,速度跑不起来还是100多KB/s,调整到1457后最大的肉眼可见的改善就是UTP线程占用的CPU降低了。
统计里面观察都跑不到1000pkt,,感觉发的utp包不够激进,有没有办法在提高发包速率?

两台服务器用网络调试软件模拟UTP包重发,mtu设置548,测试30Mbps发送,接收方可以获取到30Mbps,可以确认不存在运营商QOS,应该是软件发的UTP包不够激进。

模拟测试200Mbps,也是正常的,CPU占用不高

而且UTP包能不能移出每秒UDP限制外面,不然做种几百个任务的时候容易引起UDP队列发送导致引起内存泄漏…或者弄个和DHT那样,达到限制后对外发出去的包就丢弃掉。因为看这个截图来说,mtu为548的情况,得需要5W的包才能承受200Mbps的速率。

mtu为1457的情况,只需要1.7W的包就能承受200Mbps的速率,UTP线程的CPU也降低到了1.5%。

1Gbps网卡承受能力为16W pps,等于说mtu为1457的情况200Mbps=1.7W,1000Mbps=8.5W,使用utp搓搓有余了。
等你下一个版本。。。改善下这个UTP上传不起来的情况。。感觉有点像前几年的tcp socket缓冲区一样的毛病,1.51版本优化过tcp socket缓冲区大小,估计也有个udp socket缓冲区吧
TCP是能跑200Mbps的。。虽然也还跑不满1Gbps,不知道是不是tcp缓冲区还是小了点。

目前版本 network.max_udp_pkt_per_sec 最大值10000,,,为了高速上传可能要改成100000,主要不知道上传UTP时候CPU占用情况怎么样,要等下一个版本出来后测试下才知道。因为比特彗星仅支持CPU单线程!不像网络调试工具,是可以利用所有CPU核心的。看来我前几个版本说的那个最完美的多线程方案还是太难实现了。。。

http下载似乎有点问题,上次还可以下www.mediafire.com的

图片


同样的代理火狐就正常下载,彗星一直正在连接
而且也能获取到档案大小还支持续传
理论来说获取到档案大小应该就不用cookie了,但以防万一,我开了个隐私窗口打开下载链接也是正常下载的,所以应该还是彗星的问题

我清空了代理的日志,停止任务重新启动还是没有日志显示,但是看属性会有日志(会请求获取文件大小),因此这个问题应该是由于连接没有走代理导致的
但是我设置确实勾选了使用代理进行http下载

手动新建http下载
https://down.sandai.net/thunder11/XunLeiWebSetup11.3.14.1952gw.exe


也只有查询文件大小的代理日志,一直正在连接

HTTP代理下载测试正常,看你截图被标记direct了,可能是这个问题,你确认一下?

2022/09/16 17:09:37 tcp:127.0.0.1:57967 accepted tcp:down.sandai.net:443 [proxy] 
2022/09/16 17:09:37 tcp:127.0.0.1:57968 accepted tcp:down.sandai.net:443 [proxy] 
2022/09/16 17:09:37 tcp:127.0.0.1:57969 accepted tcp:down.sandai.net:443 [proxy] 
2022/09/16 17:09:37 tcp:127.0.0.1:57973 accepted tcp:down.sandai.net:443 [proxy] 
2022/09/16 17:09:37 tcp:127.0.0.1:57975 accepted tcp:down.sandai.net:443 [proxy] 
2022/09/16 17:09:37 tcp:127.0.0.1:57977 accepted tcp:down.sandai.net:443 [proxy] 
2022/09/16 17:09:37 tcp:127.0.0.1:57979 accepted tcp:down.sandai.net:443 [proxy] 
2022/09/16 17:09:38 tcp:127.0.0.1:57981 accepted tcp:down.sandai.net:443 [proxy] 
2022/09/16 17:09:38 tcp:127.0.0.1:57983 accepted tcp:down.sandai.net:443 [proxy] 

就是,,,这个框这里怎么前面是空白的?

这个是迅雷官网复制的下载链接,direct(直连)是应该的,另外这个是查询大小出的日志


可能是你socks5代理软件的问题,你检查一下吧,我这使用v2是正常的
image

我也是v2呀,你能看到日志吗?下载有没有走v2?

图片
每次退出,都要维持这个状态很长时间


不知道在干什么
然后就
图片
错误报告以发送