Это может быть злонамеренный узел, который не поддерживает согласованность идентификатора своего узла, пытаясь получить как можно больше таблиц маршрутизации. Это может быть сделано для сбора данных или усиления DoS.
Как правило, не следует слишком доверять чему-либо, что удаленные узлы сообщают и обрабатывают данные. В случае несогласованности его идентификатора вы должны удалить его из таблицы маршрутизации и игнорировать результаты, возвращаемые в его запросах. Я перечислил несколько возможных подходов дезинфекции за пределами BEP42 в документации моей собственной реализации DHT .
Другая возможность состоит в том, что узел B просто изменил свой идентификатор в Тем временем (например, из-за перезапуска) и узел A либо еще не обновил его, либо неправильно отслеживает изменения ID. Но это не должно происходить слишком часто.
И я вижу, что это не индивидуальный случай.
В целом, я бы ожидал такого поведения только от крошечной общей доли сети. Таким образом, вы должны сравнить количество уникальных IP-адресов, отправляющих поддельные ответы, с количеством уникальных IP-адресов, отправляющих вменяемые. Легко получить неправильную статистику такого рода, если ваша реализация наивна и захвачена вредоносными узлами для связи с еще большим количеством вредоносных узлов.
Но во время поиска вы можете увидеть это чаще на этапе терминала, когда вы получаете загрязненные данные от узлов, которые не очищают свою таблицу маршрутизации должным образом. Как один из примеров, старые версии libtorrent этого не сделали (см. Связанную проблему ; обратите внимание, что я не выделяю libtorrent здесь, многие реализации дурацкие в этой области).