1. Make sure we have a valid TCP MSS on the path when comparing
the UDP block size.
2. Fix a redundant "warning".
This should fix a bug observed on Windows but not (so far) on any
UNIX-like platforms. Fixes#608.
Don't make OpenSSL detection error out unless --with-openssl explicitly given.
This fixes the out-of-the-box build on macOS, which doesn't include
headers, etc. for OpenSSL by default. The configure script still
errors out if the user specifies a --with-openssl flag but for some
reason the build host's OpenSSL is broken or can't be used.
* Regen.
* fix: now --without-openssl configure flags works
enh: if openssl support is required and no valid installation is found, now it raise an error
* enh: added warning if building without openssl (iperf_auth disabled)
This is mostly a cosmetic fix...due to timing differences or
interference from data packets, it is possible that the server
will have a very small last measurement window, possibly with
no data transferred. This looks odd (although it's not incorrect)
and we'd like to eliminate these. If there's an interval
(presumably it'd be the last measurement interval) less than
10% of the length of a standard measurement/reporting interval,
and there are no bytes transferred in the interval, then suppress
printing the results and don't add them to the grand total.
* Towards issue #457. Try to not count the sequence number
gaps resulting from out-of-order packets as actual losses.
* Put all of the UDP diagnostic output behind the --debug flag.
Attempt to fix some brokenness in -F from #301.
In some work related to #125, we introduced a bug in which
chunks of a file being read for the -F option were not
completely sent, particularly with TCP sockets. We attempt
to fix this by detecting cases in which not all data passed
to a socket could be actually sent (for example due to full
socket buffers) and preserving that data for future send
iterations.
The ending statistics in the "diskfile" JSON structure were
wrong, and did not properly distinguish between sender-side
and receiver-side statistics. This has been fixed (at least
for the client side).
Specifically mention in the manpage that "iperf -F" is not
a file transfer tool.
Improve the compatibility of iperf_api.h with C++ so that libiperf can more easily be used with C++ programs.
This involves function declarations as extern "C" and inclusion of a couple of more headers (which arguably improves the C use case).
* s/bandwidth/bitrate/ in user-facing places. Towards #583.
iperf3 has long misused terminology; bandwidth is a measure of
capacity. iperf3 measures bitrate or throughput. We standardize
on "bitrate" because it begins with the same letter as "bandwidth"
(to match the -b command-line option).
User-facing output mentioning "bandwidth" now uses "bitrate".
The long command-line option for -b (--bandwidth) is now --bitrate
(--bandwidth is transparently accepted for backward compatibility).
A few places in documentation that talk about bandwidth as a
measured value have been reworded to use bitrate or throughput.
There are a number of places in code where variables are still
called "bandwidth". We leave these alone for now.
A mention of "bandwidth" in the test parameters JSON also needs
to remain unchanged to avoid breaking compatibility. However,
the test results JSON never used the term "bandwidth" in
the first place.
* s/bandwidth/throughput in one place in RPM description. Towards #583.
While here, add a few words of explanation that the manpage might
not correspond to a current version of iperf3 (at this moment in
time, it in fact is from the not-yet-released iperf-3.2).
* Add configurable timeout for the setup of the control connection.
This is specified using the new --connect-timeout option, with an
integer parameter in ms. The iperf3 client will wait for this
amount of time for the setup of the control connection to the
server. If this option is not given, the OS default for TCP
connection setup is used. Specifying a smaller connection timeout
allows faster detection of a down / unresponsive iperf3 server.
The implementation uses a variation on the timeout_connect()
function from OpenBSD's netcat utility.
Fixes#216.
For the case of multiple TCP streams, compute the grand total
summaries using the appropriate times for the sender and receiver
ends.
Add some divide-by-zero checks.
On the server side, only print the side of the grand total lines
where we have data. (This follows the behavior of the other
end-of-test output lines.)
Fix a minor (compared to all the other problems) bug with
UDP output printing the wrong ending timestamp.
Recent code changes require the server to send the start and end
timestamps for a test, so that the client can accurately compute
statistics for the sender side of a test. iperf 3.1 and 3.0
servers won't do this, so if this information isn't passed back
in the results at the end of a test, we fall back to using the
client's timestamps. The results might not match what's displayed
on the server, but this is basically what iperf 3.1 and earlier
did anyway.
Fixes#574.
Keep track of UDP packets sent/received and use appropriately.
We were using the number of UDP packets seen on the server
(regardless of whether it was the sender or receiver) for
computing loss percentages, etc. This caused confusion in the
case that the last UDP packet doesn't make it to the server
before the test finishes (or if a packet gets lost), because
the client and server had different ideas of how many packets were
sent (OK) and we used the wrong number when computing statistics.
This fix changes the human-readable output to make more sense.
It doesn't change the JSON output. That needs some more review.
I'm reluctant to make structural changes to the JSON output,
because other programs rely on that format.
We also need to investigate whether the last UDP packet can be
still in flight when the test ends (per hypothesis), and if so
what we should do about this.
We apply similar fixes for human-readable summaries for multi-stream UDP tests.
The fixes are similar to those already done for the stream
summary statistics, but these cover a type of output that's only
done if there is more than one stream.
Adjust the JSON computations / output to do a better job of figuring
out the total number of packets sent.
We really need to disentangle the computation and output formatting,
these two operations shouldn't be mixed together like this.
Fixes#252.
