How can I build an iperf broker to support multiple test sessions? #1276
Replies: 2 comments
-
iperf3 was designed to handle one test at a time, because in the environments for which it was designed (high performance research networks), the end hosts can easily up being the bottlenecks. In such a case, multiple simultaneous tests can interfere with each other, and it's not clear what you'd be measuring (at least with any individual test). It feels like iperf3 was just intended to solve a different problem from what you're trying to do. |
Beta Was this translation helpful? Give feedback.
-
A method I have seen before for testing several devices using TCP is by using a load balancer ( One of the issues was that scanners also sent TCP connection to the port. The solution was to check for the existence of legal iperf3 cokkie in the request (can be done by |
Beta Was this translation helpful? Give feedback.
-
I support TCP/UDP testing on devices where each device connects to a separate port on a server (Virtual Machine with Linux or Windows) and runs iperf3 in reverse mode. There are several VMs and each VM has a number of open ports for iperf3. Having each device connect to a particular server IP and port works fine if you have just a handful of devices. What if you need to test a lot of devices simultaneously, hundreds or more? How can I build an iperf broker or scheduler which would automatically open and close ports for iperf3 based on incoming requests for devices and make sure to provide an unused port to the new request? Ideally I'd want to use one single server IP and port so that all devices connected to this IP/port combination and on the backend the iperf broker would schedule these requests to different ports or VMs if it runs out of ports in one VM. Maybe this broker could start/close iperf containers, while not having multiple containers run all the time waiting for iperf requests, but only open when needed. Again I'm not familiar how to build a broker that would listen to these iperf requests and close them when session completed.
Thank you in advance!
P.S. One of the reasons to close iperf ports is because the client app on the device sometimes doesn't properly close the session and the port stays 'hung up' with process in CLOSE_WAIT or TIME_WAIT, as it was discussed in various posts online. Even killing the ports doesn't clear these issues sometimes. The most definitive solution for me is to reboot the server to clear all the hung ports and processes. Again, it's one of the reasons to have an iperf broker mainly needed to support lots of simultaneous data sessions.
https://sourceforge.net/p/iperf/mailman/message/20056251/
#683
https://www.thegeekdiary.com/high-number-of-connections-is-close_wait-state-in-netstat-command-output/
Beta Was this translation helpful? Give feedback.
All reactions