On a Quest for the Fastest P2P File Transfer CLI: Thruflux (Open Alpha)

Source: Dev.to

Click here for Github repo

My goal

One day, I awoke with this single ambition burning within my heart: I wanted to create the fastest file‑transfer tool in existence.
Having had some prior experience in self‑led web‑development projects, I instantly turned to the web to find out what existing browser‑based solutions are out there.

What people use today

Most people use popular commercial tools such as Dropbox, Google Drive, or messaging mediums such as Discord and Email.
For developers – and surprisingly for many non‑developer individuals as well – such tools are simply not sufficient. Their limits are well known:

• Size limits on the files you can transfer.
• They rely on a client‑server model where an upload must finish before anyone else can download the files.
• While great for securely storing files in the cloud, this model is terrible for one‑off file sharing.
• Because files have to be stored on a server, there are always innate security concerns.

Why existing P2P tools didn’t cut it

I then turned to the world of P2P file transfers. Some popular zero‑setup solutions include Blip, Magic‑wormhole, croc, scp, and rsync. Unfortunately, none of these satisfied me:

All of the above tools rely on TCP connections. I’ve recently become interested in QUIC and UDP, so I decided to leverage them to beat the existing tools.

Core focus

Leverage QUIC to build the fastest CLI transfer tool that is dead‑simple to use and incredibly fast.

I defined seven requirements:

1. QUIC + ICE for zero‑setup peer‑to‑peer transfers (UDP hole‑punching succeeds more often than TCP hole‑punching; QUIC also benefits from modern congestion‑control algorithms like BBR).
2. First‑class multi‑file support – transferring many files should be as fast as (or faster than) a single file of the same total size.
3. Multiple receivers – a single session can accept receivers at any time without restarting the transfer.
4. Cross‑platform – Windows, Linux, and macOS.
5. Automatic resume – essential for large files; must be fast.
6. Open source.
7. Speed over everything else – security is kept to a viable minimum; performance is the primary selling point.

Language choice

While Rust and Go were strong candidates, I chose C++ because:

• Mature QUIC/ICE libraries.
• Low‑level configurability.
• Zero garbage‑collector churn, allowing maximum performance extraction.

Lessons learned

1. Threading vs. single‑threaded – I initially thought multiple threads and multiple QUIC connections/streams would maximize throughput. In practice, a single thread with a single connection saturated the network, greatly simplifying the app logic.
2. CPU scaling – QUIC scales heavily with CPU power and core count. On reasonable CPUs (released in the last 10 years, ≥ 2 cores) QUIC outperformed TCP; on low‑end devices it performed worse.
3. Congestion control & buffers – Using BBR gave ~4× throughput compared to CUBIC. Increasing the OS UDP buffer size to at least 8 MiB added another ~1.3× speed boost.

Benchmark

The moment of truth: benchmarking my tool against existing ones.

Hardware / environment

• Vultur dedicated CPU – 2 vCPU (AMD EPYC Genoa), 4 GB RAM, NVMe SSD, Ubuntu 22.04.
• Tested over the public internet: sender in Chicago, receiver in New Jersey.
• Method: median of 3 runs; times include full end‑to‑end wall‑clock (setup + transfer + teardown).
• “Receiving phase” only is reported.

Benchmark commands (wall‑clock measured with time)

# scp — single file
time scp test_10GiB.bin root@207.246.86.142:/root/

# scp — many files
time scp -r bench/

(Further benchmark results for the custom QUIC tool would follow here.)

Benchmark Commands

# Mark files on the remote host
mark_files root@207.246.86.142:/root/

# rsync — single file
time rsync -a --info=progress2 --no-compress --whole-file --inplace \
  test_10GiB.bin root@207.246.86.142:/root/

# rsync — many files
time rsync -a --info=progress2 --no-compress --whole-file --inplace \
  benchmark_files root@207.246.86.142:/root/

# croc — single file
time CROC_SECRET="code" croc --yes

# croc — many files
time CROC_SECRET="code" croc --yes

# Thruflux — direct (single + many files)
time ./thru join --overwrite 

# Thruflux — forced TURN relay
time ./thru join --overwrite --force-turn 

# wormhole — single / many files
time wormhole receive  --accept-file

Feature Matrix

Even with a 6‑second initial P2P handshake (which scp and rsync don’t have), Thruflux beats them in wall‑clock time. Compared to other P2P tools, it shows a clear advantage, especially for 1000‑file transfers.

Observations & Trade‑offs

1. CPU‑bound – Thruflux needs more CPU power. On low‑end, single‑core devices it can be marginally slower than rsync/scp.
2. TURN relay fallback – The self‑hosted TURN server is modest and located poorly, so transfers over TURN (e.g., symmetric NATs) are slower than other tools.
3. UDP restrictions – Some networks block outbound UDP entirely, making QUIC unusable.
4. Longer connection phase – Full ICE exchange adds latency; switching to trickle ICE could reduce this.
5. Lack of verification – Thruflux trusts QUIC’s built‑in integrity (stronger than TCP). Disk‑level corruption isn’t checked, which is rare but possible.
6. Join‑code entropy – Without PAKE, the join code must be high‑entropy to compensate for security; users typically copy‑paste it anyway.

Despite these caveats, Thruflux shines in multi‑file scenarios where traditional tools struggle. The early results are encouraging, and there’s ample room for improvement.

Project Status

• Alpha stage – Core functionality is complete; basic testing done. Expect rough edges, especially on cross‑platform and networking edge cases.
• Feedback welcome – Bug reports, performance comparisons, edge‑case scenarios, and constructive criticism are highly valued.

Quickstart 🚀

Install

Use

# Host files
thru host ./photos ./videos

# Share the join code with multiple peers
thru join ABCDEFGH --out ./downloads

For more details, see the repository’s README.