这个 BitTorrent 客户端的片段验证过程中的错误在哪里？

Question

我一直在业余时间用 C 语言编写 BitTorrent 客户端。然而，看似随机，我的客户将无法验证收到的 torrent 片段是否正确，并显示以下消息：

Failed to verify piece: #4

背景：.torrent 文件包含要下载的文件的相关元数据，包括 SHA1每个片段（要下载的文件的一个块）的哈希值，因此，在下载一个片段后，我获取其 SHA1 哈希值，并将其与 torrent 元数据文件提供的哈希值进行比较。

下面是处理验证的代码：

 int verify_piece (void* addr, uint64_t piece_length, unsigned char* piece_sha)
 {
     SHA_CTX sha;
     unsigned char sha1result[20];

     SHA1_Init(&sha);
     SHA1_Update(&sha, addr, piece_length);
     SHA1_Final(sha1result, &sha);

     if (memcmp(sha1result, piece_sha, 20)) {
          printf("Expected: ");
          print_sha1(piece_sha);
          printf("Received: ");
          print_sha1(sha1result);
          return 0;
     } else
          return 1;
  }

为了追踪错误，我安装了两个函数：write_in Correct_piece() 和 write_ Correct_piece()。当 verify_piece() 失败时，将调用第一个函数 write_in Correct_piece()。它将验证失败的部分写入文件，以便我可以使用 hexdump 检查它。

 void write_incorrect_piece (void* piece, uint32_t piece_length, uint32_t index)
 {
     FILE* failed_piece = fopen("failed_piece.out", "w+");

     write(fileno(failed_piece), piece, piece_length);
     fclose(failed_piece);
     printf("ERROR: Wrote piece #%d to failed_piece.out for inspection with hexdump.\n",
            index);

     write_correct_piece(piece_length, index);
     exit(1);
 }

正如你所看到的，write_in Correct_piece()采用参数void*piece，这是一个指向验证失败的片段的指针，uint32_tpiece_length，这是片段的长度，uint32_t index 是验证失败的片段的索引。然后，它将错误的片段复制到名为 failed_piece.out 的文件中。

您会注意到，在调用 exit() 之前，write_in Correct_piece() 会调用函数 write_ Correct_piece()。这是我为帮助调试此错误而编写的第二个函数。它采用 torrent 客户端尝试下载的文件的已知良好版本 (known_good.iso)，然后将相关片段复制到文件 ( Correct_piece.out) 中，以便我可以将其与包含错误片段的文件进行比较。

void write_correct_piece (uint32_t piece_length, uint32_t index)
{
     FILE* known_good = fopen("known_good.iso", "r+");
     FILE* correct_piece = fopen("correct_piece.out", "w+");

     /* get file size for MMAPing */
     struct stat st;
     stat("known_good.iso", &st);
     long size = st.st_size;

     void* addr = mmap(0,
                       size,
                       PROT_READ | PROT_WRITE,
                       MAP_SHARED,
                       fileno(known_good),
                       0);

     write(fileno(correct_piece), addr + piece_length * index, piece_length);
     munmap(addr, size);
     fclose(known_good);
     fclose(correct_piece);
}

然后，我取出这两个写入的文件，并使用 hexdump 对其进行格式化，以便输出是人类可读的，然后尝试通过 diff 比较它们，就像这样

$ hexdump failed_piece.out > failed_piece.dump
$ hexdump correct_piece.out > correct_piece.dump
$ diff correct_piece.dump failed_piece.dump

令我惊讶的是，diff 没有输出任何内容。这些文件完全相同。那么，为什么该片段的 SHA1 哈希值与 torrent 文件所期望的不同呢？我随后想，也许元数据文件中的 SHA1 哈希值不正确。如果是这样的话，我希望客户端总是无法验证第 4 部分，因此我修改了 torrent 客户端的调度程序，只尝试下载第 4 部分，看看它是否确实总是无法验证。

Successfully downloaded piece: #4

卧槽？现在我陷入了僵局。我认为可能有几个不同的原因导致了这种情况：

• 客户端的网络代码中实际上存在一个错误，但我在 write_in Correct_piece() 和 write_ Correct_piece() 中引入了一个错误> 这样无论输入的完整性如何，它都会生成两个相同的文件。
• verify_piece() 中存在错误，导致其偶尔失败。
• 我没有考虑到一些事情。

然而，在我的一生中，我找不到上述任何代码的任何问题，所以我希望你们好心人能够指出我所缺少的内容。

客户端的完整源代码位于 https://github.com/robertseaton/slug。

编辑：在 verify_piece() 中将 strncmp() 替换为 memcmp() 并清理了 write_in Correct_piece () 和 write_ Correct_piece()。

编辑：这是一个失败片段上的 SHA1 哈希值示例，当我手动比较它时，它看起来是正确的。正如您所看到的，哈希值根本不相似：

Expected: 239 66 216 164 16 120 73 24 1 236 116 173 144 85 243 152 160 165 64 231 
Received: 214 94 49 185 54 159 255 201 214 137 102 23 223 76 102 138 89 94 154 69 
Failed to verify piece: #13

Answer 1

好的，如果我们看一下 verify_piece() 的调用，我们会看到以下内容：

 if (verify_piece(p->torrent->mmap + index * p->torrent->piece_length,
     p->torrent->piece_length, p->torrent->pieces[index].sha1)) {

现在，我们简单地知道第一个和第二个参数是正确的，因为稍后程序调用时会重用它write_in Correct_piece() 我们已经验证了它的输出是正确的。因此，我们可以专注于第三个参数，p->torrent->pieces[index].sha1。

乍一看，该参数看起来是正确的，因为我们在整个函数中使用了 index。但是，请考虑一下，如果 index （虽然在正确排序的数组上完全有效）被用作不再包含假定顺序的片段的数组的索引，该怎么办？

Viola！ 罪魁祸首（在 __schedule() 中）：

qsort(t->pieces, t->num_pieces, sizeof(struct Piece), rarest);

注释掉对 qsort() 的调用，客户端就会按预期运行。