data: avoid sending the same repeated byte (0)

[matttbe]

Hello,

Regarding data that are being sent, I would recommend not sending the same repeated byte, but some random content. One reason is that the same repeated byte can be easily compressed, which might not really validate the performances of a network in presence of some "connections optimizers".

Plus, it might be good to check data being received to catch corruption, but that's maybe a special case, if a repeating payload is used instead of random data (probably a new option for this case).

[lance0]

Good catch — all-zeros payload is a real problem for any path with WAN optimizers, compression offload, or dedup. iperf3 uses random data by default for exactly this reason.

I'm thinking:

• Default to random fill (cheap PRNG like rand::thread_rng().fill_bytes(), seeded once per stream) — this should be the baseline
• --payload-pattern flag for specific patterns (zeros, 0xAA, repeating sequence) when you want reproducibility or compression testing
• Optional --verify flag for integrity checking — receiver validates a PRNG sequence or CRC per block. This catches silent corruption but adds CPU overhead, so it should be opt-in

The random fill is a quick win, I'll prioritize that. The verify mode is more involved since it needs sender/receiver to agree on a seed and check sequence.

[lance0]

Implemented in 7620da4 — new --random flag fills TCP/UDP send buffers with random bytes at allocation time (single fill, no per-write overhead).

xfr <host> --random              # TCP with random payload
xfr <host> -u --random           # UDP with random payload
xfr <host> --random -b 100M     # Works with bitrate limiting

For UDP, only the payload bytes after the 16-byte sequence/timestamp header are randomized. The rand crate (already a dependency) handles the fill.

Current scope:

• Client-sent payloads in upload mode — fully random
• --bidir — client→server direction is random, server→client remains zeros
• -R (reverse) — sender is server, so --random doesn't apply yet (warns on stderr)
• QUIC — skipped, payload is already TLS-encrypted

Server-side random fill for reverse mode would need protocol negotiation — tracking that as future work.

This is on master, will ship in the next release. Thanks for flagging this — it's a real correctness issue for anyone testing over WAN-optimized links.