I'm wondering if I need a master server for my game. I'm using the Lidgren networking framework and they even have a sample for a master server. As far as I understand a Master Server can help with NAT punch through and functions as a lobby for connected clients. NAT punch through bit me in the face several years ago using the Unity Master Server and I'd like to avoid that now.

My current plan is just having a single server that should function as a lobby and host game rooms for the clients at the same time.

1. A player logs in, it's credentials are stored and he is put in a lobby. In the lobby he can chat, perhaps have it's private chat room, see some news and join or create games.
2. When a player joins or creates a game he is removed from the lobby list and put into the game room with other players. This game room runs the logic of the game and functions as a authoritative server.
3. When the game is finished all the players will be put back in the lobby. The game room will either go back into a pool or get cleaned up by the GC.

I'm not understanding NAT completely, but everyone should be able to connect to my server like they are able to join a master server. As far as I understand NAT punchthrough only comes in when two clients need to contact each other directly like when one client needs to act like a server (Photon PUN and Unity Master Server). Is this correct and are there any other reasons to host separate servers? How do the big games do this?

Depending on answers I might have plenty more questions.

Thanks,

NAT punch-through shouldn't be an issue in a client-server architecture where the server is publicly known and available, as it is in your setup.

That being said, such a setup isn't very scaleable, so depending on how popular your game becomes, at some point you'll need additional game servers to handle the load. You'd still maintain the one "master" server, however instead of hosting games itself it will contain a list of available game servers, and the master server will direct clients to connect to those servers instead to play the actual game. But again, if these are public servers, then NAT punch-through isn't an issue. Only once you start hosting games on private client machines will you need to start worrying about and performing introduction and matchmaking services.

The decision to use hosted servers versus user servers ultimately comes down to the kind of game you're making, and what kind of online support you want to have. The benefit of public servers is that they're generally always available, you can ensure they have the right hardware and bandwidth requirements, and you know that users haven't tampered with them (good for tournaments or "official" games). The downside is that you have to pay for them, maintain them, and make sure you're scaling them properly to support your customer base. If you have players across the world, you also need to decide how to split up your servers between geographical regions to ensure an optimal online experience for everyone.

Private user servers benefit from allowing localized groups of users (i.e. all on the same LAN or in the same region) to set up their own servers and play, which not only eliminates a lot of latency issues with WAN servers, but also gives you built-in scaleability, since theoretically the number of servers available should scale with the size of the user-base and popularity of the game. They're also typically easier to mod, since the server is physically available. The downsides are that you'll need to have a way for players to find each other, either though a "matchmaking" service, a broadcast-based protocol for LAN games, manually entering IP addresses into a text field, etc. You also can't guarantee that a user server has sufficient hardware requirements, or even the proper bandwidth (game server hosting on residential internet is also often prohibited by ISP terms of service). You can't trust a random user server to not have mods or hacks, so you can't guarantee a fair gameplay experience through architectural or technological means. And if you use a hybrid approach of hosted and private servers, users will have access to the server and can more easily reverse-engineer its behavior, giving them insight or an advantage even when using hosted servers.

In my game (project) I have a master server, which is strictly for keeping track of game servers themselves - which are operated by users/players themselves. All I am doing is offering the game and a means for players to find eachothers' games. However, NAT punchthrough comes in when one player running a server behind a router would otherwise be invisible to other players' connection attempts. To perform the NAT punchthrough I just have a player/client send a message to the master server that tells it what game server it's trying to connect to, and being that the game server itself is updating the master server as to its existence (aka a 'heartbeat' to keep itself listed) there is already a NAT tunnel provided between the master server and the user's game server, at which point upon receipt of a 'attempting connect to...' message received from another player the master server then tells the game server itself what IP/port a player is trying to connect from - which is when the game server itself then sends out a 'trailblazing' packet to that user's IP/port so as to open a path in its own router's NAT. That's what opens up the channel that will allow the connecting player's "connect" packet to get through and establish gameplay.

If you're running all games on one master server, then there's no need for NAT punchthrough, unless your master is behind some kind of NAT, in which case you just need to set up port forwarding so that all players can connect to it. Otherwise, if for some reason you need clients to be able to intercommunicate, then yes, you're going to need to establish some means of relaying a sort of "hey I'm trying to connect with you" protocol across the master server itself between clients.

