2

有时我会从其他节点收到这种奇怪的响应。事务 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:nodes。所以，我迷路了。它是什么？

4

1 回答 1

3

互联网和远程节点不可靠或有故障。您必须进行防御性编码。不要假设您收到的所有内容都是有效的。

远程对等体可能

  • 发送无效的编码，丢弃那些，甚至不要尝试恢复。
  • 发送截断的消息。通常无法恢复，除非它恰好是e根字典的最后一个。
  • 省略强制键。您可以忽略这些消息或返回错误消息
  • 包含损坏的数据
  • 包括强制性密钥之外的未知密钥。这不是错误，只是为了向前兼容而将它们视为不存在
  • 实际上是攻击者试图模糊您的实现或将您用作 DoS 放大器

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

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

以下是我看到的一些垃圾示例[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 不兼容的字节。

于 2015-07-10T21:35:12.967 回答