qBittorrent-Enhanced-Edition
qBittorrent-Enhanced-Edition copied to clipboard
c0re100
希望能動態屏蔽 比特彗星 BitComet
qBittorrent version and Operating System
qBittorrent Enhanced Edition 4.1.6 x64 on Windows 10（10.0.18362.53 / X64）
What is the problem
希望能動態屏蔽 比特彗星 BitComet
What is the expected behavior
實現動態屏蔽 比特彗星 BitComet
Extra info(if any)
BitComet - 比特彗星于0.93版引入了“長效種子”機制，用戶啓用此功能后，在 BC 自身服務存活的情況下，其客戶端就會上傳數據塊給其它 BC 客戶端(無論分享率是否已達到或超過用戶預設值)。 從表面上看有效的延長了種子的存活期，短期内(分享率未達到程序或用戶預設值的情況下)，可能會分享給其它客戶端，但是從長期看，分享率到達或超過預設值后，並不分享給其它客戶端，反而擠占了本該用於分享給 DHT 網絡上其它 BT 客戶端的帶寬，違背了 BT 的公平性原則，這點上和迅雷(Xunlei)類似，從 DHT 網絡中吸血，卻未有效反哺 DHT 網絡。 通過長時間的觀察，在給 BC 客戶端傳送一小塊數據時，其回報的進度增長速率通常情況下都高於主流 BT 客戶端的增長速率，很明顯可以看出 BC 客戶端具有很强的吸血能力(大概率是受益于其自身的“長效種子”機制)。 其它一些關於比特彗星的爭議： https://i58.tw/?p=2985
现在许多资源发布者都在用 BC，如果想迫使用户放弃或作者改变，就应该在所有主流 BT 客户端去推动。 如果 qB 屏蔽了，qBEE 自然就跟进了。
既然許多資源都用 BC 發佈，那就沒辦法了。
BC 是在对 BT 整体上传后如果还有上行网络空余（即没有跑满上传或上传限速上限），则会 用剩下的网络进行长效种子上传。 而且 长效种子 功能是可手动关闭的，同时只有设备拥有 公网IP 的情况下，才能实现长效种子上传，这在中国很稀少。。。 准确的说，吸血的定义是只下载不上传(或非常少)，迅雷才是当之无愧的吸血~
谁也無法知道BC是否會故意限制種子任务分享給其它BT客户端的上傳速度和连接数，從而擠出部分带宽和连接数給長效種子使用；另外無法否認的一點是，長效種子占用了本該用於分配發起新链接的连接数，而這些连接数在沒有長效種子機制的情况下，本應該屬於全體BT客户端，而不是BC客户端獨占，并且在连接沒有被釋放的情况下，这些连接数也失去了分配給其它BT客户端的機會。所以長效種子機制是存在一定吸血性質的。
@Zerorigin 看到你这个回复，我就知道 你根本没有对比特彗星的 长效种子 机制详细的了解分析过。
我在接触 比特彗星 后，见到一些人说 长效种子 吸血，为此我特地观察了一段时间研究了下。
首先 长效种子 是可以关闭的，但因为只有比特彗星支持，所以被一些 没了解过就下定论的人认为比特彗星和迅雷一样，都只上传给自己的用户 ，然而实际上是：
- 当你平常做种时，比特彗星会优先对BT任务整体上传，如果还有空余上传速度（例如没多少用户需要你上传，上传速度跑不上去，或者你对任务限速），才会开始长效种子上传。
需要打开长效种子的「自动控制上传限速」功能，这样比特彗星才会根据上传速度的空余自动调整长效种子上传限速数值。
- 当你的任务满足做种条件停止后（例如分享率到达 300% 停止做种），比特彗星依然会持续做种（长效种子），因为长效种子只有比特彗星支持，所以也只提供给比特彗星用户。
用户主动停止做种，或者任务满足做种条件停止，都属于用户主动放弃继续对 BT 整体上传。
总结：
只有在有上传速度存在空余，或你主动停止任务做种后 （包括满足你设定的停止条件，这相当于用户主动放弃继续对 BT 整体上传），比特彗星才会对其他比特彗星用户做种上传。 而且你不想继续做种也可以关闭长效种子功能。
也就是说，比特彗星的长效种子功能，完全是在满足 BT 整体上传的前提下，充分利用剩余上传速度，提高种子存活率。
如果你觉得我说的是假的，那么请去实地使用比特彗星并详细了解 长效种子 机制后，拿出证据反驳我，而不要全靠臆想和猜测，否则我根本没兴趣继续和你辩论，因为我从不和无理取闹的人讲道理。
而迅雷呢，无论你怎么设置，它都强制做种上传给其他迅雷用户。
我只希望大家能理智且严谨的研究讨论，而不要一味的跟风。
看來你對我的觀點有點誤解，因此有必要跟你說明下，“恰恰相反，你说的這些我都了解过。”
另外你似乎完全忽略了我闡述的兩點，特別是第二點關於连接数的你完全没談及，所以我可以認為你不知道连接数機制？
還有，我並不是來罵架的，如果你認為我不理性，那我也不多說了。
- 第一点： 【谁也無法知道？？？】既然你不知道，那就代表没证据，那不就是猜测的么？
- 第二点： 连接数的确会被占用，但是连接数上限足够高（例如我设置的 9999），不可能跑满上限（但会因为电脑性能出现瓶颈），可能我的上传速度不够快，观察不到你猜测的情况。
我的上传速度大部分情况下都能跑满，而这时候长效种子只占用了 0-100KB/s 上传速度，剩下的都是 BT 整体上传，你是否真实检测过比特彗星在限速长效种子后是否正确释放长效种子连接数？还是说依靠猜测？
你说的连接数我不否定，但是你说的【很明顯可以看出 BC 客戶端具有很强的吸血能力】我不认同。
你在1楼发的一段话，可不像是 【“恰恰相反，你说的這些我都了解过。”】
例如：【分享率到達或超過預設值后，並不分享給其它客戶端，反而擠占了本該用於分享給 DHT 網絡上其它 BT 客戶端的帶寬，違背了 BT 的公平性原則】
分享率达到用户设置的停止条件时，代表用户主动放弃了对 BT 整体的做种上传，和长效种子本身无关，如果用户打开了长效种子，那么就进行长效种子做种，如果关闭了，则不会进行任何做种上传行为。这是用户主导的，而不是软件强制的。
例如：【這點上和迅雷(Xunlei)類似，從 DHT 網絡中吸血，卻未有效反哺 DHT 網絡。】
迅雷和比特彗星长效种子的区别我前面的回答讲的很清楚了，我也不重复了，差别很大。
更多的我就不一一反驳了，没意思，比特彗星又不是我写的，哪怕我辩论赢了又能得到什么呢？什么都得不到。反而浪费时间。🙄
我平时也懒得和别人网上辩论，因为大部分情况下都是不欢而散。我只是碰巧看到你这个帖子曲解了长效种子才有感而发，回复几次就有点无趣了。
哈哈，我也不認同我说的 BC 具有很強的吸血性，不过長效種子卻是具有吸血的特性。
另外，连接数受營運商限制，虽然没有9999那麼高，但至少也會有八九百以上。正常情況下，只要不像迅雷那樣惡意占用，確實吃不滿。
不过要是家裡智能設備不少，多設備流媒體和下载同時進行卻時有可能占满。
另外關於连接数占用，在连接数達到软件设置或宽带上限時，如果部分還處於被長效種子用於上傳的狀態，此时就没辦法發起新的上傳通道給非 BC 客户端，这對其它 BT 客户端有點不公平，因为這些通道本本來是全體 BT 客户端共享的，而不是 BC 客户端獨享的。
还屏蔽bc，看来对长效种子一点都不了解。只有在任务停止，其它客户端完全无法获得数据的情况下，长效种子才真正发挥作用，确保种子存活。如果没有长效种子，这个种子就断种了。唯一的问题是bc可能形成垄断地位，解决的办法应该是其它客户端也开发自己的长效种子。至于说bc吸血，我就呵呵了
还屏蔽bc，看来对长效种子一点都不了解。只有在任务停止，其它客户端完全无法获得数据的情况下，长效种子才真正发挥作用，确保种子存活。如果没有长效种子，这个种子就断种了。唯一的问题是bc可能形成垄断地位，解决的办法应该是其它客户端也开发自己的长效种子。至于说bc吸血，我就呵呵了
别自以为别人意见和你相左就是不了解（有可能是你自己理解没别人透彻，呵呵） 长效种子和迅雷只自己的P2SP是一个性质的，吸血就是吸血，别在那边洗了 BT 断种是一开始设计上就存在的缺陷 只要长效种子不是一个公有协议，此机制无法对其它客户端产生互利效应就都是在吸血 从别的客户端获取资源也是消耗了本来应该共享给别人的共享率 像你怎么想，相当于鼓励人人都用迅雷，呵呵
那我也发表一下我的意见吧 首先什么是吸血。如果只下载，不上传，类似于迅雷，那是吸血。如果有人做种，那么bc和其他客户端是一样上传下载的，因为此时长效种子不传输，就和没有这个功能一样。 如果在断种的情况下(此时没有人做种了，以后也没有人做种了)，新加入的用户通过长效种子下载了文件，那他完成后也会通过dht分享给其他客户端，除非他限制了客户端种类与分享率。长效种子设计之初就是为了解决这种情况。 既然通过长效种子下载后也通过dht分享给了其他客户端，怎么能说没有互利效应了。 其次，长效种子不算入分享率，只有在断种时才传输，而且种子的分享率不变，用过软件都知道 作为bt软件，bc既上传了文件给别的客户端，为什么不能从别的客户端下载？为什么要说它占用了别人的分享率，难道它不消耗自己的分享率，上传给其他客户端吗？而且长效种子不占用分享率。 最后，bt断种和p2p协议缺陷没有必然联系。p2p本身就是点对点共享，如果没人做种了，必然断种。相反，长效种子部分解决了这种问题。 你可以对我的观点进行反驳，但要有理有据。你这么抵制bc，你也可以下一个用了试试，我感觉你没有用过bc，不然也不会说出bc占用别人分享率这样的话。
我突然想到一个问题，你可能误会了一个东西，bc不只上传数据给bc,也会分享数据给utorrent,transmission等，我说的"其他客户端"不是指bc，而是指除了bc的其他bt下载软件。 但现实中bc用的人太多，所以你会感觉怎么连接的全是bc，这个我亲自试过，你可以用热门种子试一下，肯定会分享给其他客户端。 至于为什么大部分是bc,现实就是大部分人用bc,或者bc优先分享给bc,但我不认为这是吸血。 只要bc有人做种，所有客户端都能下到数据。
有种专门的称呼叫“社区加分/吸血”，虽然这个功能非常好，但是它是一个私有的功能，如果没法惠及其它客户端，实质上就是一种社区吸血。那么，所谓必然断种也就不必然，长效种子的便利会导致使用者不再积极主动做种，不会觉得自己在吸血。
如果在断种的情况下(此时没有人做种了，以后也没有人做种了)，新加入的用户通过长效种子下载了文件，那他完成后也会通过dht分享给其他客户端，除非他限制了客户端种类与分享率。长效种子设计之初就是为了解决这种情况。
所以关键就在于长效种子功能本身是否真的会传给其它客户端，我没用过没有发言权。
那我也发表一下我的意见吧 首先什么是吸血。如果只下载，不上传，类似于迅雷，那是吸血。如果有人做种，那么bc和其他客户端是一样上传下载的，因为此时长效种子不传输，就和没有这个功能一样。 如果在断种的情况下(此时没有人做种了，以后也没有人做种了)，新加入的用户通过长效种子下载了文件，那他完成后也会通过dht分享给其他客户端，除非他限制了客户端种类与分享率。长效种子设计之初就是为了解决这种情况。 既然通过长效种子下载后也通过dht分享给了其他客户端，怎么能说没有互利效应了。 其次，长效种子不算入分享率，只有在断种时才传输，而且种子的分享率不变，用过软件都知道 作为bt软件，bc既上传了文件给别的客户端，为什么不能从别的客户端下载？为什么要说它占用了别人的分享率，难道它不消耗自己的分享率，上传给其他客户端吗？而且长效种子不占用分享率。 最后，bt断种和p2p协议缺陷没有必然联系。p2p本身就是点对点共享，如果没人做种了，必然断种。相反，长效种子部分解决了这种问题。 你可以对我的观点进行反驳，但要有理有据。你这么抵制bc，你也可以下一个用了试试，我感觉你没有用过bc，不然也不会说出bc占用别人分享率这样的话。
具有吸血性质的客户端我都不用，并且能屏蔽都是尽量屏蔽，多说无益。 吸血的定义并不是你这样定义的，迅雷部分版本也会传给自己的同伴客户端的同时上传部分块给其它客户端。 照你这样定义它也不算吸血，长效种子只在自己的社区客户端里上传，而不是共享给整个 DHT 网络，就是吸血。
我突然想到一个问题，你可能误会了一个东西，bc不只上传数据给bc,也会分享数据给utorrent,transmission等，我说的"其他客户端"不是指bc，而是指除了bc的其他bt下载软件。 但现实中bc用的人太多，所以你会感觉怎么连接的全是bc，这个我亲自试过，你可以用热门种子试一下，肯定会分享给其他客户端。 至于为什么大部分是bc,现实就是大部分人用bc,或者bc优先分享给bc,但我不认为这是吸血。 只要bc有人做种，所有客户端都能下到数据。
还有你下载的时候会传数据给非BC客户端，并不是长效的缘故，而是本身公共共享率未达到设定的分享率 只要分享率达到预设值，那 BC 和正常的客户端一样都会停止对外做种 但是再 BC 双方都开启长效种子的情况下，就算停止做种了 由于长效种子的机制，数据还是会在 BC 自己的客户端社区里互传(社区吸血)
这么说吧，未来我发布BC版本更新时候，默认值则主动屏蔽qBittorrent-Enhanced-Edition？
并且能屏蔽都是尽量屏蔽，多说无益。
这样qbee就不会连接到BC的用户，BC也就不会被qbee进行吸血，否者用户列表会看见好些qbee的用户只下载不进行上传，或者下完就跑，各位怎么看？
等 uTorrent 被你们屏蔽的那天到来。
@1265578519 请问这是承认有吸血？如没有吸血行为，建议你去 wiki 百科更正澄清。
@SeaHOH 是的，没错，qbee确实有吸血行为
@SeaHOH 他在别的论坛上发布一些自己修改的客户端。不过这不重要，任君屏蔽。
我觉得关键在于，其实不必只用数据传输角度的度量“吸血”来评估这个功能是否恰当。在我看来，长效种子本身最大的问题就在推进BitComet这个非自由软件的垄断。
我本人是不会去装这种非开源BT软件的。我也很讨厌看到有一些种子打开来告诉我“如果你看到此文件，请用BitComet客户端打开这个种子。”这样的话。我觉得制作这种不通用的种子、与长效种子功能一样，就算不违反分享精神不“吸血”，也是违反BT的自由、分享精神中的“自由”的。（后续查了一下，这个功能似乎是为了BC自己做的种子还能在eMule网络中下载，不过大多eMule的反吸血mod都屏蔽了BC。这部分也只对BC自己有用，对其他客户端使用者确实是干扰。并且我不看好BitComet给这类文件附上的明显具有推广意味的解释字串。
所以，我首先假设前文中各个BitComet的使用&支持者们对长效种子的描述属实。那么如果有一个种子，所有客户端用户在已完成后都停止了上传，那确实是断种了。但现在如果有已完成该种子的BitComet客户端用户启用了长效种子功能，那么新来的下载者不用BitComet客户端便无法下载这个种子。
可是这样，对于一个原本可以自由选择喜爱的BT客户端、十分希望下载该种子的用户，他如何才能知道有没有可能能从长效种子这个功能的设置中受益并下载这个种子呢？他不知道，他只能下载安装这个不自由的客户端，进行尝试。
不论他尝试的结果是能够下载还是不能，这种逻辑还是会导致的BitComet的装机量增加。而最大受益者还是BitComet背后的组织，并非BT社区。
也许有人会说类似GPL的传播式开源不够自由。不过我觉得怎么也比装上一个我完全信不过看不到的客户端要来的舒服。至少我们的隐私和安全可以得到保证，有能力者也可以修改代码自定义（就像qbee的开发一样）。
我不知道为什么前面有人如此卖力的吹捧、维护一个闭源软件中明显不和BT精神中的“自由”沾边的功能。我觉得大家应该都是聪明人，应该都能想到我这种头脑不灵光的人所疑惑的这一层。难道真的是有利益相关吗？
其实qbee太可不必犹豫，屏蔽BitComet是早有的事了。 https://zh.wikipedia.org/wiki/BitComet#%E8%B6%85%E7%B4%9A%E7%A8%AE%E5%AD%90 https://zh.wikipedia.org/wiki/BitComet#%E2%80%9CeMule%E6%8F%92%E4%BB%B6%E2%80%9D
@escape0707 https://github.com/bittorrent/bittorrent.org 你去把长效种子申请为bep标准化 Long-Term Seeding bep Standards ，这样libtorrent 就会根据协议规范开发进行支持。 https://github.com/arvidn/libtorrent 然后使用libtorrent套壳的GUI qbittorrent自然也会支持。 这样你就不会眼馋 bitcomet 的长效种子功能了。 也可以使用开源软件来进行长效种子，这样你也可以不必使用非开源软件，只要作为bep协议开发标准，其它BT开源软件，都会更新支持，你也就可以自由选择其它客户端使用体验上这个功能。
还有人吐槽制作种子后添加的 这个后缀文件 _____padding_file，在来解答下吧
比特彗星他还会给种子文件里面加奇怪的东西。不太能理解 他要做什么
反正对不使用这个软件的 只会看到一对垃圾 体验不好
这是区块对齐功能，支持bep47 BT协议规范的客户端都会加这个，比如说qbit 4.2最新版已经支持
如果看到这些文件那只是客户端不支持客户端比较垃圾
可以去找出现问题的客户端作者去更新支持BT协议
qb也能看到 比特彗星 特有的文件
QB的话4.2最新版已经支持了，升级到最新版即可
qb我用老的，新的更新感觉很奇怪，下载没那么快
老版本那就没法了，QB新版本制作种子，也会添加这些文件的都一样
我以前做种子都是ut，因为qb乱序给我，比特彗星又是＋文件
我说的是 用比特彗星 制作种子后添加的 这个后缀文件 _____padding_file
就是这个啊，区块对齐，制作的时候默认勾选的，可选取消，这是BT协议标准
https://www.bittorrent.org/beps/bep_0047.html
BT协议BEP47规范中的填充文件padding属性（qBittorrent v4.2.0版本起已更新支持边界对齐BEP47规范）
qb最新版本制作种子的时候，一样会添加这些文件
这协议是提高下载速度和性能并且解决卡99%进度问题用的
那感谢你提醒 下次使用旧的qb版本制作种子，这种文件很又矮观瞻
QB也是可选的，制作种子的时候有个区块对齐，取消，就不会有这些文件生成了
好吧我知道了 下次取消，因为做种的不知道所以√了
这功能，开着是最好的，可以有效提高性能，你硬盘就不会卡100%了
反正刚接触是什么都用过，99%从新校验一下基本也能完事，视频文件99%绝对是能看的
无法解决的，你用网盘，下载完成一个视频文件，导入BT客户端卡99%
就是因为没有启用这个BT区块对齐协议引起的问题，尾部的区块丢失了两个文件相邻
https://tieba.baidu.com/p/5761869240
网上很多类似的一搜就知道了，或者自己尝试下
相邻文件丢失 这个我有感
明明a是 99% 却导致 b文件 头丢掉，b文件是完整的
对的，，这就是BT种子制作的时候没有开启区块对齐就会引起这个毛病
因为下载A文件的时候，需要从B文件获取一个头来填充完整的一个区块
开了区块对齐，会有一个隐藏的填00空文件进行填充这样不会涉及到B文件
ut是不是默认种子对齐还是没有，只有新的客户端支持?
我理解他的拼接切割在哈希 这种远离
据我所知UT还不支持这个BT协议，目前已知支持的有比特彗星，QBIT和迅雷
transmission也是不支持的，其他的客户端我没测试了，什么毒蛙这些，我没安装过
那有没有优点这个功能，有没有什么缺点
这协议优点是提高下载速度和性能并且解决卡99%进度问题用的
缺点就是不支持的客户端会显示 制作种子后添加的 这个后缀文件 _____padding_file
迅雷基本上做种的都屏蔽了，这个优点对小白来说好，其实我还是不喜欢看到这种文件
反正不知道大家为什么反感迅雷吸血
根据上方介绍，BT协议BEP47规范中的填充文件padding属性（qBittorrent v4.2.0版本起已更新支持边界对齐BEP47规范） 你用qBittorrent v4.2.0制作生成种子文件，也会产生“如果你看到此文件，请用BitComet客户端打开这个种子。”这种文件在种子中 而不是你自行猜测的
为了BC自己做的种子还能在eMule网络中下载，不过大多eMule的反吸血mod都屏蔽了BC。这部分也只对BC自己有用，对其他客户端使用者确实是干扰。
关于这点，也就是上方所说的，你可以去提交bep标准，让其支持即可，libtorrent根据bep标准开发完毕后，qbittorrent后续就会更新支持该功能。
对于一个原本可以自由选择喜爱的BT客户端、十分希望下载该种子的用户，他如何才能知道有没有可能能从长效种子这个功能的设置中受益并下载这个种子呢？他不知道，他只能下载安装这个不自由的客户端，进行尝试。
这也就是我为什么让你去申请bep的原因，GPL开源软件任何人都可以参与bep协议规范开发，只要有人迈出这一步
不论他尝试的结果是能够下载还是不能，这种逻辑还是会导致的BitComet的装机量增加。而最大受益者还是BitComet背后的组织，并非BT社区。
也许有人会说类似GPL的传播式开源不够自由。不过我觉得怎么也比装上一个我完全信不过看不到的客户端要来的舒服。至少我们的隐私和安全可以得到保证，有能力者也可以修改代码自定义（就像qbee的开发一样）。
他在别的论坛上发布一些自己修改的客户端。
哦，开 itzmx 的那个。公开发布私改软件属于引流行为，对方较真点可以告他，保准败诉赔钱。有些发布还在用 BC 可能也是受他影响，这点太操蛋。还有，Mac 那么多客户端不推荐，居然公开教唆别人用渣雷。这么个人怎么好意思来这里叫嚣威胁，面皮之厚实，我不及也。
bep 标准申请需要完整的资料，他根本拿不出来，还喊你去申请，笑死我了。 :rofl:
