还有个读取超标的问题，单peer下没问题，多个peer同时后就出问题了
磁力分载点： magnet:?xt=urn:btih:WHMM5THERNWGPII3PTACR5ZWCCZVMPM4&xt=urn:btmh:1220c551586deef5a225490aa8fd72fdf0f1ebbab0f9cdfc300d49df85084416e0a5&dn=BitComet%20V2.21%20Beta8%20%5B20260607%5D
下一版移过去
8MB是每个UDP socket的。下一版我加个选项你可以调整一下看看有没有效果
下一版改成utp黑名单直接回rst
目前的发起连接代码做了限制，下一版我优化一下。
另外除了 network.max_connecting_connections 控制全部TCP连接发起数量上限，
http tracker有专门的设置项 network.max_connecting_connections_per_tracker，默认是6，可以改大一点试试。
此外还有 network.start_connect_interval_ms，默认是 10，可以改小一点试试。
好的，后续优化
既然做了，播放上面的复制就不用删了，文件列表上再新加一个就行了
webui流量图也忘记更新了
和tcp一样或者其它软件一样，统一回fin比较好吧？reset重置包由于不是关闭连接，重置包比较多跨国传输也容易被gfw防火墙盯上吧
这些我都优化过了的，发起间隔0ms，tracker和正在发起都是设置10000
可以优化一下，比如取值设置的一半，等待发起每次移动过去5000个比较合理，而不是20到200个
@tttttony 你那怎么样？
运行了一天
tcp端口还没出现过永久丢失现象
但是高延迟偶尔丢包还存在
beta8更新到現在，300~500個任務同時運作沒有出現連接埠封鎖的現象了，但不能打開bitcomet的介面，只能縮到右下角，不然連線速度會降的很低，縮小沒幾秒，網路速度就升到90%以上
那看来beta8的更新是有效的，应该解决TCP永久丢失端口问题了，在观察三天看看
我倒是没出现掉速度的问题，昨天说的那个内存压缩设置你改了试过了吗
就是多peer这个读盘比上传大，要等后续版本优化了，或者不知道你是不是触发磁盘瓶颈降速
記憶體壓縮已關閉
且記憶體使用量還沒達到設定的使用上限
我的硬碟應該是不可能觸發瓶頸
陣列卡:Adaptec SmartRAID Ultra 3258P-32i /e
硬碟:181TB的RAID6+7TB nvme cache
先看看流量图，切换到逻辑处理器，是不是主线程的cpu吃满了？
尝试开启beta的选项 bittorrent.transfer_thread_pool
也可以开专家模式高级设置 system.enable_expert_mode
消息队列和定时器中，这个值不是0ms就代表界面正在卡顿，下面是函数执行耗时，要是确定函数卡了的话，发出来给开发者看看能不能优化
如果看到是on_read_queue_finished占用很高的话，这个应该就是我上面提到多个peer连接情况下读取超标的问题，那要等后续优化了
又出現端口封鎖了Orz，但機率比之前低很多了
Beta9已发布，欢迎试用
1個讚
效果巨好！现在启动任务后大概1分钟就可以清理完成等待队列了，以前要等好几十分钟
效果很明显！现在多peer上传时，内存缓存用尽后，磁盘读取正常了
感觉没效果，，，算了就这样吧，Windows下没找到类似查看确认方法
Linux可以用这个命令查看进程socket缓存用尽引起的UdpRcvbufErrors丢包，UdpSndbufErrors则基本取决于CPU性能
cat /proc/net/snmp | grep -E ‘^Udp:’ | column -t
watch -n 1 “nstat -az | grep -E ‘UdpRcvbufErrors|UdpSndbufErrors’”
查看进程缓存大小
ss -tunlp -m
r 当前使用的接收缓存
rb 当前接收缓存上限值
t 当前使用的发送缓存
tb 当前发送缓存上限值
f 分配的内存页面数量
提升进程socket缓存可以解决RcvbufErrors，他不会在上涨了
工作不正常，限量是指？抓包看到依旧回的state包
哦，用户列表中手动封禁peer不正常，在设置窗口里，单独使用ip过滤器就可以了
等于说因为双方是种子 或者是其它类似的原因封禁那么这个rst就不起效果
既然改成RESET了，那tcp这里应该还能提前一下？tcp现在是发完fin才回的rst，在syn的时候就可以直接rst了
哦，我想了下用户列表手动封禁5分钟不生效的情况，所以不能发syn直接拉黑，因为syn里面没有info_hash字段，没办法判断是哪个种子，因为存在客户端有运行多个任务的情况
那其它原因产生的封禁方式就保持现状就好了
唯一要改的就是，在设置窗口ip过滤器中封禁后，tcp的 rst,ack 包还要提前一点，这样就不需要psh传输数据了，就是建立之前就回rst，而不是建立时才封禁
webui和长效种子同上，处理下tcp的情况，在syn就可以回rst
长效udp直接回个rst包？不然不知道是丢包了还是被上传方封禁了，可以直接用utp的包结构，只要不破坏客户端下载方后续阶段重试长效下载请求就可以了
手动永久封禁自动添加到ip过滤器后，最上方有一个空行不太美观
感觉可以发正式版了，虽然UTP速度还不够极限比不上qbittorrent，但是至少比之前版本快了几百倍了，可能要多开几个UTP线程才能更快了
或者你还有办法找到原因优化吗，qbittorrent是只有一个主线程，UTP啥都在主线程里，但是随便能到60MB/s
彗星beta UTP有4个工作线程分摊，每个线程吃80%左右但是30MB/s
是不是rtt延迟降速的原因啊？之前说把延迟改成1000ms你改了吗
还是说network.udp_socket_buffer_size_mb 接收缓存大小没有起到效果，不知道怎么看进程用的多少MB
磁力分载点： magnet:?xt=urn:btih:3X34YHYKKYKLSQ5OYVPDBSZUNQPEDMR2&xt=urn:btmh:1220aaefd12f33f7a6f1e9ce2093dfbc34c41132bb0574c36ea5196ceb62695ced3e&dn=BitComet%20V2.21%20Beta9%20%5B20260610%5D
限量是指per-IP rate limit，因为 UDP 源 IP 可伪造，无脑回包会变成 reflection 放大攻击工具。
好的，可以改一下，TCP三次握手后就发rst，不发FIN
好的，长效udp和utp协议不兼容，下一版回复一个长效udp自己的拒绝连接403包
感谢反馈，下一版已修复
高级选项中的 system.check_bcagent 检查浏览器插件的OCX控件状态
这个应该检查的应该是IE浏览器中的 ActiveX 控件吧？
现在IE浏览器的集成已经去掉了 这个选项应该也可以删除了
这个英文一眼懂了，之前说限量感觉很奇怪没看懂，你这个单词中文翻译出bug了
试了下还有个问题，大量peer的时候，内存缓存没用尽，未达到设定目标也会超读取，不知道是不是缓存120秒过期太短了，取消勾选"在最大最小值范围内自动调整缓存大小"，让他实现标记缓存超时但是不立即删除，确实有点点作用
还是说引入一下超级种子类似的机制？超级种子现在是优先上传未拥有的稀缺分块。
优化一下优先上传已缓存的分块？好像这样也不太好，因为可能会引发永远不上传未缓存的分块
消息队列on_read_queue_finished 平均在6ms，不知道能不能优化到0ms
现在的UTP PEX NAT1打洞还能不能增强优化下？总之就是强化AB反向回连
现在的NAT1打洞需要至少3台设备，在B直接连接到A后，B能不能同时通过PEX发送自己NAT1打洞后的ip端口地址给A？
现在只有A发给B和A发给C，然后C知道了B的ip地址后成功连接到B
也就是加强一下AB互相NAT1打洞的能力，现在只有比特彗星作为A的时候，才能够覆盖原始peer的端口信息去重连回B
其它种子客户端因为并不具备NAT1打洞能力，假设qbittorrent充当A身份的时候，A因为peer列表中不存在B的ip地址信息，A无法回连到B
虽然通过DHT网络可以直接把真实的NAT1打洞后端口通过implied_port广播出去，但是自己和他人并不一定会同时开启DHT网络，还是需要PEX更好一些
也就是实现B拿到A通过PEX返回的ip和端口信息后，再把这个端口信息加入自己作为B的pex列表，把新列表通过pex回给A
在假设A不是比特彗星的情况，如果A是qbittorrent的话，A并不会pex回真实端口给B，B就不知道自己的真实ip和NAT1后端口了
或者通过服务器检查或者其它方式拿到真实端口，直接加入自身pex分享出去，这样就能兼容所有客户端去PEX NAT1打洞
当前版本的实现
```````````````````````````分割线`````````````````````````````
成功打洞的前提，需要设备C能连接上设备B
测试NAT1打洞需要至少3台设备，测试环境如下
做种服务器A
防火墙开放TCP端口，做种客户端设置为UTP启用
下载服务器B
B服务器在路由器中封堵TCP端口，NAT值为1
一样设置为UTP启用，执行下载，此时服务器A可以看到一个来源为被动的服务器B请求。
下载服务器C
C服务器在路由器中封堵TCP端口，NAT值为4
设置UTP启用，执行下载，测试是否与服务器B连接成功
```````````````````````````分割线`````````````````````````````
比特彗星NAT1打洞主要为以下两个方面
核心改进：添加对DHT协议里的implied_port 参数支持，以增强对透过NAT网络进行uTP传输的支持
核心改进：通过PEX发送peer列表时，对已连接的uTP peer提供其UDP外网端口，而不采用其本地监听端口
AB反向回连
核心改进：发起uTP连接时，优先使用之前连入过的远程端口（可以实现AB互相打洞，A为公网，B为NAT1的情况，B异常原因断开连接后A可以直接回连到B，而不需要傻傻的等待B后续远程连入到A）
```````````````````````````分割线`````````````````````````````
```````````````````````````回复不能超过3次的分割线`````````````````````````````
总之UTP传输，比特彗星beta版和qbittorrent当前还是差距了一到两倍左右速度，唯一看出区别的是cwnd比较小
network.udp_socket_buffer_size_mb的设置值已经是64M并且重启了进程，总感觉是被什么东西降速了，你找一下是不是延迟原因？我怀疑就是没改成1000延迟引起拥塞主动降速导致UTP速度慢
MTU是本地发送对方的显示，后面那一串是接收到对方的显示
那么代表比特彗星作为上传方的时候，发送过来到下载方的cwnd特别小，所以导致了传输速度比qbittorrent慢