Я читал о Kademlia и понял основные концепции этого. Основные концепции BitTorrent также просто понятны. Но оба они вместе не имеют никакого смысла.
Из того, что мне удалось найти в сети, хэш файла цели используется для генерации идентификатора цели для поиска в DHT, затем этот поиск должен найти пиры, близкие к идентификатору цели. Хорошо, имеет смысл. За исключением того, что это совсем не так, как пир, у которого идентификатор близок к идентификатору цели, может знать что-либо о сидах или других пирах в сети?
Любая попытка исследовать релевантность привела к тому же объяснению, что алгоритм DHT использует свою кадемичность, чтобы добраться до пира, идентификатор пира которого близок к целевому идентификатору, но это не отвечает на вопрос.
решение1
Насколько я понимаю, «пир с целевым идентификатором» знает о сидах или других пирах, потому что эти пиры также использовали точно такую же процедуру длямагазининформация о себе в этом месте. Пир с этим ID — это просто место, о котором все остальные пиры договорились, чтобы хранить/извлекать данные, связанные с чем-то или чем-то.
DHT — это «распределенная хэш-таблица», где «хеш-таблица" означает структуру данных, которая хранит сопоставления {ключ⇒значение} (также называемую словарем, ассоциативным массивом, таблицей поиска и т. д.). Программа, использующая хеш-таблицу, можетположить(ключ, значение)и хеш-таблица сохраняет информацию {ключ⇒значение} по адресу X; затем другая часть программы можетполучить(ключ)и хеш-таблица извлекает значение из адреса X.
Когда типичная хеш-таблица используется внутри программы, она будет использовать похожую процедуру для генерации ячейки памяти для заданного ключа поиска, когда он хранится (хэш), и делать то же самое, когда его нужно извлечь. Базы данных, файловые системы, Git и т. д. также делают то же самое на разных уровнях; например, .git/objects/ в Git.
DHT — это то же самое, только на сетевом уровне («распределенная» часть). Хотя DHT BitTorrent знает некоторые специфичные для BT вещи, по сути он просто хранит данные, которые клиенты BitTorrent должны хранить в согласованном месте. Как говорится в спецификации Kad:
Чтобы сохранить пару <ключ, значение>, участник находит...
Это означает, что в общих чертах его можно интегрировать в протокол обмена файлами следующим образом:
Исходный узел S (на котором находится файл) вычисляет идентификатор и отправляет операцию «Сохранить» через сеть DHT, сохраняя информацию {ключ: fileID ⇒ значение: «доступно на узле S»}, которая отправляется на любой узел X, ближайший к ключу (fileID).
Затем информация {ключ: fileID ⇒ значение: «доступно на узле S»} сохраняется на узле X.
Другой одноранговый/клиентский узел C узнает идентификатор файла и отправляет операцию «Извлечь» через сеть DHT, которая извлекает значение «доступно на узле S» из узла X.
TheBitTorrent DHTреализовано аналогично этому примеру, только вызывается операция «сохранить» announce_peer, и она не перезаписывает значение полностью, а только добавляет данные диктора в уже сохраненный список пиров.