[Turn] A classic network game server architecture

Turn from:

Http://www.cppblog.com/johndragon/archive/2008/04/10/46768.html

For study purposes reproduced, if there is improper or infringement, please contact ~

This diagram is an architectural diagram of a zone, with the same schema for all zones. The ServerGroup of the dashed box above is the same as the schema in the adjacent box. All x-n servers on the graph are joined together by multiple units. There are also illustrations on the red, green, and blue lines, and there are no more introductions. About Agent server as you can see, it's actually gate.
Here we mainly introduce the content and meaning of the data connection on the location of the marked number.

1-This is a WebService pipeline, when the user activates the area account, or modifies the account password, through this channel to insert and update the user's account information.
2-This is also a WebService pipeline to get and control the user's role information within that group, as well as update operations such as paying store tokens.
3-This is a local TCP/IP connection, this connection is mainly used for the server group in the login server registration, as well as the login server authentication account, to the user server to register the account login information, as well as the login account role information to operate (such as kicking off the current login role), There are also information updates for the server group (number of players currently online, etc.).
4-This is also a local TCP/IP connection, which is used to authenticate the client connected to the Gameserver, to obtain the role data information, and to return the change of the data information of the role on the Gameserver.
5-This connection is also a local TCP/IP connection that is used for the interaction between the public Information Server and several game servers to Exchange world-class information (such as guild information, cross-party messages, cross-service chat channels, etc.).
6-Two connections here, to express the meaning is that the agent Userserver and Gameserver can be used interchangeably, that is, after the player enters the group, there is no need to switch agent. If not afraid of chaos, you can also log on the server Agent, so that users throughout the process will not need to replace the agent, reduce the number of repeated connections, but also improve the stability. (after all, the number of connections is less, but also reduce the likelihood of the occurrence of the server)

In this architecture, Gameserver is actually a complex of game logic that can then be expanded into several different logical servers, with Publicserver for public data exchange.
Userserver actually played the role of a ServerGroup leader who was responsible for registering and updating the server group's information (first name, current number) to Loginserver, and dispatching the agent Provides a minimum number of agents for players who have selected this group. At the same time, it also has a role Management Server function, sent to the client's current role list, the role of the creation, deletion, selection and other management operations, are carried out here. Furthermore, it is an authentication server for user information, which gameserver need to authenticate the client and obtain the role data information of the player's choice.


Games that use this architecture typically have the following performance.
1-The user must activate a large area in order to log in to their account in a large area.
2-When the user launches the client, it pops up a login and selects a large area.
3-When the user starts the real client, it starts with the account password.
4-After the account verification is complete, make the server selection in the zone.
After the server selection is complete, enter role management. At the same time, roles cannot be shared on different servers.

There are many games in the market that match the above features, and there is no shortage of masterpieces. This architecture is not a new architecture, but it is classic and perfect, and logic is simple and clear, used to do MMORPG, or other network game server architecture, is a good choice.

————————————————————————————————— I'm a split line —————————————————————————————————————————————

And then the content is our own.

Development to now actually have some stones feeling, as of last weekend we had a second server, is a chat server, another server monopoly overall situation, responsible for landing, recording players, storage scenes and so many seem to actually do nothing.

Due to the development of a simplified consideration of our many processing and monitoring are done on the client, the server participates in the calculation of less, mainly the data synchronous forwarding broadcast these functions ...

In Sprint3 we are going to do a new server is a scoring server, in other words, the user server, does not involve too many logical relations, but also just some processing of data.

From the above framework, our framework is simply fragile, but we have the idea of moving in this direction, after all, a single server workload is too high load, and may cause delay lag and so on the player's disastrous impact,

This separation of functions can indeed improve efficiency and make the entire logical structure clearer.

I've only written a variety of courses. I feel the architecture of this thing is really magical ... The original structure should have been finalized before the start of the work, we have so with experience to get now ... It is also a lot of accumulated lessons ...

From the above content to see our game there is a more serious problem is that we are now the client directly connected to each server, and the lack of an intermediate layer is agentserver as a medium to communicate with the back of the server, which is not our project currently doing a bad point,

Change should be too late to change, only in future projects (if you have access to similar projects) more attention.

[Turn] A classic network game server architecture