--bidir option bidirectional udp fails with "iperf3: error - unable to read from stream socket: Resource temporarily unavailable" on Windows

[mochazi]

Context

• Version of iperf3: iperf 3.11 (cJSON 1.7.13)

• Hardware:
  Intel(R) Xeon(R) CPU E5-2680 (server)
  Intel Celeron Dual-Core (client)

• Operating system (and distribution, if any):
  Ubuntu22.04 x64(client)
  Windows 10 21H2 x64(server)

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.):

I know iperf3 doesn't support windows, but I want to know why bidirectional udp fails?

Bug Report

• Expected Behavior

I hope to add the --bidir option, it can also be tested normally like the default option

• Actual Behavior

After adding the --bidir option, it displays "socket: Resource temporarily unavailable"

• Steps to Reproduce

Build iperf3 on Windows.
Use the iperf3 -c <remotehost> -u --bidir command on the client to connect to the server

But, use Windows client to connect to Linux server, very stable.

Windows successfully connects to Linux, but Linux fails to connect to Windows. In theory, isn’t it interoperable?

Can someone tell me what is the reason for this?

[davidBar-On]

This is probably the same Cygwin issue with parallel UDP streams fixed by PR #1163 which is not (yet?) part of iperf3 mainline.

Can you test the code branch from the PR and see if it solves the problem? Note the addition to the -p option that you will have to specify when running the server on Windows.

[mochazi]

This is probably the same Cygwin issue with parallel UDP streams fixed by PR #1163 which is not (yet?) part of iperf3 mainline.

Can you test the code branch from the PR and see if it solves the problem? Note the addition to the -p option that you will have to specify when running the server on Windows.

Windows connects to Ubuntu normally.

With the -p option added, the problem of ubuntu connecting to windows is still there.

When I try a port parameter with a larger value, the problem is still reproduced.

I have pulled this fix branch and the compilation has passed, but I can still reproduce the problem.

[davidBar-On]

Seems I had to explain better the changes for -p in PR #1163. On the Windows side (the server in this case), the -p also specifies the number of ports available to be used, starting from the port number specified by the parameter.

E.g. --bidir requires two ports, so -p 5000/2 should be set and the server will use ports 5000 and 5001 for the two UDP stream (port 5000 is just an example taken from your test). -P is similar - e.g. -p 5000/4 should be used for -P 4 (using ports 5000-50003).

Note that since it may not be known ahead how may ports will be required by the clients, the number of ports set should be the number of expected maximum streams. E.g. if it is expected that up to 20 streams may be used by the clients (-P 20), -p 5000/20 should be set for the server (and ports 5000-5019) should be available for the server).

Can you retry with setting the number of ports available?

[mochazi]

Sorry, I forgot to reply when I saw the email earlier. Now go ahead and test --bidir. I used -p 5000/2 and it still doesn't work.

[davidBar-On]

@mochazi, did you compile and used for the server the iperf3 from PR #1163? I am asking, sine this PR code is based on version 3.10.1 and you are using version 3.11. Note that the PR code is needed for the test, since it was not merged into iperf3 mainline (yet?). You need this version only for the server side.

PR #1163 code branch that should be built for the test (Windows server) is: https://github.com/davidBar-On/iperf/tree/issues-472-1161-cygwin-parallel-udp-stearms