Почему DHT хеширует имена файлов?

Но почему он должен хешировать имя файла?

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

Разве он не мог работать просто как словарь, поэтому вместо того, чтобы иметь хеш-значения узла между 0000 и 0a2d, он мог бы хранить значения имени файла между C и E?

Поскольку имена файлов не распределены равномерно по всему возможному пространству ключей (как часто вы видите, что имена файлов начинаются с какого-то экзотического символа Юникода?), А их энтропия распространяется по переменной длине, что приводит к еще большей кластеризации на верхнем уровне. Если бы вы проиндексировали все существующие файловые системы unix в мире, у вас была бы массивная кластеризация, например, вокруг префикса /etc/....

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

потому что поиск ведется по номерам.

Когда вы хешируете файл, вы получаете номер, и этот номер будет размещен в ближайших K-сегментах ближайших K-одноранговых узлов.

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

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

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

Я рекомендую вам прочитать эти заметки о том, как на самом деле работает настоящий DHT. https://gist.github.com/gubatron/cd9cfa66839e18e49846

Кроме того, сохранение числа занимает намного меньше места, чем сохранение слова.

Если вы знаете слово, вы можете хешировать его и искать по хешу.

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

Одно свойство, которое дает вам хеширование (вместе с метрикой расстояния XOR), - это равномерное распределение контента между всеми узлами, участвующими в DHT. "Даже" здесь ограничено тем, как работает структура данных k-bucket (вот обзор k-bucket slides), но в совокупности вы получаете узлы, равномерно распределяющие данные между участниками DHT ... теоретически. На практике можно получить точки доступа.

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

Я рассматривал то, что вы предлагаете раньше, как префикс к хешу SHA-1. Итак, что-то вроде node1-cd9cf ... (на самом деле префикс может быть любым, не обязательно, чтобы он был удобочитаемым). Это гарантирует, что все вещи с этим префиксом в значительной степени окажутся на узле, который идентифицирует себя с идентификатором, начинающимся с «node1-». Но вам понадобится реализация DHT (включая реализацию k-bucket), которая поддерживает идентификаторы переменной длины. В этом случае вы гарантируете точку доступа. Это эквивалент искусственного обеспечения того, чтобы объекты были «близко друг к другу», поскольку разница между ними в метрике XOR очень мала. Зачем кому-то это нужно? Например: com.example.www-cd9cf ... в сочетании с некоторой криптографией может гарантировать, что пока вы участвуете в DHT, данные хранятся на ваших серверах. Однако я не видел этого раньше.