这倒不用担心 BC以前应该和迅雷一样有不少业务线 但后来都不行了
迅雷可以说是国内下载器的“获胜者” BC现在相当于是变回个人客户端了
网络优化可以看这篇
docker版本是从macos版本移植过来的
有条件还是用Windows版本
可以看一下tracker的日志
站长，又有个新问题，关于长效种子
种子a和种子b里面有文件哈希值一样。
现在某比特彗星用户在种子b里面找到了种子a的文件，它获取到了长效种子。
如果我采用其他客户端，没有长效种子这个功能，自然无法吸取额外流量对吧。
这里有个情况，假设某比特彗星用户下载种子a，吸收了同哈希值文件的非比特用户种子b。在双方下载文件中，比特用户为非比特用户共享了上传流量。但是
当比特用户下载完成同哈希值文件，理论上讲，它的上传策略是为种子a上传，它不会为种子b的同哈希值文件提供流量。
然后我发现了一个客户端有类似的功效BiglyBT。
它的群组合并和长效种子一样，更变态的是它似乎可以解决了这个问题。
它的跨群组配额当你分享一个文件种子a时。种子b，种子c，种子d等等，同一个哈希值文件它都可以提供流量。
至少ai是这么告诉我的
长效种子的单位是文件而不是种子，不管文件包含在任何一个BT种子里都可以正常传输
具体可以看一下wiki的详细实现原理，只要文件是相同那么在任意BT种子都可以正常连接到同一个长效种子，唯一的前提是必须为BT种子，对于PT私有种子会强制禁用此功能
Due to the fact that in LT-Seeding protocol resources are being identified using a hash value that is being calculated per file this means that through LT-Seeding you could even get the same files from peers belonging to another torrent swarm (i.e. a torrent swarm using a .torrent file with a different info-hash than the BitTorrent swarm for which you’re currently being a peer), as long as at least some files of the alternative torrent are identical (on a binary level, thus yielding the same file-hash) to the ones of your current torrent and LT file hashes have been uploaded to the server for those files.
A BitComet client must have an open port! LAN users must make sure they have an open port (i.e. the status light is green).
Note: LT-Seeding is being inactivated automatically (and cannot be enabled) for any task added to the Task List if the torrent is a private one (i.e. it bears the private key in the info dictionary of the .torrent file).
*benefits of comet ID are not available on torrents issued by trackers requiring the “private flag” (i.e. private torrents).
好吧，我算是互联网考古了，这些技术的痛点在于，它们好像都被v2种子取代了，然后，v2种子，很多pt站点都不支持
关键不在于v2种子，而是中心服务器，去中心化很难实现舒适的类长效种子功能。
PT站不支持只是她们没有更新而已…都是私人网络BT 没有急切更新的必要…