Протокол KRPC ведет себя странно в BEP-05

Согласно BEP-05, когда вы запускаете запрос find_node или get_peers, вы получите сообщение запроса или K (8) хороших узлов, ближайших к цели/информационному хешу.

Однако в моем случае с загрузочным узлом router.utorrent.com:6881 удаленный сервер вернул 8 узлов, ближайших к собственному nodeId. И если это запрос get_peers, он всегда возвращает 8 узлов, ближайших к себе, и 7 недействительных узлов. Но если доступ к какому-то специальному узлу, который перенаправляется на ближайший к инфохешу, протокол работает нормально.

wireshark

странный дамп wireshark

успешный дамп wireshark

Любая помощь будет оценена по достоинству!


torrent bittorrent dht
person J.Doe    schedule 01.02.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

Также не имеет смысла связываться с узлом начальной загрузки через get peers. Запросы find node будут правильным выбором для заполнения таблицы маршрутизации. И связываться с ними необходимо только в относительно редком случае, когда #11089702">другие механизмы не сработали.

person the8472    schedule 01.02.2019
comment
Извините, моя ситуация такова: в запросе find_node/get_peers многие узлы возвращали информацию об узлах, ближайших к узлу запроса, который должен быть ближайшим к целевому узлу. Проблема не в узлах начальной загрузки. Вы можете проверить странный дамп wireshark. благодаря. - person J.Doe; 15.02.2019