明确反对
本来反吸血功能就是相互的，我的客户端监测对方，对方也会监测我的
对方又不一定开启反吸血，甚至对方的客户端都不一定有反吸血这个功能，以同等标准对待自己，很合理，如果自己都做不到，又何必去苛求别人。
注意，我是说反吸血要能把自己反了，没有说强制反自己吸血，如果觉得自己必须在无法进行上传的情况下进行下载，那把反吸血功能关了不就得了。各人有各人的选择。
热门、评分、截图都有类似的bug，下一版修复
确实还没有，考虑放到全局统计里
彗星如果判断某客户端满足反吸血条件，就会断开连接，并在24小时内禁止连接，不存在单方面吸血的可能。但由于BT协议里没有电驴协议里类似的排队等候信息，所以如果对方上传session数达到自己算法计算出的上限，一直没有unchoke自己的话，可能会被误杀。
感谢建议，后续版本添加
我是远程连接电脑版用的，，，全局里面怎么能统计到远程
还有排序和搜索也加一个
好的，感谢建议
上面我说的这种多线程方案好做吗？应该不用大改构造吧
感谢反馈，新版已修复。这个文件路径长度恰好处于临界区间，代码有bug
主线程卡是因为有些操作不容易转移到工作线程，做线程同步的话对历史代码的修改量会很大，容易出bug。之前的任务异步停止也改得挺辛苦的。网络连接本身不太占CPU，处理收到的数据需要在同一个线程，比较占CPU，由于历史原因都集中在主线程。
网络应该吃CPU的吧，，上传1MB/s和上传10MB/s占用的CPU使用率就不一样。。。而且主要是做种上传，应该接收数据不多
如果能做成我说的那样，，，应该是最理想的多线程方案（我怎么感觉开发难度不大来着。。。判断新连接产生直接分配到线程ID就行了例如01234567一共8个线程ID，陆续分配下去就可以了，其它负载算法可以以后在优化，现在可以做顺序式分配）
beta 2 已发布
这个上传速度变化引起的CPU占用率变化，等回头有空profile一下，看看如何优化
比特彗星 无法通过第三方客户端pikpak 下载任务，虽然成功显示任务但是下载速度0.
之前还好好的，pikpak也提示和比特彗星连接成功，但是任务进度0
你看看你最近还能从pikpak下载成功吗，是不是pikpak屏蔽比特彗星了
目前IDM aria2还能接管任务下载
希望种子市场添加"不接收发布日期小于自定义的[年-月-日 时:分:秒]种子"的功能,
因为bt的特性,时间越早坏种几率越高
无发布日期的可视为unix起始时间戳或交给用户选择是否过滤
APP几个地方大小显示不一致
用户列表里也没有等待连接和封禁连接显示 只有正在连接
速度小B显示也可以废弃了。。。最小KB即可
排序等待中 默认好像是最新添加的任务在最下方，500个任务滚到死滚屏半天。。。
十三代英特尔开始主板都标配2.5G 10G板载双网卡了 为了应付大于1Gbps的传输是要优化了
哪里的消息？我去瞧一眼