有人能说出这个奇怪的DHT响应是什么意思吗？

Question

有时我会收到来自其他节点的奇怪回应。事务ID匹配了我的请求事务ID以及远程IP，所以我倾向于认为，节点回应这一点，但它看起来像某种反应的混合的，并要求

d1:q9:find_node1:rd2:id20:.éV0özý.?tj­N.?.!2:ip4:DÄ.^7:nodes.v26:.ï?M.:iSµLW.Ðä¸úzDÄ.^æCe1:t2:..1:y1:re 

最糟糕的是，它是畸形。看看7：nodes.v这意味着我将nodes.v添加到字典中。它应该是5：节点。所以，我迷路了。它是什么？

Answer 1

互联网和远程节点是不可靠的或越野车。你必须防守编码。不要以为你收到的每件东西都是有效的。

远程端可能

• 发送无效bencoding，抛弃那些，甚至不尝试恢复。
• 发送截断的消息。通常无法恢复，除非碰巧是根词典的最后一个e。
• 忽略强制性密钥。您可以忽略这些消息或返回错误消息
• 包含损坏的数据
• 包含超出强制值的未知密钥。这是不是一个错误，只是对待他们，好像他们是不是有向前兼容的缘故
• 实际上是攻击者试图模糊测试您的实现或用你们的DoS放大器

我还怀疑一些真正的劣质实现基于他们的编程语言支持的任何string类型，并错误地处理编码而不是使用uint8的数组作为本码编码要求。对这些没有什么可以做的。忽略或偶尔发送错误消息。

指定的字典键是通常是 ASCII-mappable，但这不是必需的。例如。有一些实际使用随机二进制数据作为字典键的跟踪器响应类型。

---

下面是我看到的垃圾的几个例子^[1]，即使失败bdecoding：

d1:ad2:id20:�w)��-��t����=?�������i�&�i!94h�#7U���P�)�x��f��YMlE���p:q9Q�etjy��r7�:t�5�����N��H�|1�S� 
d1:e�����������������H# 
d1:ad2:id20:�����:��m�e��2~�����9>inm�_hash20:X�j�D��nY��-������X�6:noseedi1ee1:q9:get_peers1:t2:�=1:v4:LT��1:y1:qe 
d1:ad2:id20:�����:��m�e��2~�����9=inl�_hash20:X�j�D��nY���������X�6:noseedi1ee1:q9:get_peers1:t2:�=1:v4:LT��1:y1:qe 
d1:ad2:id20:�����:��m�e��2~�����9?ino�_hash20:X�j�D��nY���������X�6:noseedi1ee1:q9:get_peers1:t2:�=1:v4:LT��1:y1:qe 

^[1]保存字符数。用unicode替换字符替换所有不可打印的，与ASCII不兼容的字节。