Ближайшие два хороших узла kademlia недостаточно пересекаются между двумя запросами

Question

Работая над реализацией bep44, я использую определенный алгоритм kademlia, чтобы найти ближайший хороший узел с заданным хеш-идентификатором.

Используя мою программу я делаю go run main.go -put "Hello World!" -kname mykey -salt foobar2 -b public и получить значение, хранящееся более ста узлов (хорошо).

Теперь, когда я запускаю его несколько раз подряд, наборы ip, которые записываются пут-запросами, плохо пересекаются.

Это проблема, так как, когда я пытаюсь сделать запрос get, набор запрашиваемых ips не пересекается с положенным набором, поэтому значение не найдено.

В моих тестах я использую публичный узел начальной загрузки dht

        "router.utorrent.com:6881",
        "router.bittorrent.com:6881",
        "dht.transmissionbt.com:6881",

Когда я запрашиваю узлы, я выбираю 8 ближайших узлов (nodes := s.ClosestGoodNodes(8, msg.InfoHash())), которые обычно заканчиваются списком запросов ~1K после рекурсивного обхода.

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

Как это происходит, набор узлов магазина не пересекается?

Answer 1

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

Если узел возвращает token, v или же seq поле в ответе get, тогда он подходит для ближайшего набора только для чтения.

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

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

Кроме того, вам также нужно учитывать ошибки или отсутствие ответа при выполнении put Запросы. Вы можете либо повторить попытку узла, либо попробовать следующий подходящий узел.

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

которые обычно заканчиваются списком запросов ~1K после рекурсивного обхода.

Это говорит о том, что что-то не так с вашим алгоритмом поиска. По моему опыту, поиск должен занимать где-то от 60 до 200 запросов udp, чтобы найти свою цель, если вы выполняете поиск с одновременными запросами, возможно, даже меньше, если он последовательный.

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

В моих тестах я использую публичный узел начальной загрузки dht

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