logo标签列表

使用比特流协议分发夜间构建和CI版本。

c#continuous-integrationbittorrent
6
这个问题是基于我昨天提出的问题使用git分发夜间构建所了解到的。
在上面的问题的答案中，很明显git并不适合我的需求，鼓励重新考虑使用BitTorrent。

简短版

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

长版

注：如果您已经阅读了我的之前的问题，则可以跳过以下段落。

每天早上，我们需要将我们的夜间构建分发给70多人的工作室（艺术家、测试人员、程序员、制作等）。到目前为止，我们已将构建复制到服务器上，并编写了一个同步程序来获取它（在底层使用Robocopy）；即使设置了镜像，传输速度仍然不可接受，在高峰时期需要花费一小时或更长时间进行同步（非高峰时期大约需要15分钟），这表明存在硬件I/O瓶颈和可能的网络带宽问题。

我目前所知道的

我目前所发现的：

  • 我在维基百科上找到了一个关于BitTorrent协议的精彩文章，它是一篇有趣的阅读材料（我之前只知道种子是如何工作的基础知识）。此外，我还发现了这个StackOverflow答案，介绍了客户端和服务器握手后发生的BITFIELD交换。

  • 我还发现了MonoTorrent C#库（GitHub源代码），可以用来编写我们自己的跟踪器和客户端。我们不能使用现成的跟踪器或客户端（例如uTorrent）。

问题

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

使用这个设计，我是否需要为每一个新的构建创建一个新的.torrent文件？换句话说，是否可能创建一个“滚动”的.torrent文件，如果构建内容只有20%发生了变化，则只需要下载这20%即可“获取最新”？
... 实际上，在撰写上述问题时，我认为我需要创建新文件，但我可以将其下载到用户机器上的相同位置，哈希将自动确定我已经拥有的内容。这正确吗？
对评论的回应

  1. 为了完全同步整个构建（包括：游戏、源代码、本地化数据以及PS3和X360的光盘映像），共计约37,000个文件，总大小刚好不到50GB。随着生产继续，这个数字还会增加。在只有另外两个同步正在进行的时间，这次同步花费了29分钟才完成，如果考虑到早上9点会有50多个人想要获取最新版本，那么这个时间可以算是低峰期。

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

  3. 关于不使用现成的客户端，这是一个法律问题，因为安装像uTorrent这样的应用程序可能会导致其他物品轻松地通过该程序下载。我们还希望有一个自定义的工作流程来确定您想要获取哪个构建（例如，根据您桌子上的DEVKIT是PS3还是X360）并通知可用的新构建等等。使用MonoTorrent创建客户端并不是我所担心的部分。

1
你分发的文件大小是多少？你尝试过压缩吗？你也可以使用二进制差异工具与之前的版本进行比较，补丁对于几乎所有人来说已经足够了（其他人将下载完整包）。 - Guillaume
1
你确定更改协议/工具会解决问题吗？你是否对你试图在网络上分发的内容与你的硬件、网络带宽等进行了实际的数学计算？例如，你是否检查过文件系统缓存（参考：http://blogs.technet.com/b/askperf/archive/2007/05/08/slow-large-file-copy-issues.aspx）？ - Simon Mourier
我真的看不出为什么你不能使用现成的客户端，难道你也在运行内部网页浏览器和文字处理软件吗？ - grapefrukt
更新了带有对评论的回复的问题。 - Dennis
那么直接使用电驴怎么样？ - Daniel Mošmondor
4个回答
6
对于是否需要创建一个新的.torrent文件的问题，答案是是的。
然而，根据你的数据布局，你可能可以进行一些简单的半增量更新。
如果你要分发的数据是大量的单个文件集合，并且每次构建时都可能更改一些文件，你只需创建一个新的.torrent文件，并让所有客户端下载到与旧文件相同的位置（就像你建议的那样）。客户端将首先检查已经存在于磁盘上的文件，更新已更改的文件并下载新文件。主要缺点是删除的文件实际上不会在客户端中被删除。
如果你自己编写客户端，那么在.torrent文件中不存在的文件系统中的文件删除是一个相当简单的步骤，可以分开执行。
如果你分发一个映像文件，则这种方法不起作用，因为版本之间保持不变的位可能已经移动，从而产生不同的块哈希。
我不一定建议使用超级种子。根据你使用的超级种子实现的严格程度如何，它实际上可能会损害传输速率。请记住，超级种子的目的是最小化从种子发送的字节数，而不是最大化传输速率。如果你的所有客户端都表现正常（即使用最稀少的优先），块分配就不应该是一个问题。
此外，创建种子并对50 GiB的种子进行哈希检查会给硬盘带来很大的负载，你可能需要为此基准测试你使用的bittorrent实现，以确保它足够高效。在50 GiB时，不同实现之间的差异可能会很大。
3

我想给你添加一些非BitTorrent的建议：

  • 如果夜间构建之间的差异不大，您可以使用rsync来减少网络流量并缩短复制构建所需的时间。在以前的公司中，我们使用rsync将构建提交给我们的出版商，因为我们发现我们的光盘映像在每次构建时变化不大。

  • 您是否考虑过简单地分阶段进行复制操作，以便客户端不会相互拖慢传输速度？当我们进行里程碑分支时，我们在内部使用一个简单的Python脚本：该脚本休眠直到指定范围内的随机时间，然后唤醒，下载和检出所需的存储库并运行构建。用户在下班时运行脚本，回来时就已经准备好了所有内容的新副本。

2
您可以使用BitTorrent同步，它是一种类似于Dropbox但没有云服务器的替代品。它允许您同步任意数量和大小的文件夹和文件，并与多个人共享，使用与BitTorrent协议相同的算法。您可以创建只读文件夹并与他人分享密钥。这种方法消除了为每个构建创建新的torrent文件的需要。
我刚刚了解到在“.”上同步数据，并且在过去的6个月中已经传输了1PB的数据。然而，我并没有立即想到我可以用它来实现这个目的。谢谢！ - Dennis
0

只是为了在选择中再加入另一个选项，您是否考虑过BITS？我自己没有使用过它，但从阅读文档来看，它支持分布式对等缓存模型，听起来它可以实现您想要的。

缺点是它是一个后台服务，因此它会放弃网络带宽，以支持用户发起的活动 - 对于您的用户很好，但如果您需要快速获取机器上的数据，则可能不是您想要的。

不过，这是另一个选择。

谢谢您的建议。我们查看了 BITS（后台智能传输服务），也许会将其用作短期解决方案。 - Dennis
1
BITS作为后台下载器非常出色，但是根据文档：“BITS 3.0：从Windows 7开始，BITS 3.0点对点缓存模型已被弃用。如果安装了BITS 4.0，则BITS 3.0点对点缓存模型不可用。有关更多信息，请参见点对点缓存。” - Ian Mercer
@Hightechrider：感谢您提供有关BITS缓存模型的附加信息。 - Dennis
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接