Looking for Feedback: Master Server/Database Configuration
by DavidRM · in Technical Issues · 07/21/2006 (3:26 pm) · 5 replies
For my current project, I'm considering this approach to having a centralized player database, master server, and hosted dedicated servers.
1. The centralized database will be "local" to the master server and dedicated servers, and will only be accessed by those servers.
2. The player will send new account and login verification information to the master server. The master server will interact with the database, sending the result (pass/fail) back to the client. Only if the player passes will he see the list of games.
3. The master server will coordinate the player logging into dedicated servers by sending an "impending connection" to the dedicated server (with the player's IP addy, account name), and the IP of the dedicated server to the player. If a player tries to connect to a dedicated server without an announcement from the master server, the connection is rejected.
4. The dedicated server will pull the player's account information (equipment, stats, etc) from the database when the player logs in. When necessary (a match begins, ends, or the player disconnects) the dedicated server will save the player's information back to the database.
Without getting too much into the specifics (like which database software I'll use), does this sound like a feasible approach? Are there cases/considerations I've missed? Overkill? Underkill?
A few of the goals I had in mind when thinking this through are:
* The master server will know whether a player is new, playing for free, or a paid account.
* Only the master server handles login verification and non-game-specific player information (like address, age, etc.)
* Only the dedicated server updates the player's game-specific information, and they can coordinate amongst themselves to prevent the player being on more than one server at a time.
* Players can host their own servers, using the master server to handle login verification (passwords never sent other players).
Again, I'm looking for feedback here, suggestions for improvements and critiques of what seems really stupid.
Also, if something seems unclear, please feel free to ask.
Thanks!
-David
1. The centralized database will be "local" to the master server and dedicated servers, and will only be accessed by those servers.
2. The player will send new account and login verification information to the master server. The master server will interact with the database, sending the result (pass/fail) back to the client. Only if the player passes will he see the list of games.
3. The master server will coordinate the player logging into dedicated servers by sending an "impending connection" to the dedicated server (with the player's IP addy, account name), and the IP of the dedicated server to the player. If a player tries to connect to a dedicated server without an announcement from the master server, the connection is rejected.
4. The dedicated server will pull the player's account information (equipment, stats, etc) from the database when the player logs in. When necessary (a match begins, ends, or the player disconnects) the dedicated server will save the player's information back to the database.
Without getting too much into the specifics (like which database software I'll use), does this sound like a feasible approach? Are there cases/considerations I've missed? Overkill? Underkill?
A few of the goals I had in mind when thinking this through are:
* The master server will know whether a player is new, playing for free, or a paid account.
* Only the master server handles login verification and non-game-specific player information (like address, age, etc.)
* Only the dedicated server updates the player's game-specific information, and they can coordinate amongst themselves to prevent the player being on more than one server at a time.
* Players can host their own servers, using the master server to handle login verification (passwords never sent other players).
Again, I'm looking for feedback here, suggestions for improvements and critiques of what seems really stupid.
Also, if something seems unclear, please feel free to ask.
Thanks!
-David
#2
When I read the posts about people using HTTPObject and PHP Web pages, it makes me think I'm going about this very "old school", and I wonder if maybe I should look into that kind of thing.
But...with the need to update player information to a database, "old school" seems to make a lot of sense. It keeps the transferred data within the local area network, is relatively self-contained, etc.
I guess I'm trying to get a feel for how this sort of thing is being handled "nowadays".
Thanks!
-David
07/22/2006 (12:24 pm)
John: Good point. I'll give that some thought.When I read the posts about people using HTTPObject and PHP Web pages, it makes me think I'm going about this very "old school", and I wonder if maybe I should look into that kind of thing.
But...with the need to update player information to a database, "old school" seems to make a lot of sense. It keeps the transferred data within the local area network, is relatively self-contained, etc.
I guess I'm trying to get a feel for how this sort of thing is being handled "nowadays".
Thanks!
-David
#3
I use the Twisted framework. It's great for writing client/servers quickly.
-JR
07/22/2006 (2:06 pm)
I wrote a .plan that describes our server architecture evolution. It might be interesting to you. This architecture was written and is supported by one person... It doesn't get much more indie than that!I use the Twisted framework. It's great for writing client/servers quickly.
-JR
#4
I'll check out Twister. Thanks!
-David
07/22/2006 (4:17 pm)
Josh: I had read your blog post about server architecture with interest. Your needs are rather more demanding than mine, I think, and your new structure reflects that. I'll probably end up with something very similar to your original, simpler structure.I'll check out Twister. Thanks!
-David
#5
Hi David,
First off, what's your project? Are we looking at a MMO, FPS, impromptu games...?
At first glance, it sounds reasonable. You mention that the dedicated servers coordinate amongst themselves to avoid multiple logins... Since the master server is already handling traffic as far as alerting the dedicated servers to an impending connection, wouldn't that task be better handled by the master server? You could have the master server maintain the list of active connections, with the dedicated servers reporting connects and disconnects.
-- JohnDopp
<<<<<<<<<<<<<<<<<<<<<<<<<
no good, two reasons
1. Say 300 users in a part of terrain are thrown out due to a dedicated server failure, but all other players are playing fine. That 300 players will be busy logging back in at the same time and the master server will spend too much resource to take new requests and its performance to communicate with existing players will be severely compromised.
2. If master server is responsible for all inbounding and outbounding information, the computing capacity of the network card in the master server is a bottle neck to the whole system. a home network card can only handle 200-300 connections without borrowing power from CPU, a pro network card can only take 1000 itself. but if each dedicated server connect to the user directly, each can connect 1000 users without borrowing computing power from CPU.
08/22/2006 (12:55 pm)
>>>>>>>>>>>>>>>>>>>>>Hi David,
First off, what's your project? Are we looking at a MMO, FPS, impromptu games...?
At first glance, it sounds reasonable. You mention that the dedicated servers coordinate amongst themselves to avoid multiple logins... Since the master server is already handling traffic as far as alerting the dedicated servers to an impending connection, wouldn't that task be better handled by the master server? You could have the master server maintain the list of active connections, with the dedicated servers reporting connects and disconnects.
-- JohnDopp
<<<<<<<<<<<<<<<<<<<<<<<<<
no good, two reasons
1. Say 300 users in a part of terrain are thrown out due to a dedicated server failure, but all other players are playing fine. That 300 players will be busy logging back in at the same time and the master server will spend too much resource to take new requests and its performance to communicate with existing players will be severely compromised.
2. If master server is responsible for all inbounding and outbounding information, the computing capacity of the network card in the master server is a bottle neck to the whole system. a home network card can only handle 200-300 connections without borrowing power from CPU, a pro network card can only take 1000 itself. but if each dedicated server connect to the user directly, each can connect 1000 users without borrowing computing power from CPU.
Torque Owner John Doppler Schiff
First off, what's your project? Are we looking at a MMO, FPS, impromptu games...?
At first glance, it sounds reasonable. You mention that the dedicated servers coordinate amongst themselves to avoid multiple logins... Since the master server is already handling traffic as far as alerting the dedicated servers to an impending connection, wouldn't that task be better handled by the master server? You could have the master server maintain the list of active connections, with the dedicated servers reporting connects and disconnects.
-- JohnDopp