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

Question

这个问题继续从我昨天的问题中学到的,即使用git分发夜间版本.

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

---

精简版

需要每天早上向70多人分发每晚构建,想使用git BitTorrent来平衡转移.

长版

NB.如果您已阅读我之前的问题,可以跳过以下段落.

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

到目前为止我所知道的

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

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

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

问题

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

使用这种设计,我是否需要为每个新构建创建一个新的.torrent文件？换句话说,是否有可能创建一个"滚动" .torrent,如果构建的内容只有20%的变化,那么需要下载才能获得最新的内容？

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

回应评论

1. 对于完全新鲜同步整个构建(包括:游戏,源代码,本地化数据,和光盘图像为PS3和X360)〜37000页的文件和在未来只是 50GB下.随着生产的继续,这将会增加.当只有2个其他同步发生时,这个同步需要29分钟才能完成,如果您认为在早上9点我们将有50多个想要获得最新的人,这个低峰值.

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

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

Answer 1

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

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

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

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

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

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

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