欢迎下载测试版，尝试新功能。请大家多提反馈意见，感谢各位支持~
1.95 正式版
https://download.bitcomet.com/archive/BitComet_1.95_setup.exe
https://download.bitcomet.com/archive/BitComet_1.95.zip
https://download.bitcomet.com/mac/BitComet_1.95.0.dmg
v1.95 Beta13 [20221012]
界面改进：64位版选项窗口BT磁盘缓存及长效上传缓存上限增加到1TB
界面改进：BT任务用户列表peer状态信息分别显示TCP、uTP、UDP打洞的失败次数
核心改进：高级选项 bittorrent.utp_after_holepunch 设为自动时，先发起uTP连接，失败后再尝试UDP打洞
v1.95 Beta12 [20221011]
界面修正：主窗口关闭按钮设置为最小化到托盘有时会失灵
界面修正：远程下载网页界面显示统计信息不启用多语言及排序
核心修正：UDP打洞失败后没有正确处理
v1.95 Beta11 [20221009]
界面改进：任务停止时移动已下载文件，改为工作线程异步操作
核心修正：BT任务里存在大小相同的文件时，从webseed下载的部分数据未关联到正确的文件，导致数据校验出错
v1.95 Beta10 [20220930]
界面改进：程序启动时，窗口最大化状态有可能没有恢复在上次退出时的显示器上
界面改进：高级设置项 network.max_udp_pkt_per_sec 上限从一万提高到一百万
界面改进：统计列表增加CPU占用率及存储空间信息
界面改进：远程下载网页界面显示完整的统计信息
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市场右键添加到种子分享灰色无法点击
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個讚
能否只显示选定大小，而不是：选定大小(所有文件大小)
感谢反馈
目前是没有请求时每60秒发一次ping-pong，之后60秒超时等待。如果底层TCP连接已失效，最多120秒应该会断开websocket连接。
之前好像说过，ws tracker返回的peer不使用TCP/uTP协议，而是以WebRTC Data Channels做底层传输协议，目前彗星还不支持。参见 https://github.com/yciabaud/webtorrent/blob/beps/bep_webrtc.rst
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
不过还是有问题，速度跑不起来还是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是正常的
