I'm using Godot for development and I want to know the correct approach for hosting multiple "game rooms" in a single server:

Should every "game room" connect through a different TCP/UDP port?

Should I run a new application instance for every "game room" or should I trust the engine tread system and run only just a “big” instance in the server?

Thanks.

I haven't implemented any sort of networking with Godot, so there might be some specifics.

Having a single TCP and/or UDP port for communication shouldn't hinder running multiple parallel sessions. How do you think webservers manage?

How do you think webservers manage?

I'm not saying is not possible, I'm asking about 100 clients in a low latency application using the same port.

snesgx said:

How do you think webservers manage?

I'm not saying is not possible, I'm asking about 100 clients in a low latency application using the same port.

No, you didn't mention low latency nor the number of clients.

Its just an example, the number of clients is not fixed. And if you don't want to help, I don't see the point of trolling.

Using the same “port” and using the same “socket” aren't quite the same thing.

For example, it's totally possible to have multiple processes accept() or recvfrom() on the same port (with SO_REUSEPORT.) Some random process will get the connection/packet. Whether this is what you want, is a different question. There are cases where this makes sense, static content servers for example.

Another option is to use a single process that listens on a known port, and then identifies which “session” the incoming packet is part of, and funnels it to one of many server processes, either using other ports, or using some other kind of IPC, or even using multi-threading in a single OS process. Exactly how this process gets told which users/sessions belong to which back-end service instance, varies. Some modern MMO games work like this, to avoid having the player re-connect or establish a new session each time they move between worlds/zones/shards.

And, finally, it's also possible to just spin up a bunch of game instances (processes) that each listen to a different port, and use some external mechanism to let the players/clients know which port to connect to. This is certainly the most straight-forward, and also the most robust, given that crashing one of those processes will leave the rest of them intact. So, as a start, that's what I would begin with. FWIW, Roblox has worked like this for a very long time, and scaled to a lot of players :-)

If you use containerization, you can even have each process listen on the “known” port, and then let the containerization layer/kernel rename the external ports for each container instance. It doesn't gain you a whole lot over the “run a bunch of processes” instances, other than the “baking and deploying” of the data+code that makes up one “server” becomes a little more well-contained.