Sun open source game server project Darkstar server -- (Sun game server, SGS) Study Notes (1): SGS Introduction

SGS Main functions provided :

Server Expansion  :  The traditional expansion method is to divide the entire game area into multiple zones, and different zones run on different game servers. there are two problems. One is that players in different zones cannot interact with each other, and the other is that if there are few actions in a zone, the server resources may not be fully utilized. in SGS's processing method, all processing is divided into small execution units (called tasks ). Task It can be executed on any SGS server in the network. When a user increases, the system automatically adds processing threads and does not need to allocate different zones to different servers for expansion. this not only improves resource utilization, but also enables interaction between all players.

Data Integrity  : SGS  A Distributed Data Storage is provided. When a task needs to access data, it uses the data storage API for access. ,  Data access is supported by transactions. When two tasks conflict, SGS automatically coordinates. Task  Reschedule is waiting for execution, and the old task will be executed until the end. In the current version, SGS data storage does not use relational databases, but uses Berkeley dB. Any Java object, as long as it is implemented Managedobject  The flag interface and the serializable interface can automatically display transparent storage. (The storage mechanism of SGS seems to be scalable. Someone has discussed the storage plug-in of MySQL on the Forum)

simple programming model : from the perspective of application development, SGS provides APIs to shield most of the underlying complexity, such as thread scheduling, transaction processing, and so on, the application Program only needs to develop and assemble its own objects, listen to and respond to client events, and manage its own persistent managedobject object lifecycle.

Two Communication Models  :  One is client/server communication, that is, each client only communicates with the server ,  The server is responsible for data processing and forwarding. The other is the channel mechanism (similar to one-to-many broadcast). The channel is created and maintained by the server, and multiple channels can be added for each channel. Client, Server  You can listen to all the communications in the channel or the communications between a specific client. You can also Channel  All or part of the client sends messages. the client that joins the channel can receive messages sent by any other client. communication between clients under the channel does not require server intervention. because all communication data formats are byte arrays, applications need to develop their own application layer protocols.

Scalable Mechanism  : SGS  Applications access data and use channels to create tasks through "manager". Currently, there are three default types. "Manager", datamanager, channelmanager, TASKMANAGER.  However, you can expand and develop your own manager. For example, in SGS, the task should be executed as quickly as possible (the maximum time allowed by the task can be configured ), therefore, if you call a system method that may cause blocking, You need to develop an extended manager.

Darkstar  the project provides a development environment for game developers. In this environment, developers only need to use the Inherent Parallelism of the virtual environment to expand the environment without learning distributed computing or multi-thread programming. The Darkstar Project is a developer's dream. The server-side application Code can run on a single machine, single thread. In fact, the tasks executed by the server can run on many machines and threads, increasing the scalability and tolerance to some extent. The system optimizes the low latency required by game applications. Each node of the Darkstar project cluster runs a copy of the game server code (written by the game developer, including the game logic). The Code is located on the protocol stack of The Darkstar project. The protocol stack is displayed as a group of services to game servers. These services control the game's persistent status, communication channels, and task creation and calling. The task, the unit of work of the game server, responds to messages sent by players or some internal triggers, and is implicitly executed in a transaction. Parallel Control is transparent to game developers. When a task needs to access an object that has been locked by another task, tasks in transaction processing will be packaged and run up, the task will be rescheduled later. The transaction nature of the task also ensures that the relevant task can establish a serial execution sequence.

You can use multiple threads to expand a single node. These threads are controlled by the task scheduler. Further expansion allows multiple nodes (either an actual machine or a virtual machine) to collaborate to run the same game. This function is provided by the Service structure of the Darkstar project. The application runs on the infrastructure, ensuring that any task executed by the system can be migrated from one machine to another, load Balancing and enhanced reliability.

All game objects exist for a longer time than a single task. You need to create them in the Data Service and save them to the database. Before a task operates on any objects, it must read them to make sure they are working in the latest state. Data Services are supported by databases. Currently, the database server uses Berkeley dB because of its performance and open source software. However, interfaces between data services and backend databases can also be other databases, such as ipvs or MySQL.

