使用 bittorrent 协议分发夜间和 CI 构建

Posted 2023-02-23

【中文标题】使用 bittorrent 协议分发夜间和 CI 构建

【英文标题】：Using the bittorrent protocol to distribute nightly and CI builds

【发布时间】：2011-09-08 07:43:24

【问题描述】：

这个问题延续了我昨天从题为using git to distribute nightly builds的问题中学到的知识。

在对上述问题的回答中，很明显 git 不适合我的需求，并鼓励使用 BitTorrent 重新检查。

---

短版

需要每天早上向 70 多人分发夜间构建，希望使用 git BitTorrent 来负载平衡传输。

加长版

注意。如果你读过我的previous question，你可以跳过下面这段。

每天早上，我们都需要将每晚的构建分发给 70 多人（艺术家、测试人员、程序员、制作人员等）的工作室。到目前为止，我们已经将构建复制到服务器并编写了一个同步程序来获取它（使用下面的 Robocopy）；即使设置了镜像，传输速度也慢得令人无法接受，因为在高峰时间（非高峰时间大约为 15 分钟）需要长达一个小时或更长时间才能同步，这表明硬件 I/O 瓶颈和可能的网络带宽。

到目前为止我所知道的

到目前为止我发现了什么：

我在 Wikipedia 上找到了关于 BitTorrent protocol 的优秀条目，这是一本有趣的读物（我以前只知道种子如何工作的基础）。在客户端-服务器握手之后发生的 BITFIELD 交换中也发现了这个*** answer。

我还找到了MonoTorrent C# Library (GitHub Source)，我可以用它来编写我们自己的跟踪器和客户端。我们不能使用现成的跟踪器或客户端（例如 uTorrent）。

问题

在我的初始设计中，我让构建系统创建一个 .torrent 文件并将其添加到跟踪器。我将使用我们现有的构建镜像超级种子 torrent。

使用这种设计，我是否需要为每个新版本创建一个新的 .torrent 文件？换句话说，是否有可能创建一个“滚动”.torrent，如果构建的内容只有 20% 的变化，那么这就是所有需要下载的内容 get latest?

...实际上。在编写上述问题时，我认为我需要创建新文件但是我将能够下载到用户机器上的相同位置并且哈希将自动确定我已经拥有的。它是否正确？

回应cmets

为了完全同步整个构建（包括：游戏、源代码、本地化数据和 PS3 和 X360 的光盘映像）约 37,000 个文件，仅不到 50GB。随着生产的继续，这将增加。此同步需要 29 分钟才能完成，当时只发生了 2 次其他同步，如果您考虑到上午 9 点我们将有 50 多人想要获得最新信息，那么这是一个低峰。

我们与 IT 部门一起调查了磁盘 I/O 和网络带宽；结论是网络存储正在饱和。我们还将统计数据记录到同步数据库中，这些记录表明，即使只有少数用户，我们的传输速率也无法接受。

关于不使用现成的客户端，在用户计算机上安装像 uTorrent 这样的应用程序是一个法律问题，因为可以使用该程序轻松下载其他项目.我们还希望有一个自定义工作流程来确定您想要获得哪个版本（例如，仅 PS3 或 X360，具体取决于您桌面上的 DEVKIT）并通知可用的新版本等。使用 MonoTorrent 创建客户端不是部分我很担心。

【问题讨论】：

您分发的文件大小是多少？您是否尝试过良好的压缩？您也可以使用二进制 diff 工具对比之前的版本，该补丁几乎可以满足所有人的需求（其他人将下载完整的软件包）。

您确定更改协议/工具会解决问题吗？与您的硬件、网络带宽等相比，您是否对您尝试在网络上分发的内容进行了真正的数学计算...例如，您是否检查过文件系统缓存（参见：blogs.technet.com/b/askperf/archive/2007/05/08/…）？

我真的不明白为什么您不能使用现成的客户端，您是否也在运行内部网络浏览器和文字处理器？

更新了问题并回复了 cmets。

使用开箱即用的 e-mule 怎么样？

【参考方案1】：

对于是否需要创建新的 .torrent 的问题，答案是：是。

但是，根据您的数据布局，您也许可以进行一些简单的半增量更新。

如果您分发的数据是大量单个文件的集合，则每次构建时某些文件可能已更改，您只需创建一个新的 .torrent 文件并让所有客户端将其下载到与旧文件相同的位置（就像你建议）。客户端将首先检查磁盘上已存在的文件，更新已更改的文件并下载新文件。主要缺点是删除的文件实际上不会在客户端被删除。

如果您仍然在编写自己的客户端，那么删除文件系统上不在 .torrent 文件中的文件是一个相当简单的步骤，可以单独完成。

如果您分发图像文件，这将不起作用，因为在各个版本中保持相同的位可能已移动，从而产生不同的片段哈希。

我不一定推荐使用超级播种。根据您使用的超级种子实现的严格程度，它实际上可能会损害传输率。请记住，超级种子的目的是最小化从种子发送的字节数，而不是最大化传输速率。如果您的所有客户都表现正常（即首先使用最稀有的），那么块分配应该不是问题。

此外，要创建一个 torrent 并对 50 GiB 的 torrent 进行哈希检查会给驱动器带来大量负载，您可能需要对用于此操作的 bittorrent 实现进行基准测试，以确保它具有足够的性能。在 50 GiB 时，不同实现之间的差异可能很大。

【参考方案2】：

只是想添加一些非 BitTorrent 的建议供您阅读：

如果每晚构建之间的差异不显着，您可以使用rsync 来减少网络流量并减少复制构建所需的时间。在之前的一家公司，我们使用 rsync 将构建提交给我们的发布者，因为我们发现我们的光盘映像在构建之间没有太大变化。

您是否考虑过简单地错开复制操作，以便客户端不会减慢彼此的传输速度？当我们做里程碑分支时，我们一直在内部使用一个简单的 Python 脚本：脚本进入休眠状态，直到指定范围内的随机时间，唤醒，下载并签出所需的存储库并运行构建。用户在下班时运行脚本，当他们返回时，他们准备好了所有内容的新副本。

【参考方案3】：

您可以使用BitTorrent sync，它在某种程度上可以替代保管箱，但在云中没有服务器。它允许您同步任意数量的文件夹和任意大小的文件。有几个人，它使用来自 bit Torrent 协议的相同算法。您可以创建一个只读文件夹并与他人共享密钥。此方法无需为每个构建创建一个新的 torrent 文件。

【讨论】：

我刚刚阅读了有关 \. 上的同步以及在过去 6 个月中它如何传输 1PB 数据的信息。但是，我并没有立即想到我可以用于此目的。谢谢！

【参考方案4】：

只是为了加入另一个选项，你考虑过BITS吗？我自己没有使用它，但通过阅读文档，它支持分布式peer caching model，听起来它会实现你想要的。

缺点是它是一项后台服务，因此它会放弃网络带宽以支持用户发起的活动——这对您的用户来说很好，但如果您急需一台机器上的数据，这可能不是您想要的。

不过，这是另一种选择。

【讨论】：

感谢您的建议。我们查看了 BITS（后台智能传输服务），可能会将其用作短期解决方案。

BITS 非常适合作为后台下载器但是 根据文档："BITS 3.0：从 Windows 7 开始，BITS 3.0 对等缓存模型已被弃用。如果BITS 4.0 已安装，BITS 3.0 对等缓存模型不可用。有关详细信息，请参阅对等缓存。"

@Hightechrider：感谢您提供有关 BITS 缓存模型的更多信息。