Kademlia (DHT) — практическое руководство
Ресурс
Каждый узел сети имеет свой идентификатор. Кроме того любой ресурс в DHT будь то ключевое слово или файл тоже имеет идентификатор. В качестве идентификаторов используется значение хеш функции — в торрентах это SHA1, в ED2K это MD4. Разница только в длине — 160 бит против 128. Таким образом чтобы опубликовать или найти что-то в сети требуется хеш искомого ресурса.
В Кадемлии для публикации файла берется хеш используемый в самой сети ED2K, правда с некоторыми оговорками. Если сам хеш файла сериализуется просто как последовательность байт, KAD идентификатор сериализуется как последовательность 4-х 32-х битных слов. Это особенность Кадемлии.
Приходится вращать байты:
Для публикации ключевых слов имена файлов разбиваются на слова и каждое слово хешируется. Полученные хеши публикуются. Хеш можно представить в виде большого целого числа с порядком байт big endian — старшие байты по младшим адресам (в начале) или просто массивом байт.
Работа DHT основана на возможности вычисления расстояния между хешами, это позволяет последовательно приближаться к цели сокращая дистанцию. HASH_SIZE равно 128.
Компаратор двух хешей относительно некоторого целевого хеша. Обычно целевой хеш это собственный хеш узла.
Самая ходовая функция определения расстояния в K-bucket, если так можно выразиться.
Подключение к сети
Первым делом клиент генерирует свой идентификатор. Это случайный MD4 хеш (SHA1 для торрентов). Часть данных при генерации хеша может смешиваться с адресом, портом и тому подобные манипуляции для большей случайности.
Один из непонятных на первый взгляд моментов — как связан хеш узла который он себе назначил и ресурсы которые он предоставляет. Ответ — никак. Случайный выбор хеша означает что клиент в сети будет отвечать за ресурсы близкие его хешу — к нему будут приходить другие клиенты для публикации и поиска. Свои ресурсы клиент также будет публиковать на других узлах указывая себя в качестве источника.
Хотя DHT и децентрализованная сеть чтобы подключиться к ней нужно знать хотя бы один узел подключенный к сети. Зная адрес такого узла клиент посылает специальный запрос bootstrap и получает список узлов в ответ. Дальше можно рассылать bootstrap уже этим узлам и так далее. Также существуют сайты с которых можно скачать файлы с наборами узлов в формате ED2K.
Таблица маршрутизации
Таблица маршрутизации в частности предназначена для выбора нод наиболее близких некоторому хешу. Таблица содержит K-buckets. K-bucket на самом деле не более чем контейнер c структурами описывающими узел сети. Обычно таблицу иллюстрируют в виде дерева как например здесь.
Сама таблица маршрутизации может быть представлена просто листом K-bucket-ов отсортированным в порядке убывания расстояния до нашего идентификатора.
Изначально таблица не содержит ни одного K-bucket — они добавляются в процессе добавления узла.
Пусть таблица содержит такой параметр как количество уже созданных K-bucket — N(numBuckets). Номер K-bucket расчитывается используя выше упомянутую функцию distanceExp как 128 — 1 — distanceExp, более близкие нашему хешу узлы распологаются ближе к хвосту списка.
Каждый K-bucket позиции меньше чем N-2 может содержать узлы расстояние которых от нашего хеша равно n. К-bucket номер которого равен N-1 (крайний) содержит не только узлы с расстоянием n, но и все узлы расположенные ближе, проще говоря все остальные узлы. Диапазон значений n [0..127]. Понятнее это выглядит в коде функции поиска K-bucket (ниже).
Алгоритм добавления узла
Разделение K-bucket
K-bucket может разделиться только если это крайний контейнер и это не последний возможный K-bucket. Теоретически всего K-bucket-ов может быть 128 для MD4, но последний букет не может быть использован так-как хеши совпадающие с хешем узла не обрабатываются. Принцип простой — в текущим контейнере остаются узлы с расстоянием равным n, в новый перемещаются все остальные. Таким образом после разделения таблица вырастет на один K-bucket.
Таблица маршрутизации представляет собой лист K-bucket. K-bucket это список структур описывающих узел из сети DHT. Реализация может быть произвольной, например можно поместить все это в таблицу базы данных. Таблица не сжимается — если узлы из некоего K-bucket пропадают до полного опустошения контейнера — он останется в таблице. Узлы могут удаляться например в случае недоступности некоторое время.
Обновление таблицы
Тут нечего подробно рассматривать — обновление это внутренний процесс призванный содержать таблицу маршрутизации в актуальном состоянии. Периодически выбирается K-bucket где требуется обновление, генерируется случайный хеш принадлежащий этому K-bucket, но не совпадающий ни с одним из уже имеющихся и запускается процесс поиска. Условие начала обновления — например последнее обновление было более 15 минут назад.
Публикация и поиск
Публикация и поиск это один и тот-же процесс в конце которого выполняется либо публикация на найденных узлах либо запрос на поиск. Суть его заключается в том, чтобы последовательными итерациями приблизиться к узлам идентификатор которых близок идентификаторам искомых ресурсов. По логике сети именно эти узлы будут содержать информацию о ключевых словах и файлах хеш которых близок их хешу.
Без лишних слов приведу структуру таблиц для хранения ключевых слов и источников. Эта структура используется в агрегаторе на отдельном хосте.
Видно что источник публикуется для некоего хеша файла один к одному. Ключевое слово же публикуется с относящимися к нему хешами файлов в названии которых оно упоминается как один ко многим. Таблицы денормализованы для удобства использования — можно было бы иметь некую таблицу ключей как мастер над sources/keywords.
Заключение
Несколько слов об архитектуре. Поддержка DHT реализована в отдельном трекере представляющим собой асинхронный UDP сервер работающий в выделенном треде. Он может быть запущен отдельно от клиентского приложения что удобно для тестирования. Собственно сейчас этот трекер работает в виде демона на отдельной машине. Запросы в сеть организованы в RPC вызовы через RPC менеджер — это решает задачу ограничения по времени ожидания ответа, позволяет пометить не отвечающие узлы и так далее.
Логически исходящие запросы объединены в менеджере (algorithm). Для каждого запроса создается контрольная структура (observer). Ну и все это запускается как уже упоминалось через RPC менеджер. Более подробно можно посмотреть в коде по ссылкам.
Особенность Кадемлии в том, что не всегда есть возможность точно определить ответ на какой запрос прислал хост в случае если несколько процессов работают одновременно и посылают одновременно несколько запросов одному узлу. К примеру процессы поиска узлов вполне могут пересечься и тут приходится прибегать к некоторым ухищрениям.
В торрентах более грамотная поддержка транзакций — при посылке запроса клиент посылает специальный блок transaction_id который должен быть ему возвращен. Это не только позволяет точно идентифицировать транзакцию, но и дает небольшую защиту сети.
Не стал рассматривать публикацию и поиск заметок (notes) потому что не реализовал поддержку этой возможности Кадемлии.
Надеюсь удалось изложить материал ничего не перепутав.
Kademlia DHT: Основы
Здравствуйте!
В этой статье, как и, надеюсь, в последующих, я хочу рассказать об одной из современных структурированных пиринговых сетей. Данный материал включает в себя мою переработку документаций, описаний и статей, найденных по теме. В качестве введения представлена общая краткая теория p2p-сетей, DHT, а уж затем следует основная часть, которой посвящена заметка.
1. Общая теория p2p
Распределение данных, процессорного времени и других ресурсов между пользователями заставляют искать решения организации сетей разного уровня и взаимодействия.
На смену клиент-серверному взаимодействую приходят сети p2p (point-to-point), чтобы предоставить больший уровень масштабируемости, автономности, анонимности, отказоустойчивости.
Далее будет приведена общая классификация.
Минусы и плюсы зависят от степени «гибридности» — какие характеристики она наследует от централизованных, а какие от децентрализованных (о которых речь пойдет далее).
Децентрализованные — Данный тип сетей подразумевает полное отсутствие серверов. Таким образом, исключается узкое место из сети.
При проектировании топологии и протоколов структурированных сетей оптимальным считается выполнение соотношений:
— Размер таблицы маршрутизации на каждом узле: O(log(n))
— Сложность поиска: O(log(n))
2. DHT
DHT (Distributed Hash Table) — распределенная хэш-таблица. Данная структура зачастую используется для децентрализованных топологий. Однако, это не единственный выбор (как подсказывает литература, впрочем, здесь лучше заняться дальнейшим самостоятельным поиском).
Для каждого значения (данных) на каждом узле вычисляется по определенным правилам хэш (например, с помощью SHA-1), который становится ключом. Также, вычисляется идентификатор узла (той же длины, что и хэш, а зачастую, той же функцией). Таким образом, каждый узел сети обладает своим идентификатором. Ключи публикуются в сети. Узел несет ответственность за ключи таблицы, которые близки к нему по определенной метрике (т.е. расстоянию), здесь подразумевается «похожесть» ключа на идентификатор, если опустить язык математики. Благодаря этому, каждый узел занимает свою зону ответственности при хранении ключей и связанных с ней информации (координаты узла, на котором расположено значение). Это позволяет определенным образом организовать алгоритм поиска по точным значениям (сначала вычислить ключ значения для поиска, например, имени файла, а затем искать этот ключ, направляя запросы к узлу, ответственному за него через посредников, предоставляющих полный путь).
DHT в полной степени обеспечивает отказоустойчивость и масштабируемость. В сочетании с Peer Exchange, например, DHT позволяет перехватить функции Torrent-трекера.
3. Kademlia
Метрика
Создателями данной топологии являются Petar Maymounkov и David Mazières. В основе работы протокола и построения таблиц лежит определения расстояния между узлами через XOR-метрику:
d(x, y) = x XOR y. Важно отметить, что расстоянием является результат операции XOR, интерпретируемый, как число, а не количество различающихся бит (такой критерий тоже может порождать метрику в пространстве ключей/идентификаторов). Т.е. при длине ключа 4 бита: d(2,5) = 0010 XOR 0101 = 0111 = 7.
XOR метрика удовлетворяет всем аксиомам метрики:
Данное свойство отмечают в связи с возможностью формального доказательства тезисов о размерах таблиц маршрутизации и сложности поиска. (Справедливости ради, предоставляемого в виде наброска).
Таблица маршрутизации
На вычислении расстояний между узлами (посредством применения метрики к их идентификаторам) базируется алгоритм построения таблиц маршрутизации.
Каждый i-ый столбец таблицы ответственен за хранение информации об узлах на расстоянии от 2^(i+1) до 2^i. Таким образом, последний столбец для узла 0111 может содержать информацию о любых узлах 1xxx, предпоследний об узлах 00xx, еще на уровень ближе — об узлах 010x.
Конечно, в реальной сети, применяется обычно длина ключа в 128, либо в 160 бит. Зависит от реализации.
Далее, вводится ограничение на число хранимых узлов на каждом уровне, K. Поэтому столбцы таблицы, ограниченные таким K, называют K-buckets (к сожалению, русский эквивалент, звучит совсем неблагозвучно).
Если рассмотреть бинарное дерево поиска, в листах которого лежат идентификаторы узлов, становится понятно, что такая структура K-buckets не случайна: каждый узел (а на примере 110) получает знания хотя бы об одном участнике каждого поддерева (для 110 выделенных залитыми овалами). Таким образом, каждый K-bucket отражает связь узла с не более, чем K участниками поддерева на уровне i. 
Протокол
STORE запрос, позволяющий разместить информацию на заданном узле. Перед выполнением STORE узел должен найти K ближайших к ключу значения, которое он собирается опубликовать, а лишь потом отправить каждому STORE с ключом и своими координатами. Хранение сразу на K узлах позволяет повысить доступность информации.
FIND_VALUE запрос, который, зачастую, повторяется для образования итерации, позволяющий найти значение по ключу. Реализует поиск значения в сети. Возвращает либо K ближайших узлов, либо само значение, в зависимости от достижения узла, хранящего искомые данные. Итерации прекращают как раз либо при возвращении значения (успех), либо при возврате уже опрошенных K узлов (значения нет в сети).
FIND_NODE запрос, используемый для поиска ближайших K к заданному идентификатору (поведение сходно с FIND_VALUE, только никогда не возвращает значение, всегда узлы!). Используется, например, при присоединении узла к сети по следующей схеме:
— Контакт с bootstrap узлом
— Посылка запроса FIND_NODE со своим идентификатором к bs узлу, дальнейшая итеративная рассылка
— Обновление K-buckets (при этом обновляются как K-buckets нового узла, так и всех, мимо которых проходил запрос (здесь на руку симметричность метрики XOR))
Как видно, протокол в своей спецификации практически не покрывает вопросы безопасности, что нашло отражение в исследованиях и работах по атаке Kademlia-based сетей.
Из особенностей стоит подчеркнуть наличие репликации, времени жизни значения (необходимость повторного размещения через определенный промежуток времени), параллелизм при посылке запросов FIND_*, дабы достигнуть нужных узлов за более короткое время (обозначается α, в реализациях обычно равно 3). При каждом прохождении запросов происходит попытка обновить K-bucket, что позволяет держать таблицы маршрутизации максимально оптимальными.
4. Реализации
Прежде всего, самой известной сетью, базирующейся на Kademlia является Kad Network, доступная в aMule/eMule. Для bootstrap используются существующие узлы в eDonkey.
Khashmir — Kademlia-реализация на Python, использующаяся в BitTorrent
Из ныне развивающихся и активных библиотек я бы еще отметил
maidsafe-dht — C++ реализация инфраструктуры с поддержкой UDT и NAT Traversal.
Mojito — Java библиотека от LimeWire.
5. Что дальше?
Хотел бы получить комментарии о том, во что следует углубиться подробнее, т.к. статья носит чрезвычайно поверхностный характер. Дабы пробудить интерес, а не выложить все карты разом на стол. Сам планирую в следующей заметке о Kademlia рассказать о проблемах безопасности, атаках и их предотвращении.
Децентрализованное Torrent хранилище в DHT
Уже много лет, как существует система DHT и вместе с ней торренты, которые мы успешно используем для получения любой информации.
Вместе с этой системой существуют команды для взаимодействия с ней. Их не так уж много, но для создания децентрализованной БД нужно всего два: put и get. Об этом и пойдёт речь далее.
Что бы положить или менять изменяемые данные нужно 2 ed25519 ключа. Публичный и приватный. И каждый у кого есть эти два ключа может менять данные, как ему хочется.
напомню, как работают приватные и публичные ключи
Информацию можно зашифровать приватным ключом, а расшифровать публичным. Поэтому эти ключи парные. Отгадать приватный ключ, имея публичный, невозможно.
На этом и можно построить децентрализованную БД
Вариантов много. Это дело вашей фантазии. Рассмотрим, например, такие:
Вариант 1.
У всех пользователей = пиров есть публичный и приватный ключ.
Пользователь 1 хочет изменить БД. Он получает содержимое DHT с помощью Get и публичного ключа. В полученных данных, может быть всё что угодно. У нас это будет sha1 ссылка торрента по которой можно скачать торрент. Её размер около 20 байт. По этой ссылке он скачивает торрент в котором находится БД. Изменяет БД. Генерирует торрент (получая sha1 ключ) и раздаёт его. Публикует Putом полученный sha1 ключ по которому уже можно скачать новую, изменённую БД.
Пользователь 2 хочет изменить БД. аналогично.
Для того что бы данные в DHT не пропали нужна регулярная синхронизация пиров. Синхронизация это Get с публичным ключом через udp. Очень малозатратно. И если данные изменились, то скачивание их. Это уже немного более затратно, но тут тоже можно ставить ограничение по скорости скачивания, например.
Если данные в DHT пропали, то пир, который хочет синхронизироваться просто делает Put с последними данными, какие у него есть, либо с чистыми данными.
А теперь немного о том, почему это БД, а не обмен файлами
В 1000 байт можно зашить всё что угодно. А в передаваемую БД бесконечное количество информации. Так как пользователь не знает публичного и приватного ключа, то он не может сам публиковать что-то. Это может только программа. А программа в зависимости от данных в этих 1000 байт может делать всё что угодно. Может получить блокировку пользователя и перевести его только в режим чтения. Получается это БД с правами доступа на изменение определённой информации. Особенно, это будет похожим на БД, если скачиваемые данные шифровать и хранить в одном файле без расширения.
Конечно здесь могут возникнуть определённые проблемы, но все они решаются.
Теперь о недостатках и проблемах
Например, если пользователь 1 опубликовал новый хеш, изменённой БД, но не стал раздавать его. В DHT можно хранить 5 записей sha1 это 100+байт всего и если какой либо из пользователей не смог скачать изменённую версию, то он качает следующую из 5ти и затем перепубликовывает на ту, которая скачивается. Соответственно другие пользователи уже не будут пытаться скачать, то что не качается и получат БД быстрее. Чем больше пользователей, тем лучше и быстрее будет работать БД.
Вторая не менее важная проблема это то что каждый пользователь имеет программу в которой хранятся публичный ключ и приватный. И если взломать программу, то можно получить эти ключи и с помощью них публиковать свои ложные данные. Тут можно сочинить немало способов борьбы с этим. Возможно в комментариях подскажут ещё какие-то. Но например: можно хранить ключ в шифрованном виде и расшифровывать его только при использовании. Можно шифровать БД отдельным ключом так что злоумышленнику понадобится вычислить ещё и этот ключ. Можно хранить ключи тоже в DHT и менять их периодически или на сайте. Способов столько на сколько фантазия богата. Поэтому нельзя точно сказать, что это уязвимость.
Вариант 2.
Пользователь генерирует пару ключей. Приватный и публичный. Связывается с менеджером (человек) и обменивается с ним публичными ключами (например через Bluetoth, Wifi). Далее у пользователя есть публичный ключ по которому он может получить БД и своя пара ключей для публикации изменений к БД. Пользователь с помощью своей пары ключей публикует изменения к БД. Менеджер делает опрос всех публичных ключей пользователей. Получает изменения пользователей, вносит их в БД и публикует. Пользователи получают новую БД и так по кругу.
Такую систему невозможно взломать, так как ключи не зашиты в программе, как в предыдущем примере. Однако и тут есть небольшой недостаток. Количество пользователей, которых нужно опросить менеджеру влияет на скорость обновления БД. Однако не существенно. В одну секунду можно опрашивать около 1000 пользователей и получать ответы в течении 30 секунд, как обычно. Думаю, в реальности опрос 1000 пользователей (=1000 UDP запросов) займёт около минуты. Для увеличения скорости можно подумать о распределённой БД. Например, у каждого менеджера будет по 1000 пользователей и менеджеры обменявшись публичными ключами для обмена информацией (между БД) могут публиковать изменения для другого менеджера под специальным публичным ключом. Таким образом падение производительности из-за количества пользователей удастся избежать.
Таким образом получается децентрализованная, но управляемая менеджерами БД.
Подобную систему уже можно использовать даже для биллинга. Отличие от блокчейн систем тут будет в том, что менеджер может управлять содержимым БД. Т.е. если пользователи используют БД для хранения денег, то они должны доверять менеджеру секрет транзакций. Для надёжности менеджеров может быть несколько. Чем их больше, тем быстрее будет происходить обновление БД и тем надёжнее будут данные в БД, но так же возрастает количество людей, знающих о транзакциях. Впрочем вместо менеджера может быть просто компьютер, которому все доверяют 🙂
Так как все публикуемые данные публичны, то для передачи транзакций от пользователей к менеджеру можно использовать всё те же публичные и приватные ключи для шифрования текста уже.
Вариант 3.
Возможно сделать децентрализованный интернет.
Например, если менеджеры будут хранить БД не с биллингом, а с ДНС именами и публичными ключами. То пользователи могут добавлять свои ДНС имена и могут скачивать БД с ДНС именами или обращаться к БД через публичный ip.
А дальше открывая сайт, пользователи будут обращаться к публичному ключу сайта, по которому будут получать информацию о том, как скачать содержимое сайта. Скачают сайт и смогут получать обновления сайта примерно раз в пол минуты. При этом браузер может отправлять информацию на сервер сайта с помощью публичного и приватных ключей, которые придут вместе с сайтом. Получится децентрализованная двусторонняя связь, скорость работы, которой будет расти от количества серверов сайта и пользователей, потому что все будут раздавать контент сайта. А получение изменений сайта возможно в пофайловом режиме.
Для работы подобного интернета нужно разработать специальный торрент-браузер и серверную часть.
Технически это возможно сделать на основе любой торрент библиотеки. Например Libtorrent. Она весит после компиляции всего 2,5Мб, написана на с++ и работает максимально быстро. Там есть техническая информация про Put.
Подобная система используется в моём приложении «Media Library», для публикации плейлистов. У меня уже есть даже админка для модерации. Всё успешно работает. Пользуйтесь.
По причине не правильной работы системы кармы на сайте, я не могу комментировать свои же статьи. Поэтому можете считать, что комментарии к статье отключены. Пишите вопросы в личные сообщения. Там, возможно, отвечу.
BitTorrent/DHT
Содержание
DHT [ править ]
DHT (англ. Distributed hash table распределенная хэш-таблица) — это протокол, позволяющий битторрент-клиентам находить друг друга без использования трекера.
Клиенты с поддержкой DHT образуют общую DHT-сеть и помогают друг другу найти участников одних и тех же раздач.
Поддержка DHT есть в клиентах Mainline, µTorrent, KTorrent, Deluge, BitSpirit, Transmission и BitComet. В Azureus есть собственная реализация DHT, то есть клиенты Azureus образуют свою собственную отдельную DHT-сеть, а с помощью плагина mainlineDHT присоединяются к стандартной сети DHT, участвуя одновременно в обеих сетях.
PEX [ править ]
PEX (Peer exchange) — это расширение протокола для обмена списками участников.
PEX реализуется как дополнительные сообщения между клиентами, уже соединёнными между собой для обмена сегментами файла по обычному протоколу BitTorrent.
PEX есть в клиентах Transmission, Azureus, BitComet, KTorrent, µTorrent, Tixati и BitTornado, причем в каждом клиенте он реализован по-своему, поэтому PEX между собой могут пользоваться только одинаковые клиенты. Начиная с 3 версии Azureus (Vuze) может обмениваться PEX с uTorrent и BitTorrent.
Функции [ править ]
И DHT и PEX фактически выполняют основную функцию трекера — помогают участникам файлообмена узнать друг о друге. Они могут:
Закрытый ключ (англ. Private key ) [ править ]
На открытых трекерах (англ. public ), где каждый желающий может скачать торрент и участвовать в раздаче, DHT и PEX служат на благо всех участников.
Закрытым (англ. private ) трекерам в первую очередь важно, чтобы в раздачах могли участвовать только зарегистрированные пользователи, и чтобы они соблюдали определённые правила. При первом обращении клиента частный трекер имеет возможность не допустить его к раздаче, просто не сообщая ему адреса других клиентов-участников. Поэтому для закрытого трекера важно, чтобы клиенты не получали эти адреса через DHT/PEX.
DHT и PEX появились в клиентах Azureus и BitComet примерно летом 2005 года. Администраторы многих частных трекеров были недовольны такой новой функциональностью, и поэтому стали запрещать на трекере эти новые версии клиентов.
Тогда разработчики клиентов предложили новый ключ внутри торрент файла: private. Если его значение равно единице, то клиент обязан для этого торрента автоматически отключать DHT/PEX независимо от желания пользователя. Такой торрент называют защищенным (англ. Secure Torrent ).
Практически все современные частные трекеры сами принудительно вставляют private:1 во все торренты, выкладываемые на трекере, а также запрещают несколько устаревших версий клиентов, поддерживающих DHT или PEX, но ещё не знающих про private key. Пользователи трекера просто не могут на раздачах использовать DHT/PEX, и проблемы нет.
Отметим, что присутствие private key изменяет infohash торрента, поэтому выреза́ть его из торрент файла бесполезно — другие клиенты изменённый торрент всё равно не признают.
Включение в клиенте [ править ]
Рассмотрим, как включается DHT в популярных клиентах Bitcomet и µTorrent.
DHT можно включить глобально в настройках клиента. При этом клиент подключается к DHT сети, статус подключения показан в самом низу окна клиента.
Затем в свойствах каждой отдельной задачи вы можете указать, использовать ли для этой задачи DHT сеть для нахождения новых пиров.
Если в свойствах задачи включить DHT нельзя, то это значит, что либо у вас выключено DHT глобально в клиенте, либо этот торрент — частный, то есть с private key внутри, и клиент не позволит использовать DHT или PEX.
µTorrent на вкладке «Пиры» показывает, получен ли каждый пир с трекера, через PEX или через DHT, с помощью флагов X (для PEX) и H (для DHT) в колонке «Флаги». Важно понимать, что обычно это разделение условное, один и тот же пир вполне может быть получен сначала одним, а потом другим способом.
Пользоваться ли [ править ]
Все ваши торренты — с частных трекеров
Если при этом в клиенте разрешить DHT, то получится, что клиент подключается к DHT сети, тратит на это трафик, помогает другим клиентам найти нужных им пиров, но ни на одной раздаче DHT для себя не использует. Если вы не хотите тратить лишний трафик, то видимо лучше DHT в клиенте отключить.
Вы качаете раздачу с публичного трекера
Если трекер возвращает вам много пиров и их достаточно для достижения хорошей скорости скачивания, то DHT/PEX вам вероятно не нужно. Если нет, то стоит попробовать их включить (и в клиенте и в свойствах раздачи), это может помочь найти больше источников.
Вы качаете раздачу с частного трекера без принудительного private key
Из крупных русскоязычных трекеров на конец 2006 года это торрентс.ру. Возможность использования на раздачах DHT/PEX на этих трекерах отдана на откуп раздающему (создателю торрента). С 2010 года на торрентс.ру и его преемнике рутрекер.орг возможность создания частных раздач закрыта.
Вообще говоря, такая ситуация не может быть признана нормальной, особенно на трекерах с системой passkey. Дело в том, что в клиентах BitComet, BitSpirit и Azureus через DHT пользователи могут узнать passkey других пользователей, и нечестные пользователи могут использовать чужие passkey для скачивания под чужой учетной записью. Поэтому по крайней мере в этих клиентах на таких трекерах рекомендуется DHT выключить.
DHT и статистика [ править ]
Этот раздел касается только частных трекеров, на которых private key в торренты принудительно не вставляется, и на некоторых раздачах (в зависимости от того, вставил ли раздающий сам в торрент private key) можно использовать DHT и PEX.
Часто встречается мнение, что включенный в клиенте DHT влияет на учет статистики клиента трекером, например «раздавал через DHT, значит статистика шла мимо трекера». Это неверно.
Во-первых, DHT/PEX используется только для получения адресов пиров. Ни файлообмена, ни какого-либо учета статистики по ним не ведётся. Клиент рапортует статистику скачанного и отданного только на трекер.
То есть «раздавал через DHT» фактически означает «о некоторых (или о всех) пирах получил информацию по DHT, и вероятно некоторые пиры тоже нашли меня через DHT»
Во-вторых, хотя клиенты обычно и знают, откуда ими получены адреса пиров, ни один клиент не разделяет трафик на «полученный/отданный DHT пирам» и «полученный/отданный пирам, полученным от трекера». Даже при желании это было бы клиенту сделать затруднительно — некоторые пиры могут быть получены и от трекера и через DHT или PEX, и часто клиент не знает, как его адрес получил пир, сам начинающий к нему соединение.
Клиент рапортует трекеру суммарные данные об объёмах им скачанного и отданного всем пирам, с которыми он общался, независимо от того, узнал клиент об отдельных пирах через трекер, DHT или PEX, или тот пир вообще начал соединение сам. То есть даже если из-за DHT/PEX на раздаче появятся «левые» пользователи (не обращающиеся к трекеру), клиент все равно сообщит на трекер все, что у них скачал и отдал.
Правильный учет статистики зависит только от состояния трекера: работает трекер — статистика учитывается, не работает — не учитывается. Только в случае длительно неработающего трекера DHT/PEX может играть косвенную роль, не давая постепенно затухнуть файлообмену на такой «раздаче без учета статистики».
Механизм работы DHT [ править ]
Реализация распределеной сети в БТ клиентах основана на варианте DHT, называемом Kademlia. А вообще говоря, DHT (Distributed hash table) означает децентрализованную распределенную систему для объединения большого количества постоянно исчезающих и появляющихся узлов и эффективной передачи сообщений между ними. На основе DHT структур строят разные более сложные системы, такие как P2P файлообмен, кооперативное веб кеширование, DNS сервисы и т. п.
DHT использует UDP протокол. БТ клиенты слушают тот же UDP номер порта, который они используют для входящих TCP соединений. Если вы активно используете DHT, то открытие этого UDP порта для доступа снаружи желательнo, но не обязательно — DHT будет работать и так.
Каждый подключенный БТ клиент является в DHT сети отдельным узлом. У него есть свой уникальный ID (идентификатор), случайно выбираемый из того же 160-битного пространства, что и infohash’ы торрентов.
Каждый узел хранит таблицу маршрутизации, содержащую контактную информацию о многих «ближайших» к нему узлах, и о нескольких более далеких. «Близость» двух узлов вычисляется из «сходства» их ID, и не имеет никакого отношения к их географической близости.
Когда узел хочет найти пиров для какой-то раздачи, он сравнивает infohash этой раздачи с ID известных ему узлов, и затем посылает запрос тому узлу, чей ID наиболее похож на этот infohash. Тот узел возвращает ему адрес узла, чей ID ещё ближе к infohash торрента.
Тогда наш узел посылает запрос тому новому узлу, и получает от него адрес следующего узла, чей ID ещё более похож на infohash торрента.
Таким образом, запросы от клиентов, участвующих в раздаче торрента с определённым infohash, постепенно стекаются к узлам, чьи ID наиболее похожи на этот infohash. Эти узлы помнят предыдущие запросы, и всем следующим запрашивающим узлам вернут адреса предыдущих пиров с той же раздачи.
