Feature Request: Resume partial transfer

[Fenil Mehta]

Hi team,
Thanks a lot for this powerful app 🙏

Are we planning to implement the option to resume partial transfers ? We could have this option shown when a file already exists but there is size mismatch.

Following are the reasons why I believe we could add this features:

1. Save time and resources - Scenario: when a person is transferring 2GB file, and for some reason the transfer is interrupted after 1GB. Then the option to resume will be very beneficial
2. Since the person performing the transfer will know if they are sharing the same file or not. So, just deleting the partially received file and re-transferring the whole file is wasteful efforts. And, since the user will be deciding whether to "resume the transfer or not", it will be a safe thing.

A possible change to the working when receiving the data which could help this feature as well as the user:

• Currently - When a file is being received, we use the original file name itself
  • In this case, it is hard to differentiate if the file is partially received or fully received.
  • No way other than relying on the user to know whether there is a possibility of resuming a partial transfer or not
• Proposal - When receiving, we could use the file name as <NAME>.<SIZE_BYTES>.part (.part is the extension used by browsers when file download is in-progress), and once fully received, we could rename it to <NAME>
  • User can easily know if a file is partially received or fully received by just looking at the file name
  • When re-sending files that were interrupted, SIZE_BYTES in the file name can help know whether we should show the resume option to the user or not (thus reducing false positives to a great extent)

[Fenil Mehta]

If we want to be 100% sure about resuming a transfer then, the following mechanism can be followed:

1. the sender will tell the receiver the file name and file size (in bytes) which is going to be sent
2. the receiver can do first round of file resume possibility check based on the logic explained in the previous comment
3. if the file seems non-resume-able based on above check, then we goto step 6.ii, else goto step 4
4. the receiver can tell the sender that X bytes have already been received
5. the sender will calculate a hash (possibly SHA256) of those first X bytes of the file which is being sent, and give it to the receiver
6. the receiver also calculates the hash and compares it with the received value
   i. if hash matches, then we can resume the transfer
   ii. if hash does not match, then the receiver asks the sender to send the full file

Thus, there will be two levels of checking:

1. based on file size (i.e bytes) which is there in file name - this will eliminate many false positives at almost zero cost
2. based on hash (a collision resistant hash like SHA256) - this will eliminate all false positives and will be way faster than sending the data over network