我正在考虑将bittorrent用于大数据传播问题，其中数据源是千万亿次级，用户需要高达数TB的数据。一些细节
我预计活动种子的数量与可用总量相比较小，但服务质量很重要，因此每个种子必须有几个播种机或一些启动新播种机的机制。
我的问题是，bittorrent客户可以处理播种大量的种子，其中大部分都是空闲的吗？我是否需要在群集中的种子上划分种子，或者每个节点是否可以播种它可以访问的所有种子？哪个客户会做得最好？是否有用于管理播种群集的工具？
我假设跟踪器可以扩展到这个级别。
答案 0 :(得分：4)
有两个主要问题：
至于跟踪器流量，让我们假设您有100万个种子，典型的重新宣布间隔是30分钟，但有些跟踪器将其设置为1小时。让我们保守一点，假设你的跟踪器使用1小时的通知间隔。你必须每小时发出100万个GET请求，假设每个请求是400字节向上和100字节向下（假设大多数响应不包含任何对等体），那就是大约111 kB / s向上和28 kB / s不断下降。这并不是那么糟糕，但请记住，TCP需要额外的往返来建立连接，因此另外40个字节向下，40个字节向上。
只需使用UDP trackers即可减轻这种情况。然后，您只需要一条连接消息，并且可以为每个通告重用连接ID。然后每个通告消息将是100个字节，并且返回的消息也将更紧凑，假设60个字节。这样可以让你获得28 kB / s和16kB / s的速度，只是为了防止洪流宣布。为此，您需要一个具有良好udp跟踪器支持的客户端（例如，缓存连接ID的客户端）。
还不错，假设与种子发送的实际数据相比无关紧要。
但是，您不一定需要在不同的数据中心划分种子，也可以使用HTTP服务器为种子播种。所有主要的bittorrent客户端都支持http播种，你不必担心向跟踪器宣布（URL被刻录到.torrent本身）。
对于能够与种子进行良好扩展的客户，我不确定，我还没有做过任何测量。只生成一百万个随机种子并尝试加载它应该是相当简单的。
我已经在libtorrent rasterbar做了一些优化工作，以使其适应许多种子，但我没有尝试过数百万次。
我写了一篇关于这个主题的博文here。
答案 1 :(得分：3)
您可能正在寻找Hekate 它现在充其量只是pre-alpha，但它几乎就是你所描述的。
答案 2 :(得分：1)
为了不在无用的跟踪器宣布和数百万的擦除（以及每个通知间隔中）的开销下崩溃，您必须限制您的种子集群仅加载当前请求的当前工作项目集。无论如何，下载程序需要从中心位置获取（下载）.torrent文件，这可能会触发将其加载到种子集群中。或者，通过识别不是来自您的一个种子群集的通知来确定特定信息哈希的活动。
rTorrent具有快速恢复功能（意味着在加载适当准备的.torrent时不会发生散列），并且可以通过xmlrpc进行控制，因此您可以停用空闲项目。这样，.torrent下载可以触发实际数据在接下来的24小时内可用，或者只要群中有活动即可。
答案 3 :(得分：0)
协议允许这样做，但我不知道哪些客户端会扩展到数百万个种子。在最坏的情况下，您必须编写自己的种子客户端。
与您的用例最相关的协议功能是，当对等体连接到另一个时，连接对等体应该首先发送torrent的info-hash。这意味着可以使用单个侦听TCP端口来播种无限量的种子，闲置时几乎不使用任何资源。
可在The BitTorrent Protocol Specification上找到：
如果双方都没有发送相同的值，则会切断连接。一个可能的例外是，如果下载者希望通过单个端口进行多次下载，他们可能会等待传入连接首先提供下载哈希，如果它在列表中，则回复相同的连接。
我也在Bittorrent Protocol Specification v1.0上找到了相同的内容：
连接的发起者应该立即发送他们的握手。如果接收方能够同时为多个种子提供服务，则可以等待发起方的握手（种子由其info_hash唯一标识）。
然而，有一件事会增加你的负担，而且它是跟踪器。使用普通的跟踪器协议，每个客户端必须定期向跟踪器通告它拥有的每个torrent，以及它上传了多少信息。有数百万个种子，这将带来一些高负荷。如果您正在编写自己的仅限种子的客户端，那么向跟踪器宣布您的播种机的单独协议将是一个好主意。