# Falcon File Transfer (fft): full context for LLMs and agents

Source: https://falconfft.com/ · Contact: earlyaccess@falconfft.com

**Move very large files across long, lossy, high-bandwidth networks at the speed of the link, not the speed TCP will allow.**

Falcon File Transfer (`fft`) is a peer-to-peer bulk transfer engine for files from gigabytes to hundreds of gigabytes. It runs as one self-contained binary on Linux, macOS and Windows. It needs no servers and no relays, and it doesn't ask you to open firewall ports. Data is encrypted in transit by default and every file is verified end to end.

---

## Why fft

Standard file transfer (scp, rsync, HTTP, SMB, cloud CLIs) runs over TCP. TCP treats every lost packet as congestion and halves its sending rate. On a long path even a small amount of loss caps throughput far below the link's capacity, however much bandwidth you pay for. Adding parallel streams helps but doesn't solve it, and most tools don't do it.

`fft` was built for exactly the conditions where TCP breaks down:

- **Long distances:** intercontinental, satellite, and cloud-region-to-region links with 100–300 ms of round-trip time.
- **Loss that isn't congestion:** Wi-Fi, cellular, congested peering points, and ISP equipment that drops packets regardless of load.
- **Big pipes:** 1, 10 and 25+ Gbps links that single TCP connections can't fill.
- **Locked-down networks:** both ends behind NAT or firewalls, with no IT department to open ports.

## Measured performance

The numbers below are measured, not modeled.

**Test setup:**
- **Hardware:** two Google Cloud `c3-standard-8` VMs (8 vCPU, 32 GB RAM, ~23 Gbps network), October 2026.
- **Network conditions:** emulated with Linux `tc netem`. Delay was split between both directions, and loss was applied to the data direction.
- **Files and encryption:** 10 GiB files unless noted, with full AES-256-GCM encryption on.
- **Integrity:** every transfer was verified end to end.

| Network condition | fft goodput | Retransmitted | Notes |
| :--- | ---: | ---: | :--- |
| Clean cloud network | **15.9 Gbps** | 5.8% | 10 GiB in 5.4 s (retransmissions here are mostly proactive parity) |
| 100 ms RTT, 1% packet loss | **12.2 Gbps** | 1.3% | Typical intercontinental path with loss |
| 300 ms RTT, 2% packet loss | **8.4 Gbps** | 4.2% | Satellite or very long-haul path |
| 100 ms RTT, 1 Gbps bottleneck | **0.90 Gbps** | 0.01% | ~94% of the link after packet-header overhead |
| Clean network, NAT-to-NAT (hole-punched) mode, 8 paths | **14.9 Gbps** | 2.8% | No open ports on either side |
| 100 GiB, disk to disk, 100 ms RTT, 1% loss | 3.24 Gbps | 1.0% | Limited by the test VM's SSD (~410 MB/s); 100 GiB in 4 min 25 s |

### Compared with TCP on the same paths

TCP was measured with `iperf3` using 8 parallel streams and no encryption, so the conditions favored TCP. fft was encrypted.

| Path | fft | TCP CUBIC (Linux default) | TCP BBR (tuned) |
| :--- | ---: | ---: | ---: |
| 100 ms RTT, 1% loss | 12.2 Gbps | 0.019 Gbps | 15–18 Gbps |
| 300 ms RTT, 2% loss | **8.4 Gbps** | 0.006 Gbps | 0.74 Gbps |
| 100 ms RTT, 1 Gbps bottleneck | 0.90 Gbps | 0.019 Gbps | 0.89 Gbps |

**What this means in practice:**
- **Against default TCP** (CUBIC, which scp, rsync, SMB and most cloud tools use), fft is **hundreds of times faster** on lossy long-distance paths.
- **Against hand-tuned multi-stream TCP BBR** (which requires kernel changes on both ends), fft is **11× faster at 300 ms / 2% loss** and matches it at a bottleneck. BBR with 8 unencrypted streams can be faster on a moderately lossy 100 ms path.
- fft gets these results with **one command, no kernel tuning, encryption on by default, and end-to-end verification**, on all three major operating systems.

### Robustness under extreme loss

On an emulated 500 Mbps / 80 ms link, fft keeps high throughput with **10% random packet loss** (200 MB in about 4.9 s) and **20% random packet loss** (about 5–10 s). Loss-based protocols collapse under the same conditions.

## Resource efficiency

fft is designed to leave the machine usable while it moves data at full speed. These are the totals per transfer from the cloud runs above:

