Использование протокола bittorrent для распространения по ночам и сборки CI

Question

Этот вопрос продолжается из того, что я узнал из моего вчерашнего вопроса под названием , использующего git для распространения ночных сборок .

В ответах на вышеуказанные вопросы было ясно, что git не подойдет мненеобходимо и было рекомендовано провести повторное изучение с помощью BitTorrent.

---

Короткая версия

Необходимость распространять ночные сборки для более 70 человек каждое утро, которые хотели бы использовать git BitTorrent для балансировки нагрузки при передаче.

Длинная версия

Примечание.Вы можете пропустить нижеследующий абзац, если вы прочитали мой предыдущий вопрос .

Каждое утро нам нужно раздавать наши ночные сборки студии более 70 человек (художники, тестировщики,программисты, производство и т. д.).До сих пор мы копировали сборку на сервер и написали программу синхронизации, которая извлекает ее (используя Robocopy внизу);даже при настройке зеркал скорость передачи неприемлемо мала, поскольку для синхронизации в пиковое время (непиковое время составляет примерно 15 минут) требуется до часа или дольше, что указывает на узкое место аппаратного ввода-вывода и, возможно, пропускную способность сети.

Что я знаю до сих пор

Что я нашел до сих пор:

• Я нашел отличную запись в Википедиио протоколе BitTorrent , который был интересным чтением (я только ранее знал основы того, как работают торренты).Также нашел этот StackOverflow ответ на обмен BITFIELD, который происходит после рукопожатия клиент-сервер.

• Я также нашел библиотеку MonoTorrent C # ( GitHub Source ), который я могу использовать для написания нашего собственного трекера и клиента.Мы не можем использовать готовые трекеры или клиентов (например, uTorrent).

Вопросы

В моем первоначальном проекте у меня есть система сборки, создающая файл .torrent и добавив его в трекер.Я бы super-seed торрент использовал наши существующие зеркала сборки.

Используя этот дизайн, мне нужно будет создавать новый файл .torrent для каждой новой сборки?Другими словами, можно ли было бы создать «скользящий» .torrent , где, если содержимое сборки изменилось только на 20%, то есть все, что нужно загрузить в , получить самую последнюю ?

... На самом деле.При написании вышеупомянутого вопроса, я думаю, что мне нужно будет создать новый файл , однако Я смогу загрузить в ту же папку на компьютере пользователя, и хэш автоматически определит, что яуже есть.Это правильно?

В ответ на комментарии

1. Для полной свежей синхронизации всей сборки (включая: игру, исходный код, локализованные данные и образы дисков).для PS3 и X360) ~ 37 000 файлов и всего под 50 ГБ.Это будет увеличиваться по мере продолжения производства.Эта синхронизация заняла 29 минут, в то время как происходили только две другие синхронизации, что является низким пиком, если учесть, что в 9 утра у нас будет более 50 человек, желающих получить последние новости.

2. Мы исследовали дисковый ввод-вывод и пропускную способность сети с отделом ИТ;был сделан вывод, что сетевое хранилище было насыщенным.Мы также записываем статистику в базу данных синхронизаций, эти записи показывают, что даже при небольшом числе пользователей мы получаем неприемлемые скорости передачи.

3. Что касается неиспользования готовых клиентов, то с юридической точки зрения важно, чтобы на компьютерах пользователей было установлено приложение, такое как uTorrent , учитывая, что другие элементы могут быть легко загружены с помощью этой программы.Мы также хотим иметь собственный рабочий процесс для определения, какую сборку вы хотите получить (например, только PS3 или X360 в зависимости от того, какой DEVKIT у вас на рабочем столе) и иметь уведомления о новых сборках и т. Д. Создание клиента с помощью MonoTorrent не является частьючто меня беспокоит.

Answer 1

На вопрос, нужно ли вам создавать новый .torrent, ответ таков: yes .

Однако, в зависимости от структуры ваших данных, вы можетеуметь выполнять несколько простых полудельта-обновлений.

Если распространяемые вами данные представляют собой большую коллекцию отдельных файлов, при каждой сборке некоторые файлы могли изменяться, вы можете просто создать новый файл .torrent и получитьвсе клиенты загружают его в то же место, что и старый (как вы предлагаете).Клиенты сначала проверяют файлы, которые уже существуют на диске, обновляют те, которые были изменены, и загружают новые файлы.Основным недостатком является то, что удаленные файлы фактически не будут удаляться на клиентах.

Если вы все равно пишете свой собственный клиент, удаление файлов в файловой системе, которых нет в файле .torrent, является довольно простымшаг, который может быть выполнен отдельно.

Это не работает, если вы распространяете файл изображения, так как биты, которые остались одинаковыми в разных версиях, могли переместиться, что привело к получению различных кусочных хешей.

Я бы не рекомендовал использовать супер-посев.В зависимости от того, насколько строгой является реализация суперсеменирования, которую вы используете, это может фактически повредить ставкам передачи.Имейте в виду, что целью супер-заполнения является минимизация количества байтов, отправляемых из начального числа, а не максимизация скорости передачи.Если все ваши клиенты ведут себя должным образом (то есть сначала используют редчайшие), то распределение кусков в любом случае не должно быть проблемой.

Кроме того, для создания торрента и проверки хеша торрент в 50 ГиБ ставит многозагрузив диск, вы можете захотеть сравнить реализацию bittorrent, которую вы используете для этого, чтобы убедиться, что она достаточно производительная.При 50 ГиБ разница между различными реализациями может быть значительной.

Answer 2

Просто хотел добавить несколько не-BitTorrent предложений для вашего прочтения:

• Если разница между ночными сборками незначительна, вы можете использовать rsync , чтобы уменьшить сетевой трафик и сократить время, необходимое для копирования сборки. В предыдущей компании мы использовали rsync для отправки сборок нашему издателю, так как обнаружили, что образы наших дисков практически не менялись при сборке.

• Рассматривали ли вы просто смещение операций копирования, чтобы клиенты не замедляли передачу друг для друга? Мы использовали простой сценарий Python для внутренних целей, когда выполняем вехи: сценарий переходит в спящий режим до случайного времени в указанном диапазоне, просыпается, загружает и извлекает необходимые хранилища и запускает сборку. Пользователь запускает сценарий, когда уходит с работы на тот день, когда он возвращается, у него есть свежая копия всего, что готово к работе.

Answer 3

Вы можете использовать BitTorrent sync Что является альтернативой dropbox, но без сервера в облаке.Это позволяет синхронизировать любое количество папок и файлов любого размера.с несколькими людьми, и он использует те же алгоритмы из битового протокола Torrent.Вы можете создать папку только для чтения и поделиться ключом с другими.Этот метод избавляет от необходимости создавать новый торрент-файл для каждой сборки.

Answer 4

Просто, чтобы добавить другой вариант в микс, вы рассматривали БИТЫ ?Не использовал его сам, но, читая документацию, он поддерживает распределенную модель однорангового кэширования , которая звучит так, как будто она достигнет того, что вы хотите.

Недостатком является то, что это фоновая служба, поэтомуОткажитесь от пропускной способности сети в пользу активности, инициируемой пользователем - приятно для ваших пользователей, но, возможно, не так, как вы хотите, если вам нужны данные на машине в спешке.

Тем не менее, это еще один вариант.