bittorrent 对等节点能否处理播种大量空闲种子

Posted 2023-02-23

【中文标题】bittorrent 对等节点能否处理播种大量空闲种子

【英文标题】：Can bittorrent peers handle seeding large numbers of idle torrents

【发布时间】：2011-07-24 20:50:20

【问题描述】：

我正在考虑使用 bittorrent 来解决数据源为 PB 级且用户需要高达数 TB 的大型数据传播问题。一些细节

可能数百万的种子数 种子大小范围从 100Mb 到 100Gb 世界各地的一组稳定的集群能够充当播种机，每个集群都拥有总种子的很大一部分（平均说 60%） 希望下载平均数 TB 数据的同时用户数量相对较少（少于 100 个）。

我希望与可用种子总数相比，活动种子的数量很少，但服务质量很重要，因此每个种子必须有几个种子或启动新种子的某种机制。

我的问题是，bittorrent 客户端能否处理大量种子种子，其中大部分是空闲的？我是否需要在集群中的播种机上对种子进行条带化，或者每个节点是否可以播种它可以访问的所有种子？哪个客户会做得最好？有没有管理播种机集群的工具？

我假设跟踪器可以扩展到这个级别。

【参考方案1】：

有两个主要问题：

每个种子（通常）都需要定期向跟踪器宣布，这最终可能会占用大量带宽。 bittorrent 客户端本身需要以一种可扩展大量种子的方式编写

至于跟踪器流量，假设您有 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。

【讨论】：

Arvid 在此处发布了更多关于 libtorrent 的调优技巧：libtorrent.org/tuning.html 可以对其他客户端进行类似的优化。

【参考方案2】：

您可能正在寻找Hekate 它现在充其量是pre-alpha，但它几乎就是你所描述的。

【讨论】：

如果您正在寻找也可以扩展到该级别的跟踪器软件，那么您正在寻找opentracker，这是海盗湾在关闭所有跟踪器之前曾经运行的。有了这两件事，您在分发数据时应该没有什么大问题。

赫卡特似乎死了。太糟糕了——这个想法非常好。

【参考方案3】：

为了不因数百万次无用的跟踪器宣布和刮擦（以及在每个宣布间隔内）的开销而崩溃，您必须限制您的播种集群仅加载当前请求的当前工作项目集。无论如何，下载者都需要从中心位置获取（下载）.torrent 文件，这可能会触发将其加载到播种集群中。或者，通过识别不是来自您的种子集群之一的公告来确定特定信息哈希的活动。

rTorrent 具有快速恢复（意味着在加载适当准备的 .torrent 时不会发生散列），并且可以通过 xmlrpc 进行控制，因此您可以停用空闲项目。这样，.torrent 下载可以触发实际数据在接下来的 24 小时内可用，或者只要集群中有活动。

【参考方案4】：

协议允许这样做，但我不知道哪些客户端可以扩展到数百万个种子。在最坏的情况下，您将不得不编写自己的纯种子客户端。

与您的用例最相关的协议特性是，当一个对等方连接到另一个对等方时，连接的对等方应该首先发送 torrent 的信息哈希。这意味着单个侦听 TCP 端口可用于播种无限量的种子，空闲时使用的资源几乎为零。

这可以在The BitTorrent Protocol Specification找到：

如果双方不发送相同的值，他们会切断连接。一个可能的例外是，如果下载者想通过单个端口进行多次下载，他们可能会等待传入的连接首先给出下载哈希，如果它在他们的列表中，则使用相同的响应。

我在Bittorrent Protocol Specification v1.0 上也发现了同样的情况：

连接的发起者应该立即发送他们的握手。如果接收者能够同时提供多个种子（种子由其 info_hash 唯一标识），则接收者可以等待发起者的握手。

但是，有一件事会增加您的负载，那就是跟踪器。使用正常的跟踪器协议，每个客户端都必须定期向跟踪器宣布它拥有的每个种子，以及它上传了多少等信息。对于数以百万计的洪流，这将带来一些高负载。如果您正在编写自己的仅限批量种子的客户端，那么向跟踪器宣布播种机的单独协议将是一个好主意。