Я нахожусь в процессе реализации моего собственного dht для внутреннего кластера.Поскольку он будет использоваться в файлообменной программе, такой как bittorrent, «Mainline DHT» был первым, на что я обратил внимание.После этого я нашел «запутанный» (python, dht, использующий витую матрицу), конгресс (python, dht, использующий pyev + libev) и, конечно, оригинальный «kademlia».
У них разные подходы к организации k-сегментов:
1) конгресс, кадемля использует фиксированные 160 сегментов в диапазоне 2 * i <= (разница для каждого идентификатора от нас) <2 </em>* (i + 1), для 0 <= i<160. </p> 2) магистральные DHT и запутанные используют динамические сегменты.На старте у них всего 1 ведро, покрывающее все пространство.После того, как он будет заполнен 8 живыми узлами, ведро будет разделено на 2 новых.Но ТОЛЬКО если наш собственный идентификатор внутри этого ведра.Если это не так - ведро никогда не будет разделено.Итак, скоро у нас будет 160 ближайших к нам корзин и еще немного.
Оба варианта достаточно хороши.Но я обнаружил ОГРОМНОЕ различие в логике, которая обнаруживает, принадлежит ли какой-то идентификатор к некоторому сегменту или нет.И это мой вопрос.
конгресс и кадемлия рассматривают комплекты ковшей как «минимальное расстояние от нас» и «максимальное расстояние от нас».Таким образом, наш собственный идентификатор будет ВСЕГДА в bucket0.Максимум 2 других идентификатора в bucket1 (потому что он охватывает 2 * 1 <= x <2 </em>* 2 расстояния) будут ВСЕГДА ближе к нам.Так что мой мозг не ломается, потому что все в порядке.
Но если вы загляните в Mainline DHT или запутались, вы увидите, что пакеты корзин обрабатываются как пакеты с абсолютным идентификатором узла, а не как расстояние xor!Таким образом, в теоретически полных идентификаторах таблицы 0,1,2,3,4,5,6,7 будет в 1 сегменте.
Итак.Почему некоторые реализации рассматривают границы сегмента как «максимальное / минимальное расстояние от нас», а другие как «максимальное / минимальное 160-битное целочисленное значение» ??