3.21.14

A single-change release. A client that never set a stream count measured two parallel streams where iperf3 with the same arguments measured one, so the wrapper and the CLI reported different throughput for what looked like the same test.

Behavior change

A run that never sets numStreams now reports single-stream throughput. Set numStreams = 2 to keep the previous measurement.

Changed

• IperfConfiguration.numStreams now defaults to 1 (#131), the value iperf_defaults() assigns. The wrapper configures the engine directly rather than through the argument parser, so a default it does not restore is a silent divergence — and this one was invisible to whoever wrote the calling code, because they never set the option. Two streams and one measure differently on a fast path, which is how a downstream tool came to report lower loopback throughput than the CLI on the same host with nothing in its own code explaining why.

  The value dated to the initial import and nothing in the history recorded a reason for it. An interoperability test now compares the wrapper's default stream count against the CLI's, so a divergence fails instead of going unnoticed — the absence of exactly that comparison is why this survived.

Note

The remaining configuration defaults were audited the same way, in two groups: against iperf_defaults(), and against the defaults the CLI applies at the end of iperf_parse_arguments, which the wrapper bypasses entirely. Everything else agrees. One deliberate divergence remains — mode defaults to .download while the engine defaults to the client sending — and unlike this one it is disclosed, in the README option table and the DocC usage guide.

Full changelog: https://github.com/gewill/iperf-swift/blob/v3.21.14/CHANGELOG.md · v3.21.13...v3.21.14