不排除那个使用hp吸血的人，后续真的去伪造成其它客户端的标识符，因为改动这个没有什么难度
1個讚
比特彗星多台rss种子服务器互相同步BT种子任务列表数据实现CDN分布式做种上传，多个ip地址加速用户下载速度
https://bbs.itzmx.com/thread-103471-1-1.html
那位大佬应该用的就是这样
测试结果出来了
确实有上传 而且有长效种子 应该是正常的彗星客户端
在上传状态下 对方 进度也是满的 （both finished ）
其可能只是在多台服务器上运行这比特彗星
至于之前截图中所呈现的类似吸血的状态可能是因为其尚未完成首次下载
当然也可能是开启了超级种子
说起来这些吸血的还有个特征，就是随机汇报进度然后断开
是不是可以根据IP连接时长以及进度记录判断是不是吸血，比如短时间内重复连接断开，以及新进度小于历史进度
这确实非常巧妙
通过一个客户端作为主控器 开放任务列表为RSS源其他客户端添加RSS订阅
即可实现同步添加任务 一个添加各个同步
不过删除任务不知道是怎么实现的
但目前不能确定但是否在使用这个方法
也许可以通过端口查看其是否有RSS共享
但这么多IP和端口寻找起来并不容易
已经有项目实现了基于上传量的检测
即检测给一个客户的上传量是否超过了种子本身的大小
经过进一步的观察确认其存在循环现在的现象
应该可以被认为是一种滥用行为
不过有趣的是由于使用的是正常的彗星客户端 所以其在下载阶段是有上传的
其下载速度较快（若其真实的汇报了下载速度和任务进度）
仅在截图的过程中就完成了一轮循环
基本可以确定其存在循环下载的滥用行为
至于之前观察中发现的完成后上传的阶段 可能是由于其自动循环下载设置不完善造成的
目前已发现滥用比特彗星进行循环下载的IP段
223.78.79.0/24
223.78.80.0/24
2409:873c:f03:6000::/56
使用 18550 和 15685 端口
建议在Windows防火墙中屏蔽该地址段或通过下列网址查询其正在下载的任务
以避免浪费上传量
并且GitHub仓库不是说启用UseBasicAuth嘛
下的是哪个版本？
是的
不过我倒是建议优先使用彗星自己的反吸血
1個讚
最新的3.3b6
能不能直接发一个config.json给我研究一下
，感觉给bitcomet配置比给qbee麻烦
重点是自带的peerid屏蔽不支持正则表达式，也不支持屏蔽fdm那种不符合peerid规范的peerid，客户端列表也是直接一刀切，不允许输入自定义clientid来屏蔽
没什么好研究的，下面都是默认的没动，我目前也不用这个反吸血…
我只是好奇那个 execCommand_*命令怎么用
本来是要进行测试的
用于拦截那些伪装成比特彗星的客户端
但之后确认那些IP段上的是正常的比特彗星 只是被滥用 用于刷流
而且防火墙规则我也没研究好 就这样搁置下来了