[Feature Request] Banning those who always download but never upload

[RuikangSun]

Suggestion

Some strange peers alway download but never upload. there client seems normal ( like μtorrent instead of XunLei ).

Is it possible to specially limit upload rate for those who never upload? And, for a better P2P ecosystem, shall we ban those IPs?

Use case

No response

Extra info/examples/attachments

No response

[sjlleo]

Some clients (like qbittorrent) can set maxium number of upload slots. If their clients are in the max upload slots with this torrent, other clients connect with it (include you) will not get any data from these peers. Maybe their uploading will be available for you soon after theirs have free upload slots.

In the screenshot, though this peer seems not upload any data to you, it still cannot totally prove that this peer is a leecher.

[SeaHOH]

In the screenshot, though this peer seems not upload any data to you, it still cannot totally prove that this peer is a leecher.

In this case, even it is a normal peer, ban it does not undermine the P2P network.

[pinyangcong]

兄啊，你连客户端名字和peerID都不截出来，你要我们怎么解决问题

[sjlleo]

兄啊，你连客户端名字和peerID都不截出来，你要我们怎么解决问题

估计大概率是μtorrent，我遇到过很多μtorrent是只从我这里下载但是不给上传的。后来我去了解了一下，这个软件设计的时候默认就是从所有的客户端拿数据，但是上传最多只给几个客户端，剩下的客户端就不给上传了，因此很多客户端等同于被吸血了，这会让给μtorrent上传的人很不爽（毕竟自己什么数据都没从这拿到）。这个之前应该就有人说过这个问题，如果μtorrent能改成只要对方给数据就都给予一定的上传就不会有这些非议了。

[SeaHOH]

这现象不限于特定客户端，分两种情况：

一是客户端默认上传策略不合理，但并不违背 P2P 精神，因为它是有贡献的，只不过可能会被吸血以致贡献无效。不过 μTorrent 用户太多，确实应该改进。问题是你们知道现在其 boss 是谁吧，μTorrent 的立场只是个引流工具，开发维护的重点不再是普通用户需要的 P2P 分享。人家员工也是拿工资的，不会干可能吃力不讨好的私活，FIRE WARNING。

二是用户设置吸血，其实大多数客户端都可以这么设置，只是 μTorrent 用户更多设置更简便。这种应该打击，虽然顺带可能会打击到前一种，但并不会损害整体网络，都是有益的。

[pinyangcong]

@sjlleo 剩下的客户端不上传？是按照客户端名字匹配的吗

[SeaHOH]

他这里的客户端是指特定用户，而非特定客户端软件。说的是下载时上传过于集中，不过做种时情况会有改变。

[RuikangSun]

兄啊，你连客户端名字和peerID都不截出来，你要我们怎么解决问题

因为这似乎是一个普遍现象，此处是μtorrent，但不只有μtorrent，Transmission之类的客户端都似乎有这种情况

[RuikangSun]

能否设定一种逻辑，来一定程度上惩罚（例如限制对他们的上传速度）这些只下载不上传的节点？我想了一下，从道德层面应该是可行的：从趋利避害关系上讲，拥有这种惩罚措施的节点对该用户无害，还能惩罚只上传不下载的节点，改善生态，间接对该用户有利。从实际应用角度讲，即使是因为网络连通等客观问题无法提供上传的节点，尽管对他们存在速度惩罚，但只要节点多，这种影响并不大。

[pinyangcong]

能否设定一种逻辑，来一定程度上惩罚（例如限制对他们的上传速度）这些只下载不上传的节点？我想了一下，从道德层面应该是可行的：从趋利避害关系上讲，拥有这种惩罚措施的节点对该用户无害，还能惩罚只上传不下载的节点，改善生态，间接对该用户有利。从实际应用角度讲，即使是因为网络连通等客观问题无法提供上传的节点，尽管对他们存在速度惩罚，但只要节点多，这种影响并不大。

高级设置里的上传连接策略改成“反吸血”试试？

[SeaHOH]

即使是因为网络连通等客观问题无法提供上传的节点，尽管对他们存在速度惩罚

