File Transfer Protocols

A File Transfer Cancellation Protocol That Stops Both Sides

Define terminal state, versions, acknowledgement, and tombstones for local, remote, offline, and timeout cancellation so peers stop promptly and tasks never revive.

A capability stays maintainable only when the team can explain every state, retry, and piece of residual data—not merely show one successful run. Cancel is a distributed terminal state, not a hidden progress row. Because peers disconnect and messages duplicate or arrive late, cancellation is idempotent, versioned, and durable until acknowledged.

File transfer must reconcile sender offsets, durable receiver writes, chunk integrity, and terminal state on both peers. A full progress bar may show queued bytes, not a complete usable file.

Questions the design must answer

Write the following choices as reviewable rules instead of scattering them across callbacks and UI conditions. Explicit rules make scaling, compatibility, and diagnosis less dependent on guesswork.

  • Persist the cancelled terminal state first, then stop reads, sends, hashing, retries, and emit control.
  • Apply cancel idempotently by task ID and version, following an explicit policy for partial data.
  • Remove the tombstone after mutual acknowledgement; until expiry it outranks older in-progress records.

Cancellation is measured by propagation latency, resource release, and terminal consistency after reconnect. A versioned durable tombstone prevents resurrection.

Edge cases are part of the feature

Production failures often appear when two individually valid actions overlap. Inspect stale messages, duplicate effects, exhausted resources, and mixed versions instead of patching only the current stack frame.

  • Cancel waits behind the bulk queue, so the peer receives hundreds of megabytes before stopping.
  • Offline cancel exists only in memory and refresh lets the recovery coordinator revive the task.
  • Late progress from an old session overwrites cancelled and returns UI and storage to active.

Prove that it works with evidence

Write the expected state trace before injecting faults. At every phase, reconcile user-visible outcome, both protocol endpoints, persistent records, and resource counts to prove the loop.

  1. Cancel during send-buffer saturation, receiver storage, digest verification, and reconnect wait.
  2. Drop the first cancel and first acknowledgement, proving idempotent retry and terminal convergence.
  3. Replay old progress, complete, and resume messages after cancel; version fences must reject them.

The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.

Put the guide to work

Open uCopy and connect two devices securely from the browser.

Start for free