Logon servers

The logon server would send a request of "some kind" to the actual game server. This can be as easy or complicated as you wish.

In the easiest case, it could be a custom protocol (such as username/userID plus an authentification token) over a plain normal TCP connection, or if you want to use something that "already works", encapsulate that in a HTTP request. Or, anything you like.

You will probably want to add some form of encryption and message authentication (you would not usually trust the LAN in your datacenter, even if it's a virtual private network the data still goes "over some cable" that someone could possibly eavesdrop or modify), and a sequence number, and something that ties the logon token to an IP address, etc. etc., to prevent all kinds of replay/token theft attacks, but depending on how high or low your paranoia level is (and depending on how interesting breaking into your game is!), you may not even bother.

I'm sure I remember hplus0603 wrote a chapter in a book about all this... let me dig into the shelves...

EDIT: There it is: Game Programming Gems 7, chapter 6.2 (pp 481-491)

Also note that you don't really need to have the logon server separate, but it makes sense:

• Logging in and playing are different things, so it's logical to run them on different servers (even if they're on the same physical machine).
• If the logon server crashes, the game still works on.
• If a script kid is trying a dictionary attack on the logon server and it's on a different machine, the game goes on.
• Login can use expensive algorithms like bcrypt that are forbidding on the same machine the game is running. If it's another machine, it has no effect at all.
• It's scaleable and manageable. You can have 20 game servers, or 200, or 20,000, and still have an "easy" login via a central point (one logon server on a "fallback IP" that redirects to a second logon server in case it dies -- that's a service most hosters offer for very little $$$).
• You can do some coarse load balancing by assigning a random game server, or by keeping track of current users per server (or other "tricks", such as giving a player a geographically close server if you have servers in many locations).
• If one of your 2000 servers dies, people still log onto the same logon server and are directed to another game server. They never know. Same if you add another 5 servers.

EDIT: There it is: Game Programming Gems 7, chapter 6.2 (pp 481-491)

I was going to suggest that, but you beat me to it :-)

One well-known public implementation of a similar system is the Kerberos system. You authenticate to a system, it gives you a ticket, other machines can validate this ticket.