即使这样也不能防止使用正常客户端循环下载吧？
就像之前那个用彗星反复下载的
全自动识别很困难 目前还是只能人工检查
我的建议是这样的
当然也可以搞成qbee那种
在目录下面自己创建文件 写表达式但是感觉不是很方便
只要对方提供上传，就不算是吸血，循环下就循环下吧，，反正他会进行上传，这种时候如果想屏蔽他就得用最原始的方法，ip黑名单
嗯 其在下载阶段确实有上传 但完成后会重新开始
总体上还在消耗其他人的流量 应该屏蔽
说到IP黑名单 我在想是否有必要重新加入内置的IP过滤器
毕竟通过考古发现彗星在远古时期是支持 IP过滤的
现在要过滤的话是依靠外部的防火墙或者流控软件
也许外置的更方便？
内置的话最好支持手动添加和数据库文件 同时应能通过命令重载
其实这套方案还是有一些缺陷的，比如说由于只取64K数据不校验的话，如何判断对方是否发来正确的数据，如果攻击者进行对做种者重复发一个相同的任意数据包那么可以绕过这个验证
包括攻击者伪造进度为0%的时候，做种者是否应当询问下载者要64K的上传数据？因为此时没办法进行判断对方是不是真的0%
大家还有什么对于反吸血更好的建议？还是说我这套已经算是最好的了
脑残的磁盘缓存过大，被限速能不能改一改。我就是机械硬盘了，使用率拉满99都无所谓。问题是我全速下载就给我拉闸是几个意思，不给快速下载咯？迅雷都不带这样的，顶多磁盘占用多了说繁忙，也没见会被限速的。普通的HTTP是这样，BT下载也这样，一超过20麻痹一秒，就动不动磁盘缓存过大拉闸限速
要是以前的旧三星27寸PLS屏，我就这样抄起鼠标键盘飞过去砸了 
可是现在是VESA认证HDR1000 4K MINI-LED显示器，好歹也是四千多 
砸不起了
2.05及历史版本优化方案是自动使用系统剩余内存，在物理内存用尽的时候才进行自动限速，不管内存有多少都可以利用来作为磁盘写缓冲
2.06开始修改了以前的方案，可以让用户自由调整内存用到多少才进行限速，可以在高级设置进行修改，使其更灵活智能化，如果你想取消自动限速，可以通过开关 network.enable_dl_limit_for_large_writing_buffer
如果你想调整和2.05以前那种内存用尽才自动限速，可以调整数值network.large_writing_buffer_enter_size_mb 默认值缓冲区达到200MB内存就进行自动限速，不过最大数值只能设置为1024，达不到2.05那种效果，只能通过开关去禁用自动下载限速
迅雷也有磁盘繁忙后限速的，只是没显示出来通知用户，如果来不及限速迅雷还会提示崩溃就是限速失败了
主要是因为有人反馈内存老是被用满拿去做磁盘写缓冲，然后实际上他用的还是叠瓦盘，，，写入速度只有 100KB - 1MB/s 那种，所以2.06新版针对性做了优化，让其不会使用那么多缓冲内存
感谢解答，但就是不爽这种动不动被限速。HDR60FPS 杜比视界片子，我就往机械盘里下载，几G十几G起步。要是全集电视剧一两百G，要被限速几次下到什么时候
可以先试试限速阈值改成1024，如果觉得还不够满意
就把开关关掉，这时候就和2.05及以前版本一样了，直接下进内存写缓冲里
拿苹果手机固件试了，
还是被限速58麻痹一秒
限速开关 关了 直接千兆拉满 115麻痹一秒 真好
主要现在的限速策略是检测当前速率的一半，不像迅雷是5%逐步阶梯来限速，一半直接砍掉50%，所以120MB/s变成60MB/s，迅雷是120MB/s变成114MB/s这样逐步降低，限速的感知就没那么强
问题已确认：如果设置启动时窗口为最小化状态，但程序上次退出时窗口为最大化状态，则未能正常恢复收藏夹边栏大小。beta2已修复
1個讚
beta2已发布
问个问题:
为啥要 封禁客户端 ?
BitComet 有 积分等级,
反正 1 天 上传 100 GB 管它是谁 下载.
可否加个选项,
上传 xxx GB 就停止 上传,
例如 105 GB.
这个匹配的是显示出来的客户端名吗？
对，最少6位字符，例如ittorr 可以屏蔽qb，大小写要正确，测试没有忽略大小写
但这要求彗星可以显示出它的客户端名吧？
像这种整个就剩n/a就不行了吧？
建议添加对 MonoTorrent 客户端名称显示的支持 目前只能显示为n/a
其ID为 MO
以及biglybt 目前可以正确显示名称和版本但后面带有n/a
应该是没有被添加到已知客户端列表内
其ID为BI
可参考这个项目对已知客户端列表进行扩展
当然这个列表也不是很全
》 bittorrent-peerid/index.js at master · webtorrent/bittorrent-peerid · GitHub
以前的选项都保留的，可以同时客户端名称和peerid搭配使用
显示n/a是对方没有汇报自己的客户端名称，比如qb启用了匿名模式后，由于设置匿名后不进行汇报客户端名称也会显示为n/a
这种情况大概率是通过peerid信息进行猜测来显示，而不是对方汇报的结果
对方有peer ID 汇报 MO3000 经过查询属于MonoTorrent
客户端名称是另外汇报的吗？
我觉得显示n/a应该表示其不在已知的客户端内
biglybt 确实使用BI作为客户端ID
而且在BEP20中明确列出的一些peerID和客户端名称的对应关系
其中就包括这个 MonoTorrent