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

时间:2011-09-08 07:43:24

标签: c# continuous-integration bittorrent

这个问题继续从我昨天的问题中学到的using git to distribute nightly builds

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


短版

每天早上需要将每晚的版本分发给70多个人,想使用 git BitTorrent 来平衡转移。

长版

NB。如果您已阅读我的previous question

,则可以跳过以下段落

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

到目前为止我所知道的

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

  • 我在维基百科上找到了关于BitTorrent protocol的优秀条目,这是一个有趣的读物(我以前只知道基础知识关于种子如何工作)。在客户端 - 服务器握手之后的BITFIELD交换中也发现了这个StackOverflow answer

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

问题

在我的初始设计中,我让我们的构建系统创建了一个 .torrent 文件,并添加到跟踪器中。我会使用我们现有的构建镜像 super-seed torrent。

使用此设计,我是否需要为每个新版本创建一个新的 .torrent 文件?换句话说,是否有可能创建一个“滚动” .torrent ,如果构建的内容只有20%的变化,那就是需要下载到获取最新的< / em>的?

......实际上。在编写上述问题时,我认为我需要创建新文件然而我可以下载到用户计算机上的相同位置,哈希将自动确定我已经拥有的东西。它是否正确?

回复评论

  1. 为了完全全新同步整个构建(包括:PS3和X360的游戏,源代码,本地化数据和光盘映像)~37,000个文件,并且低于50GB。随着生产的继续,这将会增加。这个同步需要29分钟才能完成,当时只有2个其他同步发生,如果你认为在早上9点我们会有50多个人想要获得最新信息,这个低峰值。

  2. 我们已经与IT部门调查了磁盘I / O和网络带宽;结论是网络存储已经饱和。我们还将统计数据记录到同步数据库中,这些记录显示,即使是少数用户,我们也会获得不可接受的传输速率。

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

4 个答案:

答案 0 :(得分:6)

关于您是否需要创建新的.torrent的问题,答案是:

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

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

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

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

我不一定建议使用超级种子。根据您使用的超级种子实施的严格程度,它实际上可能会损害传输速率。请记住,超级播种的目的是最小化从种子发送的字节数,而不是最大化传输速率。如果您的所有客户都表现得正常(即首先使用最稀有的),那么无论如何都不应该成为问题。

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

答案 1 :(得分:3)

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

  • 如果夜间构建之间的差异不显着,您可以使用rsync来减少网络流量并减少复制构建所需的时间。在之前的公司,我们使用rsync向我们的发布者提交构建版本,因为我们发现我们的光盘映像并没有改变构建版本。

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

答案 2 :(得分:2)

您可以使用BitTorrent sync这是Dropbox的替代方案,但云中没有服务器。它允许您同步任意大小的任意数量的文件夹和文件。有几个人,它使用相同的算法从Torrent协议。您可以创建只读文件夹并与其他人共享密钥。此方法无需为每个构建创建新的torrent文件。

答案 3 :(得分:0)

只是在混合中添加另一个选项,你考虑过BITS吗?不是自己使用它,而是通过阅读它支持分布式peer caching model的文档,听起来它会达到你想要的效果。

缺点是它是一个后台服务,所以它会放弃网络带宽,有利于用户发起的活动 - 对你的用户很好,但如果你急需机器上的数据,可能不是你想要的。

不过,这是另一种选择。