Darkstar  The project coordinates communication through the session service and channel service. Session Service provides direct communication between game clients and game servers. The channel service provides a publish/subscribe communication mechanism. messages in the channel can be sent to all subscribers in the channel. This mechanism provides client and client conversation services. These two communication modes are based on the abstract concept of the basic communication mechanism provided by the underlying operating system. You can release the communication endpoint in any special node of the Darkstar project cluster. In this way, communication between any special intermediate node in the server cluster is free. These channels can be moved from one server to another, with optimized performance or fault recovery.

If the purpose of the data service is combined with the portability of the communication channel, each task can run on any machine without changing the task execution performance. That is to say, the load can be moved from one machine to another. In the process of moving, by simply adding more machines to the node set where the game is running, the load capacity can be increased or reduced. In addition, the meta service in the infrastructure of the Darkstar project will participate in dynamic mobile tasks to ensure the location of data access and communication. These services are invisible to game developers. They can observe the basic services in the infrastructure of the Darkstar project to determine the optimal load of system nodes, detect faults, and restore them to the initial state, detect new resources so that they can be added to the entire system in the future.

Third-party vendors can improve the basic services of the Darkstar project. New services can be introduced and participate in task execution activities. These services can interact with the transaction mechanism and observe the entire system using the meta service. For example, it can access a complete relational database, track game statistics, and allow query of these statistics, and expand game management capabilities without the need for game data service storage information, optimized the low access latency required by many games.

Summary of Project advantages

Darkstar the project architecture has many important advantages, including:

2. A simple Development Model
   
   although the infrastructure of the Darkstar project provides a scalable multi-threaded Multi-node environment, however, game server developers write code in a single machine and single thread environment. This model minimizes or eliminates Data Access competition, thread scheduling, and workload distribution, allowing developers to concentrate on writing games without having to focus on scalable system mechanisms. As we all know, writing a complex, multi-threaded game application is a difficult and hard task, and few programmers have the experience and skills to successfully develop such applications. With the infrastructure of the Darkstar project, the development complexity will be greatly reduced, and the skills required by programmers are only related to the game and not to the environment.
4. improved scalability through dynamic load balancing
   
   the architecture allows the system to expand linearly to meet the increasing demand for computing resources. Additional requirements are usually caused by the increase in the number of concurrent online players, the increase in application complexity, or the simultaneous occurrence of both. In either case, considering the dynamic behavior during game operation, the architecture automatically performs load balancing to respond to the increased task load. When more capacity is required, more computing nodes are simply added to the available server pool. Multiple games can even share servers in the computing center. In today's gaming industry, the existing architecture cannot fully achieve such resource sharing and scalability.
6. designed for future computing technologies
   
   the main chips are designed to use parallel technology, has the performance improvement function. Although Single-Chip multithreading saves energy, increases throughput, and extends Moore's Law, if those programs want to benefit from the new hardware stage, they need to be written in different ways. The infrastructure of the Darkstar project has performance improvement functions and does not need to change the game code itself.
8. robust game operation capabilities
   
   Darkstar the basic structure of the project system is designed to facilitate the development of large-scale multi-player online games, and the game will be more robust than any game in the industry so far. Gaming server crashes, database damages, and programming errors are common. Therefore, companies need to organize large internal developer teams, network experts, and operators to maintain the game. This has been confirmed in the Financial and enterprise sectors that require absolute reliability. We believe that the games created by the Darkstar project will be more robust, with simpler maintenance and enhancement, it does not sacrifice the performance required by interactive games. This will shorten the development cycle (shorter time required for new games and new features from conception to market), reduce development costs, and reduce support and operation costs.
9. Effective use of computing resources
   
   Darkstar  A project is a complete game architecture, that is, its operation model does not need to allocate specific hardware to a specific game region. When a game is required, available server resources can be dynamically distributed. Using the Darkstar model, you do not have any restrictions on the fragment architecture, as shown in Second Life  in most other fragmented architectures such as MMO, some servers are overloaded while others are idle. For example, the public useful data shows that Second Life is characterized by the use of only 5% or fewer servers when the island capacity is severely limited. However, they are still adding many machines to their infrastructure, trying to keep up with the increase in the number of subscribers. The Darkstar project architecture is enabled with higher server utilization, which saves machine costs and infrastructure and operation costs. Therefore, the cost is completely reduced, which can be effectively allocated to multiple protocol stacks across a single game or multiple games. In today's gaming industry, you still cannot find the flexibility of such deployment and the reusability of computer resources.