Могут ли одноранговые одноранговые устройства справляться с посевом большого количества бездействующих торрентов

Question

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

• Количество потенциально опасных потоков в миллионах
• Размеры торрента от 100 МБ до 100 ГБ
• Стабильный набор кластеров по всему миру, способных действовать как сеялки, каждый из которых содержит большое подмножество общих потоков (скажем, в среднем 60%)
• Относительно небольшое количество одновременных пользователей (менее 100), желающих загрузить в среднем несколько терабайт данных.

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

У меня вопрос: могут ли клиенты-торренты обрабатывать огромное количество торрентов, большинство из которых бездействуют? Нужно ли чередовать торренты через сеялки в кластере, или каждый узел может заполнять все торренты, к которым он имеет доступ? Какой клиент сделает лучшую работу? Есть ли инструменты для управления кластерами сеялок?

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

Answer 1

Существует две основные проблемы:

1. Каждый торрент (обычно) должен периодически сообщать трекеру, что может привести к использованию значительной полосы пропускания.
2. Бит-торрентсам клиент должен быть написан так, чтобы масштабироваться с большим количеством торрентов

Что касается трафика трекера, давайте предположим, что у вас есть 1 миллион торрентов, типичный интервал повторного объявления составляет 30 минут,но у некоторых трекеров он установлен на 1 час.Давайте будем консервативны и предположим, что ваш трекер использует 1-часовой интервал объявления.Вам нужно будет делать 1 миллион запросов GET в час, скажем, каждый запрос на 400 байтов вверх и на 100 байтов вниз (при условии, что большинство ответов не содержат одноранговых узлов), это примерно на 111 кБ / с и на 28 кБ / с постоянно.Это не так уж и плохо, но имейте в виду, что TCP требует дополнительного обхода для установления соединений, так что это еще 40 байтов вниз и 40 байтов вверх.

Это можно уменьшить, используя только UDP-трекеры.Тогда вам потребуется только одно сообщение о подключении, и вы можете повторно использовать идентификатор подключения для каждого объявления.Каждое объявленное сообщение тогда будет иметь размер 100 байт, и возвращаемое сообщение также будет немного более компактным, допустим, 60 байт.Это увеличит скорость до 28 кБ / с и снизит 16 кБ / с, просто чтобы объявить торренты.Для этого вам понадобится клиент с приличной поддержкой трекера udp (например, который кэширует идентификатор соединения).

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

Однако вам не обязательно чередовать торренты по отдельным центрам обработки данных, вы также можете использовать HTTP-сервер для заполнения торрентов.Все основные клиенты Bittorrent поддерживают заполнение http, и вам не придется беспокоиться об объявлении на трекер (URL записывается в сам .torrent).

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

Я провел некоторую работу по оптимизации в libtorrent rasterbar , чтобы он хорошо масштабировался со многими торрентами.Я не пробовал миллионы.

Я написал сообщение в блоге на эту тему, здесь .

Answer 2

Возможно, вы ищете Гекат Это в лучшем случае пре-альфа, но это почти то, что вы описываете.

Answer 3

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

rTorrent имеет быстрое возобновление (то есть, при загрузке надлежащим образом подготовленного .torrent не происходит хеширование),и управляется через xmlrpc, так что вы можете списать незанятые элементы.Таким образом, загрузка .torrent может привести к тому, что фактические данные будут доступны в течение следующих 24 часов или до тех пор, пока в рое будет активность.

Answer 4

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

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

Это можно найти в Спецификация протокола BitTorrent :

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

Я также нашел то же самое в этой спецификации протокола Bittorrent v1.0 :

Ожидается, что инициатор соединения немедленно передаст свое рукопожатие.Получатель может дождаться рукопожатия инициатора, если он способен одновременно обслуживать несколько торрентов (торренты однозначно идентифицируются по их info_hash).

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