GetRight is possibly the piece of software that planted the seed of fascination with computers and software in my head at a young age. It blew my mind that someone had made an app that could fix Internet Explorer dropping downloads mid-way through on my dial-up connection if my Nanna sent a fax to my Mum whilst I was on the PC.
Cool. After reading your README, the "post-part" hook is the most interesting part for me. Chunk-level hooks make it easier to plug into things like rclone or other workflows.
As you mentioned, the single .rapel-state.json file tracks all chunk metadata. Does that state also pin the origin file identity while resuming, so it can detect if the remote file changed between sessions?
How is this any different than existing solutions like aria2? I'd also like to see some benchmarks for the same download using the same chunk size settings with Rapel vs aria2.
A little bit of a nit - when tracking progress you can ditch the mutex by using atomic integers for the download progress. Instead of using locks, your test for a chunk being done becomes something like "downloaded == chunk_size".
You also never call UpdateChunkProgress, FYI! The code is a little confusing to read because of that dead variable, at first I thought that chunks are never resumed. ProgressTracker and State/ChunkInfo do similar things, if I were in your shoes I'd make it so that there's clear ownership over where progress is actually tracked.
...I'd probably move State to be saved on the _start_ of the download, have it solely be responsible for tracking the arguments that the download was called with. Rename it to DownloadArguments, delete all the runtime state tracking, as it's already inferred by the downloader on start.
Is this like a modern GetRight?
GetRight is possibly the piece of software that planted the seed of fascination with computers and software in my head at a young age. It blew my mind that someone had made an app that could fix Internet Explorer dropping downloads mid-way through on my dial-up connection if my Nanna sent a fax to my Mum whilst I was on the PC.
Same, I think I went with Flashget.
I seem to recall that I'm fascinated with NetAnts too, but went with Flashget for some reason.
Cool. After reading your README, the "post-part" hook is the most interesting part for me. Chunk-level hooks make it easier to plug into things like rclone or other workflows. As you mentioned, the single .rapel-state.json file tracks all chunk metadata. Does that state also pin the origin file identity while resuming, so it can detect if the remote file changed between sessions?
How is this any different than existing solutions like aria2? I'd also like to see some benchmarks for the same download using the same chunk size settings with Rapel vs aria2.
Interesting approach. One thing I'd be curious about: how does this handle edge cases in production? That's usually where the real complexity lives.
A little bit of a nit - when tracking progress you can ditch the mutex by using atomic integers for the download progress. Instead of using locks, your test for a chunk being done becomes something like "downloaded == chunk_size".
You also never call UpdateChunkProgress, FYI! The code is a little confusing to read because of that dead variable, at first I thought that chunks are never resumed. ProgressTracker and State/ChunkInfo do similar things, if I were in your shoes I'd make it so that there's clear ownership over where progress is actually tracked.
...I'd probably move State to be saved on the _start_ of the download, have it solely be responsible for tracking the arguments that the download was called with. Rename it to DownloadArguments, delete all the runtime state tracking, as it's already inferred by the downloader on start.
Looks like fun but also a half implemented BitTorrent client.