Login Server for MMO

This could be achieved with an "authenication token", some encrypted data with an embedded date. The data is user specific, perhaps their user-id or similar. It is unforgeable, the client doesn't have the key. It is opaque, the client cannot determine anything about it, it can only hand it back to a server who has a key to decrypt it. It is only valid for a specified time period, so a token cannot be reused once this period expires.

This way all your servers can independently check if the user has recently been authenticated. The client should only send the authentication token through a secure channel, to prevent 3^rd parties from stealing it and acting like the user.

The Kerberos protocol is an example of such a system. At the very least it will give you a good idea of how it can be made to work, the drawbacks of this approach and mistakes they made. You might even be able to use part of their implementation or architecture for your game.

Thanks. I'll look into how they do that. It makes a lot of sense.

As a variation of rip-off's suggestion, the login server could generate a session id and store it to the database (along with the user id & timestamp) and give a copy to the client. The client then presents this to the actual game server which checks the database and sees if the session is valid.

The difference is that the session id is random instead of containing encrypted player information-- it is used as a short-lived passkey. This is fairly standard way of handling authentication on the web.

The problem with putting session IDs in the database is that you add significant database load. If you have lots of shortlived requests, and can use Kerberos-style authentication (as described above), then you probably should, because it will let you scale your system better and cheaper.

Btw: I have an article on authentication for games in Game Programming Gems 7. I highly recommend it :-) There are also some links in the Forum FAQ.

I have solved this by keeping the connection on the login server which relays the messages to the "main" server.

1 The user connects to the login server and a connection is created.
2 When the user has supplied the correct username and password, the connection can tell your "main" server to create a player object.
3 Connect the login server with the player object on the "main" server, probably by using tcp sockets.
4 All messages arriving to the connection on the login server can be filtered and relayed to the object on your main server.

The advantages is that you don't need put anything in the database and you can also put your "main" server behind on local network, protecting it better from evil hackers.
The CPU cost of filtering or even encrypting/decrypting the data is also affecting your login server instead of your "main" server.

The disadvantages is that a message has to be first sent to the connection server and then sent again to your "main" server, same overhead applies when you want the server to send something back.

I think you are adding alot of complexity to handle a situation that might never happen.

Make game work first. Optimize later :)

As mentioned a few times before we had a single threaded C/C++ server handling thousands of players with no problems ;)

I know a lot of people would like to complicate writing an MMO with words like "scalability", "complicated", "hundreds of servers" etc.

Fact is. Will your homemade mmo ever reach a 1000 players? One WoW node hard pressed have about 2500 players.

I know a few successfull homemade mmo's that can reach 10-18 players at once on a good day ;)

And I've worked on a few launched (commercial) mmo's where there's usually about 25-80 players on at the same time (hard competing with WoW)