2 replies to this topic

[rpiller]

My understanding is that most online games have Logon servers which is it's own application and can be on it's own physical server that is done specifically for logging the players in. If that's true, how does the game server end up knowing that said user was logged in correctly since that would be a separate program. Is there networking between the logon server and the game server as well as back to the player to communicate all of this?

 

I guess I'm picturing client sends details to login, logon server validates and if success sends to the game server to create said client over there, then after it gets response from the game server, sends response back to the user that they were connected with some kind of session ID (which the game server knows about also).

[samoth]

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.

[hplus0603]

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.