NAT punch-through shouldn't be an issue in a client-server architecture where the server is publicly known and available, as it is in your setup.

That being said, such a setup isn't very scaleable, so depending on how popular your game becomes, at some point you'll need additional game servers to handle the load. You'd still maintain the one "master" server, however instead of hosting games itself it will contain a list of available game servers, and the master server will direct clients to connect to those servers instead to play the actual game. But again, if these are public servers, then NAT punch-through isn't an issue. Only once you start hosting games on private client machines will you need to start worrying about and performing introduction and matchmaking services.

The decision to use hosted servers versus user servers ultimately comes down to the kind of game you're making, and what kind of online support you want to have. The benefit of public servers is that they're generally always available, you can ensure they have the right hardware and bandwidth requirements, and you know that users haven't tampered with them (good for tournaments or "official" games). The downside is that you have to pay for them, maintain them, and make sure you're scaling them properly to support your customer base. If you have players across the world, you also need to decide how to split up your servers between geographical regions to ensure an optimal online experience for everyone.

Private user servers benefit from allowing localized groups of users (i.e. all on the same LAN or in the same region) to set up their own servers and play, which not only eliminates a lot of latency issues with WAN servers, but also gives you built-in scaleability, since theoretically the number of servers available should scale with the size of the user-base and popularity of the game. They're also typically easier to mod, since the server is physically available. The downsides are that you'll need to have a way for players to find each other, either though a "matchmaking" service, a broadcast-based protocol for LAN games, manually entering IP addresses into a text field, etc. You also can't guarantee that a user server has sufficient hardware requirements, or even the proper bandwidth (game server hosting on residential internet is also often prohibited by ISP terms of service). You can't trust a random user server to not have mods or hacks, so you can't guarantee a fair gameplay experience through architectural or technological means. And if you use a hybrid approach of hosted and private servers, users will have access to the server and can more easily reverse-engineer its behavior, giving them insight or an advantage even when using hosted servers.

I want it to be scalable but still have the clients only communicate via server. Money is not really a problem, hosting at digital ocean starts at 5$ a month and can be upgraded performance and cost wise at powers of 2. They have servers around the globe so latency should not be a problem for anyone either. I do not need any heavy lifting like running physics on the server, it's mostly just calculating numbers and verifying if the client input is legit.

So it seems I do need a master server and this does leave some newbie questions.

• These Game Servers should be always running right? And the master server should have access to some sort of list to connect to them. To clarify, it's not like the master server starts a server somewhere to host a single game for a couple of players. The master server communicates between these running game servers, list there games, registers the outcome, etc.
• Would I need to take into account for multiple servers in the same region? I'm aiming high but I'm not going to have a user base competing with the big boys. But even then, these game servers could just be upgraded to some sick enterprise model to keep them running right? By the time I have millions of people playing concurrently I can easily pay for some upgrades.
• Leaving the Master Server connection opened would not be a problem right? I still want to use it for chat and private/public lobbies. Or am I still not grasping the concept?

Have to do some more experimenting with this but seems doable.

In my game (project) I have a master server, which is strictly for keeping track of game servers themselves - which are operated by users/players themselves. All I am doing is offering the game and a means for players to find eachothers' games. However, NAT punchthrough comes in when one player running a server behind a router would otherwise be invisible to other players' connection attempts. To perform the NAT punchthrough I just have a player/client send a message to the master server that tells it what game server it's trying to connect to, and being that the game server itself is updating the master server as to its existence (aka a 'heartbeat' to keep itself listed) there is already a NAT tunnel provided between the master server and the user's game server, at which point upon receipt of a 'attempting connect to...' message received from another player the master server then tells the game server itself what IP/port a player is trying to connect from - which is when the game server itself then sends out a 'trailblazing' packet to that user's IP/port so as to open a path in its own router's NAT. That's what opens up the channel that will allow the connecting player's "connect" packet to get through and establish gameplay.