| Metric | Sender | Receiver |
| :--- | :--- | :--- |
| CPU per GB moved (clean link, 15.9 Gbps) | ~1.8 CPU-seconds | ~2.5 CPU-seconds |
| CPU in use at 15.9 Gbps | ~3.6 of 8 cores | ~5 of 8 cores (includes encryption, verification and writing) |
| Memory (peak resident) | ~155 MB | 20–300 MB |
| Memory for a 100 GiB transfer | Flat, bounded | ~310 MB, flat for the whole transfer |
| Packets dropped by the receiving NIC | — | 0 in every run |
| Windows Server 2022 receiver | — | 5.2–7.6 Gbps; busiest thread ≤73%; 0 NIC discards; ≤222 MB |

**Memory doesn't grow with file size.** fft streams data through fixed-size buffers and bypasses the operating system's file cache. A 100 GB transfer doesn't push other applications' data out of memory, and it runs with the same footprint as a 1 GB transfer.

## Capabilities

### Speed
- **Fills the pipe on long, lossy paths:** an adaptive rate controller measures the path's real capacity and keeps pacing at that rate whether loss is random or caused by congestion.
- **Recovers losses within about one round trip** while the transfer continues, instead of waiting until the end.
- **Adaptive forward error correction** adds redundancy only where a lost packet would cost a round trip, so there is no bulk overhead.
- **Hardware acceleration:** kernel and NIC batching on Linux, macOS and Windows, and CPU-accelerated encryption and hashing (AES-NI / ARMv8 Crypto, SIMD BLAKE3).
- **Discovers the path MTU automatically,** using jumbo frames on private links and exact sizing through VPNs and tunnels.
- **Disk-aware:** when the receiving disk is slower than the network, fft paces to the disk instead of wasting bandwidth.

### Connectivity
- **Zero-configuration peer-to-peer:** peers find each other through the public BitTorrent DHT. There is no rendezvous server to run, pay for or trust.
- **Private rendezvous (optional):** organizations that want peer discovery kept in-house can run their own rendezvous service instead of the DHT. It only introduces the two peers; file data never passes through it and stays encrypted end to end.
- **NAT-to-NAT transfers** through home and office routers without port forwarding (cone NATs), plus UPnP and STUN when available.
- **Direct mode** for LANs, private links and cloud VPCs, with multiple parallel flows that spread across NIC queues.
- **Shareable transfer tickets:** one string encodes everything a sender needs to reach a receiver.
- IPv4 and IPv6, dual-stack.

### Security
- **Authenticated, forward-secret handshake** based on the Noise Protocol Framework. The shared secret never crosses the wire.
- **AES-256-GCM on every packet:** forged, replayed or injected packets are rejected before they reach the disk.
- Receivers accept only senders that hold the transfer secret, and file names are sanitized on receipt.

### Reliability
- **End-to-end BLAKE3 verification** of every file, computed while the data streams, so it needs no extra pass over the disk on either side.
- **Resume:** an interrupted transfer continues with only the missing or corrupted blocks, including across NAT-to-NAT connections.
- **Stall protection:** if the receiver stops responding, the sender backs off instead of flooding the network, and it recovers automatically when the receiver comes back. In a test where the receiver was frozen for 2 s, retransmission fell from 262% to 0.08%.
- Recursive directory transfers, skip-if-identical, and a long-running receiver daemon mode.

### Deployment
- **One self-contained binary per platform** (Linux x86_64, macOS Apple Silicon, Windows x64; other targets build from source), with no runtime dependencies.
- Nothing to install on intermediate infrastructure, and no cloud services required.

## Typical use cases

- Moving camera originals, VFX plates and post-production deliverables between studios and continents.
- Replicating datasets, model checkpoints and backups between cloud regions and on-premises clusters.
- Getting large files out of remote sites over satellite, cellular or congested links.
- Ad-hoc large transfers between people behind ordinary home or office routers.

## Methodology and reproducibility

- **Raw data:** available on request.
- **Test harness:** all cloud results come from the scripts in the fft test harness. a GCP testbed script creates and tears down the VM pair. The scripts in its metrics scripts record CPU time, peak memory and NIC packet counters on each end. Results are reproducible on demand.
- **Units:** "Goodput" is file bytes delivered per second during the data phase, and excludes connection setup (a few round trips). "Retransmitted" counts repeated and parity packets as a share of the file's packets.
- **Comparison caveat:** emulated loss drops packets in bursts for both fft and TCP. Real-world paths differ, so please ask for a trial on your own network.

## Current limitations

- **Symmetric NATs** (some carrier-grade and enterprise firewalls) can't be traversed peer to peer yet, and there is no data relay. Run one side on a reachable host, such as a cloud VM or DMZ server, with access limited to known peers, and use direct mode.
- **Disk speed often decides end-to-end throughput** above a few Gbps. fft adapts to it, but can't exceed it.
- **NAT-to-NAT throughput above ~10 Gbps** benefits from multiple punched paths (`--punch-paths`), which add a few seconds of setup.