2

I'm writing a small app to test out how torrent p2p works and I created a sample torrent and am seeding it from my Deluge client. From my app I'm trying to connect to Deluge and download the file.

The torrent in question is a single-file torrent (file is called A - without any extension), and its data is the ASCII string Test.

enter image description here

Referring to this I was able to submit the initial handshake and also get a valid response back.

Immediately afterwards Deluge is sending even more data. From the 5th byte it would seem like it is a bitfield message, but I'm not sure what to make of it. I read that torrent clients may send a mixture of Bitfield and Have messages to show which parts of the torrent they possess. (My client isn't sending any bitfield, since it is assuming not to have any part of the file in question).

If my understanding is correct, it's stating that the message size is 2: one for identifier + payload. If that's the case why is it sending so much more data, and what's that supposed to be?

Same thing happens after my app sends an interested command. Deluge responds with a 1-byte message of unchoke (but then again appends more data).

And finally when it actually submits the piece, I'm not sure what to make of the data. The first underlined byte is 84 which corresponds to the letter T, as expected, but I cannot make much more sense of the rest of the data.

Note that the link in question does not really specify how the clients should supply messages in order once the initial handshake is completed. I just assumed to send interested and request based on what seemed to make sense to me, but I might be completely off.

Zuiq Pazu
  • 285
  • 1
  • 4
  • 12

1 Answers1

2

I don't think Deluge is sending the additional bytes you're seeing.

If you look at them, you'll notice that all of the extra bytes are bytes that already existed in the handshake message, which should have been the longest message you received so far.

I think you're reading new messages into the same buffer, without zeroing it out or anything, so you're seeing bytes from earlier messages again, following the bytes of the latest message you read.

Consider checking if the network API you're using has a way to check the number of bytes actually received, and only look at that slice of the buffer, not the entire thing.

Jeremy
  • 1
  • 85
  • 340
  • 366
  • You're absolutely right. Now I feel like an idiot for asking. Thanks for the sanity-check. – Zuiq Pazu Jun 13 '18 at 20:37
  • @ZuiqPazu You're welcome. Good luck! It's too bad that more BitTorrent clients don't have detailed logs available to the user; I had a hard time figuring out what they were trying to send me a few times. Also, although I haven't used it, I have heard that [the WireShark BitTorrent plugin](https://wiki.wireshark.org/BitTorrent) can be very helpful, so consider looking into that if you have trouble. Cheers. – Jeremy Jun 13 '18 at 20:39