I am implementing a bittorrent client to learn that protocol and practice code, in Elixir.
I am testing my client with Transmission as a seed on a local tracker.
I can successfully handshake Transmission, receive its bitfield (full) and send mine (all zeros) and send the "interested" message, and Transmission unchokes me.
Then I am sending those two chunk requests:
<<6, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 64, 0>> # index: 2, begin: 0, length: 16384
<<6, 0, 0, 0, 2, 0, 0, 64, 0, 0, 0, 64, 0>> # index: 2, begin: 16384, length: 16384
Edit: in hex that is (again without the length prefix on four bytes):
06 00 00 00 02 00 00 00 00 00 00 40 00
06 00 00 00 02 00 00 40 00 00 00 40 00
I am not showing the length prefix as it is handled automatically by the T̶C̶P̶ ̶l̶a̶y̶e̶r̶ gen_tcp library configured with {packet, 4} except for the handshake where it is just 19. It works for all other messages.
To me it looks fine: 6 on one byte, then the piece index (2 here) on four bytes, and the offset and length on four bytes each.
In the Transmission peers view, I can see myself, with no requests, and the ?I flags where ? means that I am not choked (true) and not interested (false, as I send the "interested" message which is just <<2>> (and the length prefix)).
Can you spot anything that I am doing wrong? Or maybe I skipped a step?
After sending those two requests nothing happens, then I receive like four keepalive empty messages from Transmission and finally Transmission closes the connection.
Thank you.
PS: I saw another question here but it was because the chunk size were not proper. Here my torrent is 161920 bytes long and the piece length is 32768. It's a single file.
I don't see any issue. A common way of debugging bittorrent clients is using wireshark which has a protocol dissector for bittorrent which works as long as the TCP connection has been captured from the beginning. With that you can see what actually goes over the wire. For comparison you could also look at two working bittorrent clients talking to each other (although they're likely to use some extensions on top of the vanilla BEP3 protocol).
Transmission sending keep-alives suggests that it didn't run into a protocol violation that would result in an immediate disconnect and instead is still waiting on something.