连通性问题是双边的，应该不存在这种超级不对等的网络。这种超低比例 (甚至零) 上传就是恰好没轮到，或者是故意，反正怎么惩罚都可以。

有些渣雷鸡贼得很，会第一时间给你传几百 K 或 1M 多点，然后就再也没有了。

[sjlleo]

我同意 @SeaHOH 的观点，不管是客观因素（如有些电信、联通宽带的上行速率依旧只有4Mbps、电信163炸到起飞的国际互联）还是主观因素（用户在软件BT策略上偏向违反P2P精神的设置）导致的事实上的吸血，都应该给予一定的惩罚，因为我们也无法分辨这些因素，在我们看来这些Peer都违反了P2P的“人人为我，我为人人”的共享精神。

关于惩罚的问题我觉得最好的办法还是看分享率，刚刚握手的时候给予一定的时间的考察期（比如30秒），考察期内视作对方为一个正常的Pee。考察期过后计算对方上传/我方上传的比值，不应该低于一个分享期望值（如0.5），这个值可以由用户自行设定。一旦低于了这个值，可以由用户自行选择屏蔽IP/对该Peer大幅度限制上传速度，直到分享率达到期望值再放开限制。

关于客户端的问题：

根据我之前下载/做种的经验，迅雷是否吸血也看版本，只有迅雷7/极速版的几个版本是不吸血的，但是考虑到迅雷用户大多丝毫不关心P2P网络存亡——从搜索引擎上搜索如何关闭上传就可以看出来，所以一并屏蔽了是最好的。

Transmission用户设置吸血的非常常见，还有很多吸血下载软件也会伪装Transmission的UA让自己看起来是一个正常的Peer。

[SeaHOH]

关于超低分享率的问题，owner 明确表示过不会管，用户可以调用 Web API 来自行采取任意策略。

零分享的忘记他是否说过，我个人认为完全可以作为内置策略，实现也不复杂。

渣雷的话，最好能反吸血，给整体 P2P 找补。

我前年倒是写过一个针对 μTorrent 3 的工具就采取了这些策略 (刚看了下居然还有一百多的月下载)，但最后实在受不了 μTorrent 本身老 bug 不修新 bug 不断，转 Tixati 了 (新版 qB 在我机器上老是崩溃)。再之前是坚守 μTorrent 2，如果不是有分块 bug 我都不想换，可惜后来卖给人渣，搞得大家用不爽。

[RuikangSun]

最近跑了好几天的Bittorrent，怀疑是软件策略的原因，我发现使用一些软件（例如BitSpirit）的节点，即使是完成度大于自己，也只是自己上传几MB而使用自己几GB的流量。能否设计一种第三方算法来对这种情况进行限制呢？似乎现在也没有现成的相对公正的策略可用。

主要是我的编程算法基础太菜了TAT，只是个普通用户，要不然我大概会选择某种限制那些只吸血不分享的节点。

[KevinMX]

连通性问题是双边的，应该不存在这种超级不对等的网络。这种超低比例 (甚至零) 上传就是恰好没轮到，或者是故意，反正怎么惩罚都可以。

Hi :)

[SeaHOH]

@KevinMX 如果要较真的话，你展示的是带宽问题，和连通性扯不着。但是无所谓了，其实不管任何原因造成上传量极不对等，都可以执行惩罚而不会对整体网络造成损害，比如你展示的这种。

[sjlleo]

@KevinMX 如果要较真的话，你展示的是带宽问题，和连通性扯不着。但是无所谓了，其实不管任何原因造成上传量极不对等，都可以执行惩罚而不会对整体网络造成损害，比如你展示的这种。

这种情况换做是我的话可能会去主动限制下载速度，以和现有的上传速度匹配。毕竟P2P分享精神就在那里，虽然不是故意这么设置的，但是它仍会造成一种吸血行为，这是事实。它被Ban在对于社区来看同样也是有利的，毕竟没有那么多上传宽带，也就不应该获得远多于自己上传宽带的下载宽带。