How would you go about testing this implementation in a robust manner? Seems difficult to create all the edge cases of disconnections, retransmissions, etc.
One architecture optimization (dont really know what to call this) i would make is to have a function called download block range and have that be where you deal with all the complex logic that you dealt with in downloaded. Then download all would just call the entire range and for any specific set of files you would figure out what blocks you need. Now, becuase of the possible overlap of pieces across blocks, it is possible that you download a block multiple times in a download all. Edit: or maybe I am misunderstanding how files/pieces/blocks work.
Your colorscheme/theme is really niceeeeeeeeeeeeeeee!!!!! what is it, (it's not gruvbox) i checked your config files but cannot implement the same in mine, how can i get a theme like yours....
Just wanted to say thanks for having made my Rust learning experience in the past really enjoyable. Totally unrelated question, but what kind of zip neck sweater are you wearing?
Good catch! Fixed in github.com/jonhoo/codecrafters-bittorrent-rust/commit/27aeebfb1d9ff2e9294406b332a76ef71e38f4c1. Not caught by the CI I think because CodeCrafters only has single-file download at the moment.
I'd love to see what a 'from scratch' impl would look like as opposed to using (mostly) just the crates from the Codecrafters challenges. One example I could think of is using nom for bencode instead