If you're running all games on one master server, then there's no need for NAT punchthrough, unless your master is behind some kind of NAT, in which case you just need to set up port forwarding so that all players can connect to it. Otherwise, if for some reason you need clients to be able to intercommunicate, then yes, you're going to need to establish some means of relaying a sort of "hey I'm trying to connect with you" protocol across the master server itself between clients.

Then I do not need to worry about NAT punchthrough at all. I will always have a authoritative server between clients. Thanks.

These Game Servers should be always running right? And the master server should have access to some sort of list to connect to them. To clarify, it's not like the master server starts a server somewhere to host a single game for a couple of players. The master server communicates between these running game servers, list there games, registers the outcome, etc.

I don't see any reason not to keep them running. The game servers would probably spend a lot of their time sitting in an "idle" state anyway, consuming few resources, waiting for the master server to "wake" them, create the actual game state, and accept connections from whitelisted clients. Once the game is over, the server destroys the game state and goes back into an idle state.

You can even split that into two separate applications, one that is *just* a game server, and another that acts as a "controller", listening for master server commands and spinning up game server applications as needed. You can get really creative with how you tier your servers, depending on your needs and requirements. There's no single solution.

Would I need to take into account for multiple servers in the same region? I'm aiming high but I'm not going to have a user base competing with the big boys. But even then, these game servers could just be upgraded to some sick enterprise model to keep them running right? By the time I have millions of people playing concurrently I can easily pay for some upgrades.

It's one of those problems that would be nice to have one day, but you don't have to worry about just yet. Definitely design for a bit of scaleability, but don't over-complicate things to a point where it never gets off the ground. If you ever reach a point where you have millions of players and need to scale your architecture, you'll be in a position to fund that effort anyway :)

Leaving the Master Server connection opened would not be a problem right? I still want to use it for chat and private/public lobbies. Or am I still not grasping the concept?

I usually prefer multiple servers that each have a single purpose, over a single server that has multiple purposes. It simplifies the design of your servers and allows each to be developed, managed, and scaled independently. So instead of the master server handling chat, you have a separate chat server specifically designed to handle a large number of connections and typical chat traffic. You can even have a separate chat server for each game server, so that players can chat independently of whatever is happening in the game, i.e. the game server starts to lag or crashes out, players can still chat, send help messages to an admin, etc.

These Game Servers should be always running right? And the master server should have access to some sort of list to connect to them. To clarify, it's not like the master server starts a server somewhere to host a single game for a couple of players. The master server communicates between these running game servers, list there games, registers the outcome, etc.

I don't see any reason not to keep them running. The game servers would probably spend a lot of their time sitting in an "idle" state anyway, consuming few resources, waiting for the master server to "wake" them, create the actual game state, and accept connections from whitelisted clients. Once the game is over, the server destroys the game state and goes back into an idle state.

You can even split that into two separate applications, one that is *just* a game server, and another that acts as a "controller", listening for master server commands and spinning up game server applications as needed. You can get really creative with how you tier your servers, depending on your needs and requirements. There's no single solution.

Would I need to take into account for multiple servers in the same region? I'm aiming high but I'm not going to have a user base competing with the big boys. But even then, these game servers could just be upgraded to some sick enterprise model to keep them running right? By the time I have millions of people playing concurrently I can easily pay for some upgrades.

It's one of those problems that would be nice to have one day, but you don't have to worry about just yet. Definitely design for a bit of scaleability, but don't over-complicate things to a point where it never gets off the ground. If you ever reach a point where you have millions of players and need to scale your architecture, you'll be in a position to fund that effort anyway :)

Leaving the Master Server connection opened would not be a problem right? I still want to use it for chat and private/public lobbies. Or am I still not grasping the concept?

I usually prefer multiple servers that each have a single purpose, over a single server that has multiple purposes. It simplifies the design of your servers and allows each to be developed, managed, and scaled independently. So instead of the master server handling chat, you have a separate chat server specifically designed to handle a large number of connections and typical chat traffic. You can even have a separate chat server for each game server, so that players can chat independently of whatever is happening in the game, i.e. the game server starts to lag or crashes out, players can still chat, send help messages to an admin, etc.

Awesome points, I have plenty more research to do.