Ste*_*hen 5 bittorrent bigdata
我正在考虑将bittorrent用于大数据传播问题,其中数据源是千万亿次级,用户需要高达数TB的数据.一些细节
我预计活动种子的数量与可用总量相比较小,但服务质量很重要,因此每个种子必须有几个播种机或一些推出新播种机的机制.
我的问题是,bittorrent客户可以处理播种大量的种子,其中大部分都是空闲的吗？我是否需要在群集中的种子上划分种子,或者每个节点是否可以播种它可以访问的所有种子？哪个客户会做得最好？是否有任何工具来管理播种群？
我假设跟踪器可以扩展到这个级别.
有2个主要问题：
至于跟踪器流量，假设您有 100 万个种子，典型的重新发布间隔为 30 分钟，但某些跟踪器将其设置为 1 小时。让我们保守一点，假设您的跟踪器使用 1 小时的广播间隔。您必须每小时发出 100 万个 GET 请求，假设每个请求向上 400 字节和向下 100 字节（假设大多数响应不包含任何对等点），即大约 111 kB/s 向上和 28 kB/s 向下。这还不错，但请记住，TCP 需要额外的往返来建立连接，因此又减少了 40 个字节，增加了 40 个字节。
这可以通过仅使用UDP 跟踪器来缓解。然后您只需要一个连接消息，并且您可以为每个通知重复使用连接 ID。每个通知消息将是 100 字节，并且返回的消息也会更紧凑一些，假设为 60 字节。这将使您的速度提高 28 kB/s，降低 16kB/s，只是为了保持种子文件的发布。为此，您需要一个具有良好 udp 跟踪器支持的客户端（例如，一个缓存连接 ID 的客户端）。
还不错，假设与您的种子发送的实际数据相比微不足道。
但是，您不一定需要在不同的数据中心对种子文件进行条带化，您也可以使用 HTTP 服务器来为种子文件提供种子。所有主要的 bittorrent 客户端都支持 http 种子，您不必担心向跟踪器宣布（URL 被烧入 .torrent 本身）。
至于可以很好地扩展种子的客户端，我不确定，我没有做过任何测量。生成一百万个随机种子并尝试加载它应该相当简单。
我在libtorrent rasterbar 中做了一些优化工作，以使其在许多种子中都能很好地扩展，不过我还没有尝试过数百万次。
我已经写了一篇关于这个主题的博客文章，这里。
该协议允许这样做，但我不知道哪些客户端可以扩展到数百万个种子。在最坏的情况下，您将不得不编写自己的仅种子客户端。
与您的用例最相关的协议功能是，当一个对等点连接到另一个对等点时，连接的对等点应该首先发送 torrent 的信息哈希。这意味着单个侦听 TCP 端口可用于播种无限量的种子，空闲时使用的资源几乎为零。
如果双方不发送相同的值，则会断开连接。一个可能的例外是，如果下载者想要通过单个端口进行多次下载，他们可能会等待传入连接首先给出下载哈希，然后使用相同的哈希进行响应（如果它在他们的列表中）。
我还在Bittorrent 协议规范 v1.0中发现了相同的内容：
连接的发起者应该立即传输握手信号。如果接收者能够同时提供多个 torrent（torrent 由其 info_hash 唯一标识），则接收者可以等待发起者的握手。
然而，有一样东西会增加你的负载，那就是追踪器。使用正常的跟踪器协议，每个客户端都必须定期向跟踪器宣布其拥有的每个 torrent，以及已上传的数量等信息。对于数百万个种子，这会带来较高的负载。如果您正在编写自己的仅批量种子客户端，那么使用单独的协议向跟踪器宣布您的种子程序将是一个好主意。