Why a file cannot travel in one piece
Every link has a largest unit it will carry at once, and on the radios a mesh uses that unit is small. In Bluetooth Low Energy, the Attribute Protocol defines ATT_MTU as the maximum size of any packet sent between a client and a server. The two sides can exchange the sizes they support and then both use the smaller one. A write command can carry only the first ATT_MTU minus 3 octets of a value, so anything larger has to be split.
A mesh adds a second limit: time. Devices move in and out of range, and a link may last only a few seconds. The Bundle Protocol for delay-tolerant networks (RFC 9171) gives this as a reason to make bundles smaller: the next node may be reachable only through intermittent contacts, none long enough to forward the whole bundle.
So a file is cut into pieces at the application level, and each piece may be cut again by the transport to fit the link.
Chunks with their own identity
A chunk carries enough information to be placed correctly on arrival: an identifier for the transfer, its position in the file, the total number of chunks or bytes, and usually a checksum. Because each chunk describes itself, chunks can arrive out of order, travel by different paths or arrive on different days, and the receiver can still put them back together.
The Bundle Protocol does exactly this. A fragment keeps the original bundle’s source and creation timestamp and records its offset and the total length of the original data. The destination reassembles the payload once the bytes it holds form a continuous run equal to that total length.
Choosing a chunk size is a trade-off. Larger chunks need fewer headers and fewer acknowledgments. Smaller chunks waste less when one is lost and are more likely to finish within a short contact.
Acknowledging each chunk
The sender needs to know which chunks arrived, so the receiver confirms them, either one by one or by reporting how far it has got. Each confirmation is an ordinary acknowledgment: if one does not arrive in time, the sender sends that chunk again, not the whole file.
The tus protocol for resumable HTTP uploads uses the second style. After each upload request the server replies with an Upload-Offset header giving how many bytes it now holds, and the client continues from there. An optional checksum extension lets the server verify each piece and reject one that does not match.
Resuming after a break
Interruptions are normal in a mesh, so resume is the feature that decides whether large files work at all. In tus, a client that lost its connection asks the server for the current offset and sends only the remaining bytes.
Delay-tolerant networking describes two ways to split work across contacts (RFC 4838). Proactive fragmentation divides the data in advance, when the size of upcoming contacts is known or predicted. Reactive fragmentation happens after a transfer is cut short: the receiving node keeps the part it got and marks it as a fragment, and the sender forwards the remaining part at a later contact, possibly through a different next hop. The RFC notes a catch: when a signed message is only partly received, most message authentication codes will fail, so with security turned on it may be necessary to fragment large bundles in advance into units that are easier to sign.
Resume also needs memory on both sides. The receiver has to keep the chunks it already holds through a restart, and the sender has to still have the original bytes. An app that deletes its copy as soon as sending starts cannot finish an interrupted transfer.
Checking the whole file
Acknowledged chunks are not yet a correct file. Saltzer, Reed and Clark’s “careful file transfer” example makes the point: errors can creep in while reading from disk, buffering, copying or writing, not only on the network. Their answer is an end-to-end check. The receiver reads the file back, computes its checksum and compares it with the sender’s, and only if they match is the transfer declared committed. Reliable links reduce how often that check fails, but they do not replace it.
That final check is the file-sized version of the gap between delivered, accepted and committed. The last chunk arriving is delivery. A verified, stored file is the result the user cares about.
What a mesh adds
On a multi-hop mesh, every relay spends airtime and storage on someone else’s file, and every hop is another place a chunk can be lost. Mesh software therefore sets limits: a chunk size suited to its links, a maximum file size, and caps on how many transfers a device will reassemble at once. A transfer that cannot finish should fail clearly so the app can offer to send it again.
Offline Protocol’s mesh SDK shows these choices in practice. In v0.27.0 it sends files in 32 KiB chunks with a 100 MiB maximum file size by default, and reports progress per chunk and a completion event once every chunk is acknowledged. It saves only a description of each outgoing transfer, not the chunk bytes, so after a restart it asks the app to supply the file again and checks the bytes against the original transfer.