Question

我正在实施BitTorrent客户端，而且我在处理传入的握手消息时遇到问题。

即使我将所有保留字节设置为0（表示我不支持任何扩展），我也会在握手消息中附加大量数据。例如：

[2014-11-21 13:41:30 EET : Rho.PeerComms : WARNING] Extra message: [0,0,0,52,5,255,255,255,255,255,255,255,255,247,255,251,247,238,191,239,253,253,255,247,191,223,239]
[2014-11-21 13:41:33 EET : Rho.PeerComms : WARNING] Extra message: [0,0,0,52,5,255,255,255,127,255,255,254,255,253,255,255,255,255,255,255,253]
[2014-11-21 13:41:37 EET : Rho.PeerComms : WARNING] Extra message: [0,0,0,52,5,255,127,239,255,255,253,255,255,255,255,251,255,255,223,251,95,127,255,255,255,255,127,255,183,255,253,255,251,239,253,252,239,223,247,255,255,255]
[2014-11-21 13:41:37 EET : Rho.PeerComms : WARNING] Extra message: [0,0,0,52,5,254,255,255,247,255,255,255,255,255,255,235,255,255,63,127,255,239,127,255,255,239,255,239,255,223,254,255,255,255,255,255,255,251,251,255,255,127,255,249,255,239,255,191,191,255,255,239,191,255,247,252,0,0,0,5,4,0,0,1,121,0,0,0,5,4,0,0,0,105,0,0,0,5,4,0,0,0,207,0,0,0,5,4,0,0,0,104,0,0,0,5,4,0,0,0,85,0,0,0,5,4,0,0,1,32,0,0,0,5,4,0,0,1,53,0,0,0,5,4,0,0,1,67,0,0,0,5,4,0,0,0,131,0,0,0,5,4,0,0,0,136,0,0,0,5,4,0,0,1,140,0,0,0,5,4,0,0,1,89,0,0,0,5,4,0,0,1,54,0,0,0,5,4,0,0,1,81,0,0,0,5,4,0,0,0,83,0,0,0,5,4,0,0,1,5,0,0,0,5,4,0,0,0,112,0,0,0,5,4,0,0,1,13,0,0,0,5,4,0,0,0,7,0,0,0,5,4,0,0,0,194,0,0,0,5,4,0,0,0,28,0,0,0,5,4,0,0,0,179,0,0,0,5,4,0,0,0,163,0,0,0,5,4,0,0,1,115]
[2014-11-21 13:41:40 EET : Rho.PeerComms : WARNING] Extra message: [0,0,0,52,5,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,252]

这些是握手消息后的数据。例如：<pstrlen><pstr><reserved><info_hash><peer_id><extra>此消息格式的附加部分。

任何想法是什么，我应该如何使用它们以及为什么我会得到它们？

感谢。

Answer 1

0,0,0,52 4字节消息长度

,5消息ID

指定为＆＃34;位域＆＃34;在BEP3。即这是核心bittorrent协议的一部分，即使没有扩展也应该是预期的。

输出似乎不准确，尽管这些数组的长度可变，尽管每条线的指示大小相同。因此，字节流解析器可能无法根据长度正确地对消息进行切片。

BitTorrent协议：为什么我用握手获得额外数据？

1 个答案: