为啥我从对等端接收的数据与预期输出不匹配？

Posted 2023-02-23

【中文标题】为啥我从对等端接收的数据与预期输出不匹配？

【英文标题】：Why doesn't the data I'm receiving from a peer match the expected output?为什么我从对等端接收的数据与预期输出不匹配？

【发布时间】：2011-09-18 17:07:22

【问题描述】：

在业余时间，我一直致力于用 C 语言实现一个 BitTorrent 客户端。目前它与跟踪器通信，连接到 swarm，从对等点请求 torrent 文件的片段，并接收 torrent 文件的片段。但是，在验证接收到的片段是否正确时（通过获取 SHA1 哈希并将其与 .torrent 元数据中提供的哈希进行比较），它总是失败。

为了调试它，我用一个已知工作的 BitTorrent 客户端下载了一个 torrent，然后修改了我自己的 BitTorrent 实现，只请求和下载 torrent 的开头（第一部分）。然后我将这两个文件与 Emacs 的 hexl-mode 进行了比较。

众所周知的：

00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
00008000: 0143 4430 3031 0100 4c49 4e55 5820 2020  .CD001..LINUX   
00008010: 2020 2020 2020 2020 2020 2020 2020 2020                  
00008020: 2020 2020 2020 2020 5562 756e 7475 2031          Ubuntu 1
00008030: 312e 3034 2069 3338 3620 2020 2020 2020  1.04 i386

我的实现：

00000000: a616 f132 7f00 0080 5066 0000 0000 0080  ...2....Pf......
00000010: 5066 0000 0000 0060 3b62 0000 0000 0098  Pf.....`;b......
00000020: 3b62 0000 0000 00d0 3b62 0000 0000 0008  ;b......;b......
00000030: 3c62 0000 0000 0040 3c62 0000 0000 0078  <b.....@<b.....x
00000040: 3c62 0000 0000 00b0 3c62 0000 0000 00e8  <b......<b......
00000050: 3c62 0000 0000 0020 3d62 0000 0000 0058  <b..... =b.....X
00000060: 3d62 0000 0000 0090 3d62 0000 0000 00c8  =b......=b......
00000070: 3d62 0000 0000 0000 3e62 0000 0000 0038  =b......>b.....8
...
0000d000: 0243 4430 3031 0100 004c 0049 004e 0055  .CD001...L.I.N.U
0000d010: 0058 0020 0020 0020 0020 0020 0020 0020  .X. . . . . . . 
0000d020: 0020 0020 0020 0020 0055 0062 0075 006e  . . . . .U.b.u.n
0000d030: 0074 0075 0020 0031 0031 002e 0030 0034  .t.u. .1.1...0.4
0000d040: 0020 0069 0033 0038 0000 0000 0000 0000  . .i.3.8........

然后，我认为我必须将接收到的片段写入错误的偏移量，从而导致正确的数据出现在文件中的错误位置。为了验证这一点，我启动了 gdb 并在从对等点接收到第一个片段后检查了它的开头，期望它包含全零，就像已知良好文件的开头一样。

(gdb) break network.c:40
Breakpoint 1 at 0x402fe7: file network.c, line 40.
(gdb) run
Starting program: /home/robb/slug/slug 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffcb58d700 (LWP 12936)]
[Thread 0x7fffcb58d700 (LWP 12936) exited]
ANNOUNCE: 50 peers.
CONNECTED: 62.245.41.28
CONNECTED: 89.178.142.45
CONNECTED: 66.65.166.17
...
UNCHOKE: 95.26.0.1
Requested piece 0 from peer 95.26.0.1.
UNCHOKE: 202.231.116.163
PIECE: #0 from 95.26.0.1

Breakpoint 1, handle_piece (p=0x42d7e0) at network.c:41
41       memcpy(p->torrent->mmap + length, &p->message[9], REQUEST_LENGTH);
(gdb) p off
$1 = 0
(gdb) p index
$2 = 0
(gdb) p p->message[9]
$3 = 46 '.'
(gdb) p p->message[10]
$4 = 67 'C'
(gdb) p p->message[11]
$5 = 0 '\000'
(gdb) p p->message[12]
$6 = 0 '\000'
(gdb) p p->message[13]
$7 = 0 '\000'
(gdb) p p->message[14]
$8 = 0 '\000'
(gdb) p p->message[15]
$9 = 0 '\000'
(gdb) p p->message[16]
$10 = 128 '\200'
(gdb) p p->message[17]
$11 = 46 '.'
(gdb) p p->message[18]
$12 = 67 'C'

如您所见，我从对等方收到的数据并不像 known-good 文件的开头那样包含全零。为什么？

我的程序的完整源代码可在https://github.com/robertseaton/slug 获得。

【问题讨论】：

这有点大，这里有人给你调试。您不能将代码简化为网络 IO（如果这就是问题所在？）。您是否在 bufferevent_read() 调用后立即进行了调试，因为这是您收到的内容，而您的代码没有任何其他更改。您是否验证了用于调用它的参数？当 network.c get_msg() 第 55 行 bufferevent_read() 失败时会发生什么？它返回-1吗？这可能就是为什么你的“LINUX”字符串字节都被加宽了。还有 network.c read_prefix() 第 78 行，您正在阅读 &p->message_length - 对吗？

不清楚您是如何接收数据的。您是否考虑了小端和大端编码。互联网协议总是以大端编码传输数据。

您似乎同时拥有 64 位位域（“global_bitfield）和 8 位位域（主要是时间），都只使用了一位。您还有 8 位位域，所有位都被使用了。我假设协议在消息中使用了它可以使用的所有位，但是为什么在收到它们时将它们分散开来？如果我错了，请纠正我。

64 位的 global_bitfield 保存了所有位域的组合信息，因此可能会使用超过 1 位。我在接收位域时展开位域的原因只是为了让我可以通过使用数组寻址轻松检查是否设置了位。我将来可能会改变这一点。

【参考方案1】：

这没有考虑到 bufferevent_read 可能会失败并返回负数：

void get_msg (struct bufferevent* bufev, struct Peer* p)

     uint64_t amount_read = p->message_length - p->amount_pending;
     int64_t message_length = bufferevent_read(bufev, &p->message[amount_read],  p->amount_pending);

替换为：

void get_msg (struct bufferevent* bufev, struct Peer* p)

 uint64_t amount_read = p->message_length - p->amount_pending;
 int64_t message_length = bufferevent_read(bufev, &p->message[amount_read], p->amount_pending);

 /* possible bufferevent_read found nothing */
 if (message_length < 0)
      message_length = 0;

【讨论】：

我想你的意思是 if(message_length

【参考方案2】：

阅读我在network.c中找到的源代码：

memcpy(&index, &p->message[1], sizeof(index));
memcpy(&off, &p->message[5], sizeof(off));

index = ntohl(index);
off = ntohl(off);
length = index * p->torrent->piece_length + off;

#ifdef DEBUG
if (off == 0)
   printf("PIECE: #%d from %s\n", index, inet_ntoa(p->addr.sin_addr));
#endif

memcpy(p->torrent->mmap + length, &p->message[9], REQUEST_LENGTH);
p->torrent->pieces[index].amount_downloaded += REQUEST_LENGTH;

我认为最后两行是：

memcpy(p->torrent->mmap + length, &p->message[9], length);
p->torrent->pieces[index].amount_downloaded += length;

顺便说一句，REQUEST_LENGTH = 16K。 更有可能这个“长度的东西”应该是 p->message_length，或者 (p->message_length - 9)

另一个 bug 可能是 strlen()+1 类型的 bug。