   Logging into network of servers.
  I was wondering how people handle logging into different servers.  Right now my server handles login, character management and simulating the world.  So the game is simply two programs (client/server).  Now that I have it going I want to split the world simulation into a separate program that can run on a different computer (say login server and game server).   I am using mysql to handle the account info, so when someone logs in right now, the game pauses while I do a mysql access to check id and password.  So if my new login server does this access, I don't think the pause is a big problem.  The problem is that when I hand the player off to the game server, do I have to do a full login from scratch, and thus access mysql? How do people handle logging in?  Do I need to write some kind of aysnc code to handle this?  Also sometime when I see people talking about their network structure, they seem to imply that they have one computer that takes all outside access and routes it to internal computers.  Do people really do this?  I would assume most all computers would be visible to the Internet and have the players access them directly, except for stuff like mysql computers.   
Quote:I am using mysql to handle the account info, so when someone logs in right now, the game pauses while I do a mysql access to check id and password. So if my new login server does this access, I don't think the pause is a big problem. The problem is that when I hand the player off to the game server, do I have to do a full login from scratch, and thus access mysql? How do people handle logging in? Do I need to write some kind of aysnc code to handle this?The one and only responsibility Login server has is to perform the login. After that, the user is logged in, and no other server is concerned with that.BTW: pause *may* be a problem, for example, if you need to restart the server, or it comes online, you'll be flooded with login requests, but you'll be conveniently blocking on each query. But this is *maybe* category.Once your login server authenticates, you assign some internal id to the user. If you need to have them access multiple servers, it's common to give each client a unique, random token (an arbitrary number, large and random enough). Then, when they pass this token around, you always know who they are.There's also another approach. When you hand-off player information between servers, you'll usually be telling both the client, as well as the servers, what is about to happen. In that case, you might not even need any kind of authentication.The exchange looks something like this:- Server A tells Server B that client will be transferred to it- Server A tells client to connect to server B- Client connects to Server B- Server B tells A that it has accepted the clientHere, A and B can be login or game or some third server. It merely assumes that at some point, client has been allowed to connect to the network.After that, you make the assumption, that your internal servers are reliable and fair.   ;Quote:Original post by AntheusOnce your login server authenticates, you assign some internal id to the user. If you need to have them access multiple servers, it's common to give each client a unique, random token (an arbitrary number, large and random enough). Then, when they pass this token around, you always know who they are.There's also another approach. When you hand-off player information between servers, you'll usually be telling both the client, as well as the servers, what is about to happen. In that case, you might not even need any kind of authentication.The exchange looks something like this:- Server A tells Server B that client will be transferred to it- Server A tells client to connect to server B- Client connects to Server B- Server B tells A that it has accepted the clientHere, A and B can be login or game or some third server. It merely assumes that at some point, client has been allowed to connect to the network.After that, you make the assumption, that your internal servers are reliable and fair. Great, thanks for the reply.  So for either method, how does a server know that it's the login server that it's talking to and not someone hacking?  Do you store the ip address of the login server for verification?;Quote:Original post by TesshuQuote:Original post by AntheusOnce your login server authenticates, you assign some internal id to the user. If you need to have them access multiple servers, it's common to give each client a unique, random token (an arbitrary number, large and random enough). Then, when they pass this token around, you always know who they are.There's also another approach. When you hand-off player information between servers, you'll usually be telling both the client, as well as the servers, what is about to happen. In that case, you might not even need any kind of authentication.The exchange looks something like this:- Server A tells Server B that client will be transferred to it- Server A tells client to connect to server B- Client connects to Server B- Server B tells A that it has accepted the clientHere, A and B can be login or game or some third server. It merely assumes that at some point, client has been allowed to connect to the network.After that, you make the assumption, that your internal servers are reliable and fair. Great, thanks for the reply.  So for either method, how does a server know that it's the login server that it's talking to and not someone hacking?  Do you store the ip address of the login server for verification?IP addresses can be spoofed too, although I've heard it is difficult as ISPs now try to control it. As an alternative you could digitally sign messages from the login server (or just encrypt them).   ;Quote:Original post by Tesshu Great, thanks for the reply.  So for either method, how does a server know that it's the login server that it's talking to and not someone hacking?  Do you store the ip address of the login server for verification?Because you're in control of the login server.That means, you can add internal information to communication, and hand-offs are performed through intranet only.If someone not outside of your immediate subnet (127.x.x.x) tells you they are login server, you know they are not.You'll need some way to physically separate inside from outside anyway, so you might as well block all the ports you're using for internal communication (10000-11000), and ignore any request to them from outside.Client does connect to servers, but they are never an authority. Your internal servers are who determines who gets access to what.   ;  Game Programming Gems 6 has an Article from someone from ubisoft.What the do is basically have a so-called "proxy" server to whichthe clients connect.This is the only server(-type) (ip-adress) visible to the outside world (of course you might have several proxy-servers visible).The proxy-server forwards the login request to the login-server and ifit receives the ok, it'll open a connection to the appropriate server(note that the client, once the connection is made, doesn't have todo anything, the proxy-server connects to whatever server is needed -note that all server run in a LAN, so connection-speed is not an issue).This way, you don't show your internal network structure & ip-adressesto outside clients. So they only have the proxy-servers to attack./R   ;  I use authentication using a cryptographic cookie.Networked game authentication.Any server that sees the cookie can know that the cookie was issued by some other server that has the same cryptographic key.   