Invalid JSON output for buffer information
NOTE: The iperf3 issue tracker is for registering bugs, enhancement requests, or submissions of code. It is not a means for asking questions about building or using iperf3. Those are best directed towards the iperf3 mailing list at [email protected] or question sites such as Stack Overflow (http://www.stackoverflow.com/). A list of frequently-asked questions regarding iperf3 can be found at http://software.es.net/iperf/faq.html.
Context
-
Version of iperf3: 3.6+
-
Hardware:
-
Operating system (and distribution, if any):
Please note: iperf3 is supported on Linux, FreeBSD, and macOS. Support may be provided on a best-effort basis to other UNIX-like platforms. We cannot provide support for building and/or running iperf3 on Windows, iOS, or Android.
- Other relevant information (for example, non-default compilers, libraries, cross-compiling, etc.):
Please fill out one of the "Bug Report" or "Enhancement Request" sections, as appropriate.
Bug Report
-
Expected Behavior Valid JSON output using -u and -P options.
-
Actual Behavior Invalid JSON output using -u and -P options.
-
Steps to Reproduce Invoke iperf3 with -u, -P and --json options
-
Possible Solution Current code outputs JSON for sock_bufsize, sndbuf_actual, and rcvbuf_actual values in iperf_udp_buffercheck(), however this may be called multiple times even for a single stream, and definitely will be called multiple times if the -P option is specified, but the JSON is not encapsulated within an array.
- Declare and create JSON array to hold buffer information e.g. json_buffers and add array to test->json_start
- Use cJSON_AddItemToArray() in iperf_udp_connect() after calls to iperf_udp_buffercheck() to add buffer items.
Please submit patches or code changes as a pull request.
Enhancement Request
-
Current behavior
-
Desired behavior
-
Implementation notes
If submitting a proposed implementation of an enhancement request, please use the pull request mechanism.
Thanks for the report, this is definitely a bug. Also --udp is not required to reproduce it...default TCP tests will cause this this problem too. Not sure what's the right way to fix it (the suggestions in the original bug report might be feasible, just haven't really thought about it enough). It'd be easier to just not even try printing this information, assuming nothing else uses it.
Hi Bruce, the fix I suggested worked for me.
Sorry I wasn't clear...the change you suggested seems perfectly reasonable by itself. What I'm concerned about is that if I make that change, I'd be changing the structure of the data that is currently consumed by perfSONAR and anything else that uses --json. That's the part that requires some thought.
Sorry I wasn't clear...the change you suggested seems perfectly reasonable by itself. What I'm concerned about is that if I make that change, I'd be changing the structure of the data that is currently consumed by perfSONAR and anything else that uses
--json. That's the part that requires some thought.
Hello, has there been any progress in resolving this bug? In the context of data processing in Power Bi, for example, this is a rather annoying error because the standard loading system reports errors in duplicate items. It would be great to find a solution. Please!
Hello, any news about reconsidering better structure instead of duplicit records (sock_bufsize, sndbuf_actual, rcvbuf_actual) in JSON output?
Hello, any news about reconsidering better structure instead of duplicit records (sock_bufsize, sndbuf_actual, rcvbuf_actual) in JSON output?
@bmah888 do you have an idea about the fix of this issue?