Почему данные, которые я получаю от партнера, не соответствуют ожидаемому результату? - PullRequest
Новая
       13

Почему данные, которые я получаю от партнера, не соответствуют ожидаемому результату?

1 голос
/ 18 сентября 2011

В свое свободное время я работал над реализацией клиента BitTorrent на C. В настоящее время он связывается с трекером, подключается к рою, запрашивает части торрент-файла у пиров и получает части торрент-файла. Однако, когда дело доходит до проверки правильности полученного фрагмента (взяв хеш SHA1 и сравнив его с хешем, указанным в метаданных .torrent), он всегда завершается неудачей.

Для отладки я загрузил торрент с известным клиентом BitTorrent, а затем изменил собственную реализацию BitTorrent, чтобы запрашивать и загружать только самое начало торрента (первый фрагмент). Затем я сравнил два файла в hexl-режиме Emacs.

Известный товар: 

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'

Как видите, данные, которые я получил от однорангового узла, не содержат все нули, как начало файла с заведомо исправным кодом. Почему?

Полный источник моей программы доступен по адресу https://github.com/robertseaton/slug.

Ответы [ 2 ]

1 голос
/ 19 сентября 2011

Не учитывается, что 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;
0 голосов
/ 20 сентября 2011

Читая источник, я нашел это в 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;

BTW REQUEST_LENGTH = 16K.Скорее всего, эта "длина-вещь" должна быть p-> message_length или (p-> message_length - 9)

Другой ошибкой, вероятно, является ошибка типа strlen () + 1.

...