BitTorrent节点是否能够处理大量空闲种子的做种？

Question

我考虑在数据源为petascale且用户需要高达几个TB的情况下使用BT进行数据传播。以下是一些细节：

• 潜在的种子数可能达到数百万
• Torrent的大小范围从100 MB到100 GB不等
• 在全球范围内有一组稳定的群集，可充当种子方，每个群集保存着总Torrent的大部分（平均为60%）
• 相对较少的用户同时下载（少于100），平均需要下载几个TB的数据。

我预计活跃的Torrent数量与总量相比较小，但服务质量很重要，因此每个Torrent必须有多个Seeder或某种机制来启动新的Seeder。

我的问题是BT客户端能否处理种子数量巨大的Torrent，其中大部分是空闲的？我是否需要将Torrent条带化跨越整个群集中的种子，或者每个节点都可以下载其访问权限下的所有Torrent？哪个客户端的表现最好？是否有用于管理种子的群集的工具？

我假设Tracker可以扩展到这个级别。

- Stephen

Answer 1

有两个主要问题：

1. 每个种子（通常）需要定期向跟踪器宣告，这可能会消耗大量带宽。
2. BitTorrent客户端本身需要以可扩展的方式编写，以应对大量种子。

至于跟踪器流量，让我们假设你有100万个种子，典型的重新宣告间隔为30分钟，但某些跟踪器将其设置为1小时。保守估计，假设您的跟踪器使用1小时的宣告间隔。您将不得不每小时进行100万次GET请求，假设每个请求上行400字节和下行100字节（假设大多数响应不包含任何对等方），那么就是约111kB/s的上行和28kB/s的下行不断地进行。这还不错，但请记住，TCP需要额外的往返来建立连接，因此又需要40字节的下行和40字节的上行。

这可以通过仅使用UDP trackers来缓解。然后，您只需要一个连接消息，每个announce都可以重复使用连接ID。然后，每个announce消息将为100字节，返回的消息也会更加紧凑，假设为60字节。这将使您获得28 kB/s上传和16kB/s下载，仅用于保持种子的announce。为此，您需要一个带有良好udp tracker支持的客户端（例如缓存连接ID的客户端）。

不算太糟糕，假设与您的种子实际发送的数据相比微不足道。

但是，您不一定需要在不同的数据中心之间分割您的种子，也可以使用HTTP服务器来播种。所有主要的bittorrent客户端都支持http种子，而且您不必担心向跟踪器通告（URL已经烙印到.torrent文件本身中）。

至于与种子规模相适应的客户端，我不确定，我没有进行任何测量。只需生成一百万个随机种子并尝试加载它应该就很容易了。

我已经在libtorrent rasterbar中进行了一些优化工作，使其可以很好地处理多个种子，但我尚未尝试过百万级别的种子。

我已经写了一篇关于这个主题的博客文章，在这里。

- Arvid

---

Arvid在这里发布了有关libtorrent的更多调优技巧：http://libtorrent.org/tuning.html。其他客户端也可以进行类似的优化。 - Encombe

Answer 2

您可能正在寻找Hekate。它目前处于最好的情况下，预览版阶段，但它几乎就是您所描述的内容。

- Aranjedeath

---

如果你正在寻找能够扩展到那个级别的跟踪软件，那么你需要寻找opentracker，这是海盗湾在关闭所有跟踪器之前使用的软件。有了这两个东西，你就不应该有任何重要的数据分发问题。 - Aranjedeath

Hekate 似乎已经死了。太糟糕了——这个想法非常好。 - Adobe

Answer 3

为了不被数百万无用的跟踪器公告和抓取压垮（每个公告间隔都有），您必须将种子群集限制为仅加载当前请求的工作集。下载者需要从中央位置获取（下载）.torrent文件，这可能会触发将其加载到种子群集中。或者，通过识别不来自您的种子群集之一的公告来确定特定信息哈希的活动。

rTorrent具有快速恢复功能（意味着在加载适当准备好的.torrent时不进行哈希处理），并且可以通过xmlrpc进行控制，因此您可以停用空闲项目。这样，.torrent下载可以触发实际数据在下一个24小时内或在群集中有活动的时间内可用。

- pyroscope

Answer 4

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

对于您的用例来说，最相关的协议特性是当一个对等体连接到另一个对等体时，连接对等体应该首先发送种子的信息哈希值。这意味着单个监听TCP端口可以用于播种无限数量的种子，在空闲时几乎不使用任何资源。

这可以在BitTorrent协议规范中找到：

如果双方没有发送相同的值，则它们会断开连接。唯一可能的例外是如果下载器想要通过单个端口进行多次下载，则它们可以等待传入连接先提供下载哈希值，如果在其列表中，则回复相同的哈希值。

我还在Bittorrent协议规范v1.0中找到了相同的内容：

发起连接的一方应立即传输握手信息。如果接收方能够同时为多个种子提供服务（种子通过其info_hash唯一标识），则可以等待发起方的握手信息。

然而，有一件事会增加您的负载，那就是追踪器。使用普通的追踪器协议，每个客户端都必须定期向追踪器宣布其拥有的每个种子，并提供上传量等信息。对于数百万个种子来说，这将带来相当大的负载。如果您正在编写自己的仅用于大规模种子发布的客户端，建议使用单独的协议向追踪器宣布您的种子发布者。

- CesarB