Three kinds of resume
- None: the connection drops and the transfer begins again. Typical of email attachments, many web upload forms and consumer sharing links.
- File-level: the tool knows which files completed and skips them, but a file interrupted at 90% is sent again in full. rsync and most sync clients behave this way for a single large file.
- Block-level: the receiver tracks which blocks of each file arrived and asks only for the rest. An interruption costs the blocks in flight, not the file.
Why verification is part of resume
Resuming from a checkpoint is only safe if both sides agree on what the receiver already holds. A protocol that resumes from a byte offset without checking can splice a corrupted tail onto a good head. Block-level protocols keep a map of received blocks and verify the assembled file before declaring it complete; RIPTON CLOUD marks a package delivered only after that verification.
What RIPTON CLOUD does on an interruption
| Path | On interruption | On completion |
|---|---|---|
| Browser (Web Edge) | Resumes from the last completed batch of files; large files resume by chunk. | Package assembled on the node and verified. |
| RIPTON Desktop and node-to-node (RIPT) | Resumes from the last verified block; missing blocks are retransmitted, not the file. | Every block accounted for before the package is marked delivered. |
| Recipient download | Browser download managers handle resume per their own rules; the archive is served as one stream. | Download events recorded per recipient. |
How to test resume in an evaluation
- 1Start a transfer of a multi-gigabyte file or a large directory.
- 2At around 60 to 90 percent, pull the network cable or stop the process.
- 3Restore and restart. Record how much was repeated and the total elapsed time.
- 4Compare the delivered files with the source. A resume that saves time but corrupts data is worse than a restart.