Minor fix to improve the portability

[xiaoxiang781216]

PLEASE NOTE the following text from the iperf3 license. Submitting a
pull request to the iperf3 repository constitutes "[making]
Enhancements available...publicly":

You are under no obligation whatsoever to provide any bug fixes, patches, or
upgrades to the features, functionality or performance of the source code
("Enhancements") to anyone; however, if you choose to make your Enhancements
available either publicly, or directly to Lawrence Berkeley National
Laboratory, without imposing a separate written license agreement for such
Enhancements, then you hereby grant the following license: a non-exclusive,
royalty-free perpetual license to install, use, modify, prepare derivative
works, incorporate into other computer software, distribute, and sublicense
such enhancements or derivative works thereof, in binary and source code form.

The complete iperf3 license is available in the LICENSE file in the
top directory of the iperf3 source tree.

• Version of iperf3 (or development branch, such as master or
  3.1-STABLE) to which this pull request applies:

• Issues fixed (if any):

• Brief description of code changes (suitable for use as a commit message):

[bmah888]

Thanks for the pull request! Out of curiosity...on what platform were you trying to build iperf3? I'm just wondering what the OS and hardware is.

[xiaoxiang781216]

Thanks for the pull request! Out of curiosity...on what platform were you trying to build iperf3? I'm just wondering what the OS and hardware is.

I am trying to port iperf3 to NuttX( a realtime operating system) and test on Photon and Simulator.
You can get more info from these links:
NuttX: https://www.nuttx.org
Photon: https://store.particle.io/products/photon
Simulator: https://nuttx.org/doku.php?id=wiki:nxinternal:simulator

[bmah888]

That's great, thanks. I'm looking over the changes...there are a lot of them so I'm trying to see if I can review and merge them one or two at a time.

[bmah888]

I cherry-picked d7e30be and 6c10c3e from the pull request...this seems to be a reasonable workflow for working through your changes. More to come...thanks again for the pull request.

[bmah888]

Cherry-picked d4267b6 and b9aa6ce.

[bmah888]

Cherry-picked 9dab732.

[bmah888]

Of the commits in this PR I haven't merged so far, I have the following questions/comments:

Regarding 98c8683 : I'm going to merge this...I was debating whether to just fix this by importing a new cJSON, but that's a potentially big undertaking.

Regarding f9dd48e : readentropy() is deliberately written to only open /dev/urandom once per invocation of iperf3. Admittedly I'm not sure what tradeoffs this involves. Does it cause any particular problems in the NuttX environment?

Regarding ecb8c31 : We want to keep this code as-is...if the user doesn't specify a -w flag, we want to know what the default buffer / window size is.

Regarding af35a48 : I'm not sure how to evaluate this change. Are you saying because we unlink the file, whether we do MAP_PRIVATE or MAP_SHARED doesn't matter? (Put another way, is there anything wrong with the mmap() calls as they exist today?

Regarding 69fb9dd : Can you describe a little more detail about the starvation problem that is solved by this change?

Regarding 9098e1d : Is this change just to make the client and server code more consistent? I'm just asking this because I've gotten bit by making changes like this in places where the ordering of various steps is actually important to preserve. So I tend to shy away from making changes like this unless we've tested them really well.

[bmah888]

Cherry-picked 98c8683.

[xiaoxiang781216]

Of the commits in this PR I haven't merged so far, I have the following questions/comments:

Regarding 98c8683 : I'm going to merge this...I was debating whether to just fix this by importing a new cJSON, but that's a potentially big undertaking.

Regarding f9dd48e : readentropy() is deliberately written to only open /dev/urandom once per invocation of iperf3. Admittedly I'm not sure what tradeoffs this involves. Does it cause any particular problems in the NuttX environment?

Yes, the global variables for each application just initialize once in NuttX, the global variables keep the previous value in the second invocation. For iperf3, "/dev/urandom" isn't opened in the second launch. Here has the more explanation:
https://cwiki.apache.org/confluence/display/NUTTX/Linux+Processes+vs+NuttX+Tasks

Regarding ecb8c31 : We want to keep this code as-is...if the user doesn't specify a -w flag, we want to know what the default buffer / window size is.

I made this change just because NuttX doesn't support SO_SNDBUF/SO_RCVBUF, how about we query the buffer size regardless of -w flag, but don't exit the test if getsockopt return error?

Regarding af35a48 : I'm not sure how to evaluate this change. Are you saying because we unlink the file, whether we do MAP_PRIVATE or MAP_SHARED doesn't matter? (Put another way, is there anything wrong with the mmap() calls as they exist today?

Yes, unlink with MAP_SHARED equals MAP_PRIVATE. MAP_PRIVATE has copy-on-write semantics and is very hard to implement without MMU, but most hardware running NuttX don't have MMU, that's why I made this change.

Regarding 69fb9dd : Can you describe a little more detail about the starvation problem that is solved by this change?

If we monitor write_set unconditionally, select will return immediately without sleeping since we haven't sent anything then the buffer should be always available, but iperf_send is called to consume the buffer ony when the state equals to TEST_RUNNING. Then you will see while become a busy loop until the state transit to TEST_RUNNING.

Regarding 9098e1d : Is this change just to make the client and server code more consistent? I'm just asking this because I've gotten bit by making changes like this in places where the ordering of various steps is actually important to preserve. So I tend to shy away from making changes like this unless we've tested them really well.

The change is also a good thing to let the client initiate the close process. Here has a clean explanation:
http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html