I am emulating lots of clients by using the following code:

int select_ret = select(0, &fds, 0, 0, &timeout);

if (SOCKET_ERROR == select_ret)
{
	cout << "  Socket select error." << endl;
	cleanup();
	return 7;
}
else if (0 < select_ret)
{
	int temp_bytes_received = 0;

	if (SOCKET_ERROR == (temp_bytes_received = recvfrom(udp_socket, &rx_buf[0], rx_buf_size, 0, reinterpret_cast<struct sockaddr*>(&their_addr), &addr_len)))
	{
		cout << "  Socket recvfrom error." << endl;
		cleanup();
		return 8;
	}

	ostringstream oss;
	oss << "127.";// static_cast<int>(their_addr.sin_addr.S_un.S_un_b.s_b1) << ".";
	oss << "0.";// static_cast<int>(their_addr.sin_addr.S_un.S_un_b.s_b2) << ".";
	oss << "0.";// static_cast<int>(their_addr.sin_addr.S_un.S_un_b.s_b3) << ".";
	oss << rand() % 256;// static_cast<int>(their_addr.sin_addr.S_un.S_un_b.s_b4);
	...

Does anyone have another way of testing many clients, without having actual clients?

The best way of emulating clients is perhaps, having clients?

I don't know what your code is supposed to do, it selects the socket, starts a receive and then, how does this help you testing for a huge network load? If you intend to have a simple loopback server/client, simply take a port range and spawn a lot of udp listeners on that range which are all sending to/receiving from what you want to test.

If you want a more elegant way, write a test suite application which spawns it's own processes and collects results in a nice GUI

Thanks for the reply!

Are you suggesting that I somehow set up a multi-homed client? Are you familiar with this kind of thing in Windows 10? I've only got 2 Windows machines, and zero Linux / Mac OS X machines. :(

The data that I'm looking for are the average load per thread in bytes per second, as well as the standard deviation. If the final load balancing code is working, then the standard deviation should drop, right?

P.S. Do you know how to enumerate all of the multi-homed client's IP addresses, using sockets? Is that even possible?

The following is the output of the working product (https://github.com/sjhalayka/udpspeed_5_load_balancing/blob/main/main.cpp);

Thread 0 342.459 Mbit/s
Thread 1 366.351 Mbit/s
Thread 2 263.315 Mbit/s
Thread 3 368.342 Mbit/s
Start mean: 335.117 +/- 42.6876
Start mean: 335.117 +/- 38.7732
Start mean: 335.117 +/- 34.5134
Start mean: 335.117 +/- 30.0215
Start mean: 335.117 +/- 28.1694
Start mean: 335.117 +/- 25.7621
Start mean: 335.117 +/- 21.911
Start mean: 335.117 +/- 18.2867
Start mean: 335.117 +/- 15.3798
Start mean: 335.117 +/- 12.7215
Start mean: 335.117 +/- 9.51213
Start mean: 335.117 +/- 6.68162
Start mean: 335.117 +/- 2.54722
Start mean: 335.117 +/- 2.54722
Start mean: 335.117 +/- 1.66489
Start mean: 335.117 +/- 1.01858
End mean: 335.117 +/- 1.01858

taby said:
I've only got 2 Windows machines

The poor (wo)man's testing suite is usually starting multiple processes on the same machine if possible. If you have a second machine, better just use that to spawn as much clients as you need so your performance isn't interrupted from processes running in parallel. You can for example choose a port-range like

const int end = 23250;

int start = 23230;
for(int port = start; port < end; port++)
    SpawnUdpClientAt(port);

and start an own process which is sending/listening at the given port.

taby said:
The data that I'm looking for are the average load per thread in bytes per second, as well as the standard deviation.

Do you run your network code in threads which are managed from your application or do you go for IOCP?

I/O Completion Ports have the advantage that you can handle hundrets of connections at the same time without significant increasing the amount of threads as they're managed in a background pool from the OS itself. In our game engine, network handling is limited to 2 IOCP threads which don't perform any action rather than spawning a task for the message send. This plays well with our micro-scheduled task worker pool and allows faster processing of incoming messages.

Btw. as you mentioned Linux and Mac, IOCP is a Windows only thing which can be emulated using the UNIX Poll API call

Thanks for the advice!

P.S. I changed the code to use an IPv4_address object instead of a string representation. Every cycle counts! Thanks again.

P.P.S. I discontinued the use of push_back when dealing with vectors of a known size. Hopefully it's not still too inefficient compared to using the stack.

hplus0603 said:
You don't need to choose a port range on a client. You don't need to call bind() at all for a client UDP socket

With UDP, you have to bind() the socket in the client because UDP is connectionless, so there is no other way for the stack to know which program to deliver datagrams to for a particular port. If you could recvfrom() without bind(), you'd essentially be asking the stack to give your program all UDP datagrams sent to that computer

I made a major change to the algorithm. First, I find a candidate thread with 2 or more jobs (each job handles a client IP address). That's the same. Next I pick the smallest job in the candidate's job pool. This is different than before, where I just picked the first job in the pool. The reason I did this change was because the algorithm was failing to perform the reduction of the standard deviation of the job sizes where there are were like 65536 different client IP addresses. It all works great now, I believe. Thanks again for all of the ideas!