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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тем не менее, это другой вариант.