Skynet: Start

Skynet is a lightweight framework designed for online game servers.

The simple Web service tends to store the user-related state information (design data structure) in the database, after receiving the user request through the network, read out the status information associated with the user from the database, and then write back to the database. Online game services typically have a stronger contextual state and more complex interactions among multiple users. If the same pattern is used, bottlenecks can easily occur between the database and the Business Processing module, and this bottleneck cannot even be solved completely by adding a memory cache layer.

In Skynet, the concept of service is used to express a specific business, which includes the logic to process the business and the associated data state. Yes, when implementing a game server using Skynet, it is not recommended to synchronize the business state to the database, but to store it in the service's memory data structure. The service, together with the logic code of the service processing business and the state data of the business association, are resident memory. If the database is part of your architecture, in most cases it plays a role as a data backup. You can either push the data to the database when the state changes, or you can write to the database backup on a regular basis. The business process uses memory data structures directly within the service.

Simply put, Skynet can be understood as a simple operating system that can be used to dispatch thousands of LUA virtual machines to work in parallel. Each LUA virtual machine can receive messages that process other virtual machines and send messages to other virtual machines. Each LUA virtual machine can be viewed as a standalone process under the Skynet operating system, where you can start new processes while Skynet work, destroy processes that are no longer in use, and supervise them through the debug console. Skynet also controls the external network data input, and timer management; it converts these into consistent (inter-process-like) messages into these processes.

For example:

In a network game, you can create a LUA virtual machine (called the LUA Service) for each online user, Skynet it as an agent. When users do not interact with other users and only entertain themselves, the agent can fully meet the requirements. The agent responds to a user's network request by loading all of its data from the database into the LUA VM when the user is online. Of course you can also have a LUA service that manages multiple online users, each of which is an object within a LUA virtual machine.

You can also use a standalone service to handle a copy (or battlefield) of a network game, dealing with players and players, and players fighting AI battles together. The agent interacts with the replica service through the message without having the user client communicate directly with the replica.

We usually recommend using a gateway service that specifically listens on the port to accept new connections. After the user's identity is determined, the real business data is transferred to the specific service for processing. At the same time, the Gateway will be responsible for the agreed Protocol, the TCP connection on the data stream into a packet, and do not need business processing services to split the TCP traffic. Business-processed services do not have to face the socket handle directly, but are driven by Skynet normal internal messages. Such a gateway service, Skynet in the release of the provision of one, but it is only an optional module, you can not use it, or write a similar service yourself to better meet the needs of your project.

Skynet: Start