Sign in to follow this  

Logging into network of servers.

This topic is 3744 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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 client

Here, 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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus

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 client

Here, 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?


Share this post


Link to post
Share on other sites
Quote:
Original post by Tesshu
Quote:
Original post by Antheus

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 client

Here, 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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Game Programming Gems 6 has an Article from someone from ubisoft.
What the do is basically have a so-called "proxy" server to which
the 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 if
it receives the ok, it'll open a connection to the appropriate server
(note that the client, once the connection is made, doesn't have to
do 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-adresses
to outside clients. So they only have the proxy-servers to attack.

/R

Share this post


Link to post
Share on other sites

This topic is 3744 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this