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協議的一部分，應該甚至沒有擴展名。

輸出似乎是不準確的，儘管因爲這些數組的長度是可變的，儘管指定的大小對於每一行都是相同的。所以有可能字節流解析器不能根據長度正確地分片消息。