Tag: bittorrent

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

这个问题继续从我昨天的问题中学到的，即使用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％的变化，那么需要下载才能获得最新的内容 ？ ……其实。 在编写上述问题时，我认为我需要创建新文件， 但是我可以下载到用户计算机上的相同位置，哈希将自动确定我已经拥有的内容。 它是否正确？ 回应评论 为了完全全新同步整个构建（包括：PS3和X360的游戏，源代码，本地化数据和光盘映像）~37,000个文件，不到50GB。 随着生产的继续，这将会增加。 这个同步需要29分钟才能完成，当时只有2个其他同步发生，如果你认为在早上9点我们会有50多个想要获得最新的人，这个低峰值。 我们已经与IT部门调查了磁盘I / O和网络带宽; 结论是网络存储已经饱和。 我们还将统计数据记录到同步数据库中，这些记录显示即使是少数用户，我们也会获得不可接受的传输速率。 在不使用现成客户端的情况下，在用户机器上安装uTorrent等应用程序是一个法律问题，因为可以使用该程序轻松下载其他项目。 我们还希望有一个自定义工作流程来确定您想要获得哪个版本（例如，只有PS3或X360取决于您在桌面上的DEVKIT）并且可以获得新版本的通知等。使用MonoTorrent创建客户端不是我很担心。