We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
我们应该给反复下载相同文件的IP段限速,而不是封掉就完了。 现在已经有peer id为bitcomet 2.04的反复下载客户端了,这怎么封?而且在你下载文件时,这些客户端也会给你数据的,封掉这些客户端对大家是有负面影响的。这不是简单的吸血行为。 所以统计IP段下载量,超过合理值(比如文件大小的1倍或者数倍)就给这个IP段限速是更好的方案。这也能避免这个IP段下的正常客户端被一棍子打死。而且按照这些客户端现在的工作逻辑,如果同一IP段下有正常客户端,这个正常客户端完全可以通过这些客户端的狂野流量迅速下载完毕。
No response
The text was updated successfully, but these errors were encountered:
我的详细发现放在discussion里了,但是好像没人看: #548
Sorry, something went wrong.
你去查一下那些IP就知道原因了,都是各种网盘的数据中心的离线下载. 占满我的上行带宽反复下载同一个文件这一点就够恶意的了,我就给封了这些垃圾客户端.
而且在你下载文件时,这些客户端也会给你数据的
经过观察,这些客户端似乎是直接把下载的数据丢弃掉,甚至都不会有保存的动作,何来给别的客户端上传这一说?
No branches or pull requests
Suggestion
我们应该给反复下载相同文件的IP段限速,而不是封掉就完了。
现在已经有peer id为bitcomet 2.04的反复下载客户端了,这怎么封?而且在你下载文件时,这些客户端也会给你数据的,封掉这些客户端对大家是有负面影响的。这不是简单的吸血行为。
所以统计IP段下载量,超过合理值(比如文件大小的1倍或者数倍)就给这个IP段限速是更好的方案。这也能避免这个IP段下的正常客户端被一棍子打死。而且按照这些客户端现在的工作逻辑,如果同一IP段下有正常客户端,这个正常客户端完全可以通过这些客户端的狂野流量迅速下载完毕。
Use case
No response
Extra info/examples/attachments
No response
The text was updated successfully, but these errors were encountered: