UDP Broadcasting for automatic search of servers

Question

I am making a multiplayer networking game. Now to connect to the server, client needs the ip address of the server.

So, the way I implement this is as follows.

Client Broadcasts its ip address at Broadcast IP and a port say A. Server listens to it over A, and

Server creates a new UDP connection with the client behaving as a client say over port B. It sends all the important information required for the game including its IP.

Client is the server for this connection and receives the data from server over port B.

Now, A and B are constants. So when I need the server to listen for multiple clients in different threads I can put diff values to A and B for the threads but in the client file A and B are independent of these threads. So it gives me an error of

bind: Address already in use

What is the plausible solution for this?

Answer 1

First of all, having the client broadcast its address sounds pretty horrible, at least to me. Broadcasting means that it'll only work if the server is on the local subnet, as well as polluting the network with a lot of unnecessary traffic.

I'd have the client find the server via DNS Service Discovery (DNS-SD). This has the advantage that you can use multicast DNS as long as your server is on the local subnet, and transition to a wide-area server using normal administered DNS, without making any changes to the client at all.

Second, the server should not dedicate a thread to each client. While this model can be made to work to some degree, it has quite a bit of overhead and scales really poorly.

Finally, to (what I think was) your original question: instead of a different port for each client, I'd have one port for all clients. Each request from a client will carry enough information for the server to carry out whatever request it contains. The server simply listens on its single port, and services each request as it arrives. You might dedicate more than one thread to this, but it should be a generic thread pool -- i.e., the number of threads involved is simply a matter of configuration, with no logical implication to the overall design (i.e., the identity of a particular thread has no significance -- if you move to a bigger server with 8 times as man cores, adding more threads is a simple matter of configuring more threads, not changing the overall design).