Implement way to restore DownloadWorker from file

[minhnhut]

By implement this will enable more use case of the library:

• network disconnected during download session, and we need to resume later
• user need to stop the download completely, and resume it later

Idea:

• Serialize DownloadWorker's state and put it somewhere along with downloaded file (which maybe not completed yet).
• I like the idea that wrap download file inside a container file, which contains meta information about download session. Many other downloaders implemented this way.
• Restore DownloadWorker's state from serialized information, DownloadWorker will then restore partial download sessions's state, and start download from where it left

P/s: only PartialDownloadSession is compatible with this method

[ProtocolNebula]

You are using the Multi-threaded-downloader, which can be nice, but I don't like it at all, I prefer something like https://github.com/zenflow/node-fast-download.

This basically check if file already in the destination folder and get the file lenght, so on restore you only have to read the filesize and make the call, you not writing everytime a metafile, so processor speed must be better and you have not to check if file contains X data but not saved in meta file, etc...

It's only my view point and a suggestion.

[minhnhut]

Thanks for your suggestion!

rapid-downloader already came with single-thread mode and multi-thread mode, which can be switched easily by option object.
I also came up with checking file length idea, but that will only work well with single thread as you suggested. Thing getting more complicated in multi-thread case. Moreover, end user may change download settings later, when resuming. Therefore, I really want a solution that can work universally for both cases, and separated from binary data itself.

[ProtocolNebula]

Maybe the best solution is not let the user change the threads quantity... Which is contrarily to my original idea about multi-thread downloader, but have sense with this problem.

Another solution can be split more the file, for example, split in 100MB (parametizable size) parts and every chunk download up to 100MB, with this you can join files early and if downlaod stopped and threads changed, you simple have to put more workers to download.

I hope you found a nice and clean way to do it.