Login and Game server separate? Why?
Author
What the reason behind separating server to Game and Login part... It make sense to separate database server and logic server... but why game and login? All login do is wait for people to log in and pass it to game server...
Consider what happens when you have so many clients that one physical game server does not have sufficient capacity of handling them.
Author
well.. that make sense..
If I understand.. if this problem occurs, Login can serve clients to multiple Game servers.
But that mean I need to build server structure so that players can be divided... I need to consider what communication will occur.
Simplest would be if I divide players according to location.. but that won't help if many player are at same location
Hard way would be to find some way to communicate with players that are on other game server. That would be easiest with 1 communication server which holds every player socket. Is that what login do? Or there is some other logic behind communicating with players that are on other Game server?
If I understand.. if this problem occurs, Login can serve clients to multiple Game servers.
But that mean I need to build server structure so that players can be divided... I need to consider what communication will occur.
Simplest would be if I divide players according to location.. but that won't help if many player are at same location
Hard way would be to find some way to communicate with players that are on other game server. That would be easiest with 1 communication server which holds every player socket. Is that what login do? Or there is some other logic behind communicating with players that are on other Game server?
The communication protocol between game servers is highly dependent on the game itself.
As far as I know, it is common that the server load is (somewhat) geographically partitioned so that the average communication latency inside given server instance is minimized. In a large-scale game, the servers would be connected to each other using high-bandwidth (but not necessary low latency) network for state synchronization.
The partitioning could also be based on the game geography - for example, depending on where the players dwell in the virtual world. This way, it is more easier to control the loads based on anticipated usage of different areas of the game.
As far as I know, it is common that the server load is (somewhat) geographically partitioned so that the average communication latency inside given server instance is minimized. In a large-scale game, the servers would be connected to each other using high-bandwidth (but not necessary low latency) network for state synchronization.
The partitioning could also be based on the game geography - for example, depending on where the players dwell in the virtual world. This way, it is more easier to control the loads based on anticipated usage of different areas of the game.
Author
Well i think i will need to figure it out alone.. every server got it's own system as it seems.. some got login, game.. others got login, game, map server...
Well.. at least I know I need to build it so i CAN divide gameservers.
thx..
Well.. at least I know I need to build it so i CAN divide gameservers.
thx..
Solving the general problem of distributing coherent, dependent solution over servers (where two people that are interacting may be on different physical machines) with sufficient performance for games is hard, and an open research problem in many respects.
Most MMO's check billing and account info on login. Probably not a task you would want to ask a gameserver (especially at peak times).
Keeping a connection open to a database and running a stored procedure on log-in is pretty much zero load, given that the player will talk to the server a lot while playing anyway.
A much better reason is that the login server often also has another function, such as figuring out which simulation/game server actually should contain the player, and telling both the server and the player about the new object that is popping into the world. In a sense, the login server can work as a simple redirector (not gateway) service for the player trying to find the right game server to connect to.
Regular DNS doesn't really work that well for that, because if there are 20 different zone servers, the client can't know which zone server would contain the player's character when he logs in -- it can't store it locally, because the player can play from any other machine, too.
A much better reason is that the login server often also has another function, such as figuring out which simulation/game server actually should contain the player, and telling both the server and the player about the new object that is popping into the world. In a sense, the login server can work as a simple redirector (not gateway) service for the player trying to find the right game server to connect to.
Regular DNS doesn't really work that well for that, because if there are 20 different zone servers, the client can't know which zone server would contain the player's character when he logs in -- it can't store it locally, because the player can play from any other machine, too.
Author
If I understand.. it mean that if I will have just one server.. i don't need to divide my server. I can make it as one app with multiple threads. That was my original idea :) thx
Quote:if I will have just one server.. i don't need to divide my server
That's right. Good luck with your game!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
