Card Phone Games service-side design based on HTTP protocol __ Architecture Design

Background:

Mobile gaming platform Server design at present there are mainly based on the socket state connection and HTTP stateless connection two kinds of architectures. Because the mobile phone users of the network traffic sensitivity and changes in the network state than the PC environment to be complex, so for card games basic use of HTTP connection architecture.

Basic principle:

A server based on the HTTP connection architecture, consisting of an API client page and a management Web site. Deployment and management operations are similar to Web sites. The server does not need to run a stable server-side program, which reduces the amount of operation and maintenance work. Because of the HTTP protocol, the extended concurrent users can also be used to purchase CDN services to solve. But only applicable to simple rules, for real-time interaction requirements of card-type games. For the complex rules, real-time interaction requires a high graphical network game is still commonly used in the way of socket to achieve.

The server design based on HTTP protocol has higher requirements for development design and architecture, and higher requirement for database design. The main calculations are based on the database, thus improving the performance and extending the angle of more connections. Database design strategies need to be based on the Sub-Library table. The deployment of Web pages is based on the distribution of functions and game types, levels of rooms and tables, and distributed deployment. There are also high requirements for the interaction protocol with the client. The client has a thread that constantly gets the current game state from the server to update the interface. When the server responds to the client request, the corresponding calculation is completed and the result is stored in the temporary data table and transmitted to the client via the JOSN protocol encryption.

Server-side system diagram

Service-Side System description

1 The first level is the game player system, including registration, prop shop management, membership Integration System. This part is planned to be developed on the basis of the mature imperial content management system.

2 The second level is the game management system. Including the game to add configuration management, the specific game of the main server open up, each game room and room card table settings and other types of game management related work. This part is also based on the Imperial Content Management system, the implementation of customized development.

3 The third level is the management of each game room. This section communicates through standard JSON APIs and client communication through standard JSON APIs and client communications. Select the room in the game according to the user points. and can provide to the client which user on-line condition, directs the user to enter the corresponding room.

4 The fourth level is the game room under the specific table management. This part is based on the rules and interactive features of each game, through the standard JSON API and client communication, complete the entire networking game process. To solve the big concurrency problem, each room has its own independent distributed database and is emptied at the end of the game.

I will follow up on the simple card game I realized to touch the point for the game demo, build the network version of the game, and complete the framework of the initial development and development of the architecture. When the right time for submitting GitHub to be open source to share, And hope that the master and game enthusiasts together to improve the framework. The current touch point of the stand-alone version can be downloaded to the 360 market.