想請問訂閱的 IP 過濾器，是否有提供阻擋次數或阻擋比例等相關統計？目前使用上無法明確看出過濾器是否有在運作，因此也難以評估訂閱項目的實際成效或進一步優化設定。
之前抓包看过你的上传，确认都是正常的长效合法下载行为，没有任何吸血现象
如果未来版本支持显示ip，那么你用的pbh一样识别不出来是吸血的，因为下载行为非常正常并不是吸血用户，也是来自全球各地不同的真实ip
一个超冷门老种子一晚上百倍分享率耶，而且一直在持续，肯定就是过量下载了，哪怕往乐观地说也是对方本地校验出了问题在不断下载。
之前老哥你帮忙抓包虽说没找出破绽，但老哥你把那几个IP屏蔽掉，我的长效上传确实安静了一段时间，说明屏蔽IP这种做法本身是可行的。
现在只是想让PBH自动化完成这一步骤而已，PBH本身是支持屏蔽过量下载的，只是彗星没显示出来。
既然存在下载，那么他就不是冷门文件，而是热门文件了
这种抓包屏蔽ip的做法是类似关闭长效种子，禁止对方下载了，对方用300KB/s的速度下载了5MB数据，文件大小为60M，屏蔽后可以防止对方下载到后续55M的文件数据
之前抓包上，并没有看到存在所谓的过量下载和重复下载，一旦下载完成了这个60M的文件，对方就停止了不在发生任何流量，下载者都是世界各地不同的ip地址，而且ip地址也是住宅家庭，并不是代理的ip
你可以让pbh支持一下当前有下载任务的时候启用长效种子用于下载数据，如果只有做种任务则自动关闭长效种子功能，此时不会发生长效上传，当前webui上已有设置接口
或者正如你提议的，可以在专家模式界面上双击这个文件，弹出一个窗口，里面显示当前活动的连接ip
这定时器肯定还有些问题的，不好优化吃CPU的话最好放工作线程吧，反正不知道还有什么在吃主线程
这个PieceManage::check_pending_io 一秒涨好几千，虽然看到总计处理时间耗费的不多，1秒不到。。
先等beta2修好崩溃了看看吧，传输加密解密线程不知道吃多少CPU
tcp丢端口除了cpu多线程静态竞争条件，应该是没用原子计数导致意外出现＜0引起负数的值导致互斥锁
而且和这个设置有关 network.max_connecting_connections ＞ 600的时候就很容易tcp丢包，或者整个tcp端口永久丢失，比如设置大于600的时候，例如800、1000的时候产生tcp丢包
截图现象为tcp丢包，如果是丢tcp端口那么是永远持续性的tcp超时，除非进设置里面换个随机监听端口在换回原来的监听端口才能恢复tcp访问
已经确定不是系统的问题，系统是server2022，也解锁了MaxUserPort为65534，其它程序尝试发tcp请求没有这种tcp丢包和永久丢端口的现象
network.max_connecting_connections 设置 600 的时候就没出现tcp丢包，按照之前的复现方式去测试，也没永久丢失tcp端口的现象了，副作用就是随着运行时间积累越来越多几十万等待发起
软件全选任务停止，批量替换tracker清空等待发起，开启任务就能概率复现
这个更新优先级比较高 这一版修一下这个？关键字匹配下Connection或missmatch 忽略大小写 有的话就立即重新发Transaction请求并且完成这次宣告
或者根据bep15的说明，客户端有效期为1分钟(qbittorrent的做法是每次请求都重新申请)，不太推荐
我更倾向现有的做法永久缓存，除非客户端重启才更新，不然和qb那种做法会导致没必要的udp数据包变多，而且会让tracker服务器一直生成新的id占用服务器内存和性能
现有的做法就是如果服务器重启了 那么id就匹配不上了永久错误，除非比特彗星也同时重启，总之根据回应值判断 如果服务器告诉客户端失效 那么客户端在去重新申请最稳妥
现在应该是永远缓存但是没有任何拒绝判断吧？至少看起来是这样
增加高級選項 bittorrent.transfer_thread_pool，這選項開了之後常常當掉，
我使用的cpu是7950x3d，換成intel的使用者會比較正常嗎?