DHT: BitTorrent vs kademlia vs clones (python)

Я занимаюсь реализацией своего собственного dht для внутреннего кластера. Поскольку он будет использоваться в программе обмена файлами, такой как bittorrent,« Mainline DHT »было первым, на что я обратил внимание. at. После этого я нашел «запутанный» (python, dht с использованием скрученной матрицы), конгресс (python, dht с использованием pyev + libev) и, конечно же, оригинальный «kademlia».

У них разные подходы к организации k-ведер:

1) конгресс, кадемлиа используют фиксированные 160 сегментов в диапазоне 2 * i <= (разница для каждого идентификатора от нас) <2 * (i + 1), для 0 <= i <160.

2) основной DHT и запутанный используют динамические корзины. На старте у них есть только 1 ведро, покрывающее все пространство. После того, как оно будет заполнено 8 активными узлами, ведро будет разделено на 2 новых. Но ТОЛЬКО если наш собственный идентификатор внутри этого ведра . Если это не так - ведро никогда не будет разделено. Итак, скоро у нас будет 160 ближайших к нам ведер и несколько других.

Оба варианта достаточно хороши. Но я обнаружил ОГРОМНУЮ разницу в логике, которая определяет, что ngs какой-то идентификатор в какое-то ведро или нет. И это мой вопрос.

конгресс и кадемлия трактуют связки ведер как «минимальное расстояние от нас» и «максимальное расстояние от нас». Итак, наш собственный идентификатор ВСЕГДА будет в bucket0.Максимум 2 других идентификатора в bucket1 (поскольку он покрывает 2 * 1 <= x <2 * 2 расстояния) ВСЕГДА будут ближайшими к нам. Так что мой мозг не ломается, потому что все в порядке.

Но если вы посмотрите на Mainline DHT или запутанный, вы увидите, какие пакеты сегментов обрабатываются как пакеты с абсолютным идентификатором узла, а не как расстояние xor! Таким образом, в теоретически полной таблице идентификаторы 0,1,2,3,4,5,6,7 будут в 1 ведре.

Итак. Почему одни реализации трактуют границы сегмента как «максимальное / минимальное расстояние от нас», а другие - как «максимальное / минимальное 160-битное целочисленное значение» ??