BitTorrent协议：为什么我通过握手获取额外的数据？

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

指定为BEP3 “位字段”。即这是核心BitTorrent协议的一部分，应该甚至没有扩展名。

输出似乎是不准确的，尽管因为这些数组的长度是可变的，尽管指定的大小对于每一行都是相同的。所以有可能字节流解析器不能根据长度正确地分片消息。