Key Points of game server development

Go to: http://jiangwen2011.blog.163.com/blog/static/194801340201181104532377/

Abstract: As the basic outline of game server development, this article is a summary of game practice development. The first part is the professional foundation, which is used to guide recruitment and practice assessment. The second part is the introduction to the game server development. The third part is the server architecture, which introduces some basic principles in the architecture design. Hope to help you with a professional basic 1.1 Network

1.1.1 understanding of TCP/IP protocol

Network Transmission Model

Sliding Window Technology

Three-way handshake for establishing a connection and four-way handshake for disconnecting

Various statuses during connection establishment and disconnection

Transmission Efficiency of TCP/IP protocol

Thoughts

1) Explain the basic principles of DoS attacks and drdos attacks.

2) A 50%-byte data packet is reduced to 50 bytes, and its transmission efficiency is improved

3) how to explain the timewait status?

1.1.2 master common Network Communication Models

Select

Epoll, difference between edge triggering and platform starting point and Application

Difference between select and epoll and Its Application

1.2 Storage

Computer System Storage System

Memory Structure during program running

Computer file system, page table structure

Implementation Principles, application scenarios, and differences between a memory pool and an object pool

Use of relational database MySQL

Shared Memory

1.3 programs

Have a deep understanding of the C/C ++ Language

Deep understanding of interfaces, encapsulation and polymorphism, and practical experience

Deep understanding of common data structures: arrays, linked lists, binary trees, and hash tables

Familiar with common algorithms and related complexity: Bubble sorting and quick sorting

2. Getting started with Game Development

2.1 defense Programming

Do not trust the client data. Check the data. As a server, you cannot determine who your client is, and you cannot assume that it is in good faith. Please protect yourself. (This is the basic criterion for determining whether a server programmer is getting started)

The legality judgment must be performed on the pass-through parameters and return values of the function. The internal subsystems and function modules should not be too trusted, requiring low coupling and high cohesion.

Plug-in-type module design. The robustness of module functions should be built-in, and the coupling between modules should be minimized.

2.2 Design Model

It is natural. Do not be superstitious, be obsessed with design patterns, or be rigid.

Simplified, simplified, and simplified to solve problems in the simplest way

With dabao's one sentence: the design of this day is amazing.

2.3 Network Model

Self-built wheels: Must select, epoll, and epoll be more efficient than select?

Open-source framework: libevent, libev, ace

2.4 data persistence

Custom file storage, such as fantasy westward journey

Relational Database: MySQL

NO-SQL Database: MongoDB

Factors should be taken into account when selecting a storage system: stability, performance, and scalability.

2.5 Memory Management

Use the memory pool and Object pool to prohibit dynamic memory allocation during running

Strictly check input and output pointer parameters.

Write memory protection. Use functions with memory protection (strncpy, memcpy, snprintf, vsnprintf, and so on) to prevent array subscript out of bounds

Prevent READ memory overflow and ensure that the string ends with '\ 0'

2.6 Log System

Simple and efficient. A large number of log operations should not affect program performance.

Stable. If the server crashes, logs are not lost.

Complete, logs must be recorded for key player operations. Ideally, the log can be used to rebuild player data at any time point.

Switch. You need to add level switch control for log development.

2.7 communication protocol

Using PDL (protocol design language), such as protobuf, you can generate front-end code at the same time to reduce the joint debugging cost of front-end protocol and improve scalability.

JSON, text protocol, simple, self-explanatory, no joint debugging cost, good scalability, and convenient package filtering and log writing

Custom binary protocol, simplified, efficient transmission performance, full control, almost no scalability

2.8 globally unique key (guid)

Prepare for the combination

Easy tracking of items and equipment flow

Each role, equipment, and item should have a globally unique key.

2.9 multithreading and Synchronization

Synchronous processing of Message Queues

2.10 state machine

Strengthen the role status

Check and verify the frontend status

2.11 data packet operations

Merge data packets within the same frame to reduce the number of I/O operations

A single copy is used to store only one copy of a package, reducing the number of memory copies.

Reduces unnecessary data packets in the intermediate process during AOI Synchronization

2.12 Status Monitoring

Monitor internal server status at any time

Memory Pool, Object pool usage

Frame Processing Time

Network I/O

Packet Processing Performance

Number of times various business logic are processed

2.13 packet Frequency Control

Control the packet Frequency Based on each protocol of each player, paralyzing the Variable Speed Gear

2.14 Switch Control

Each module has a switch that can immediately turn off any faulty functional module.

2.15 anti-plug-in and anti-cheating

Packet frequency control can eliminate variable speed gears

Package ID auto-increment check, which can eliminate WPE

Packet verification code can eliminate packet interception and tampering

Image Recognition? You can kill 99% non-human operations.

The magic is full

2.16 hot update

Hot update of core configuration logic, such as Anti-addiction system, packet frequency control, and switch control

Code is basically hot-updated, such as Erlang and Lua.

2.17 anti-click farming

Output logs of key system resources (such as Yuanbao, energy value, item, and equipment)

Resource output and consumption are measured based on two or more independent conditions.

Strictly check the prerequisites for each operation

Verify parameter Validity

2.18 crash prevention

The underlying system has nothing to do with the specific business logic. A large number of robot stress tests can be used to expose various bugs to ensure stability.

Script is recommended for business logic

Systematic assurance that the game will not crash

2.19 Performance Optimization

Asynchronous Io operations

Io operations merge slow writes (transactional dB operations, package merge, and file log slow writes)

Cache Mechanism

Reduce race conditions (Avoid frequent access and switch, minimize lock usage, and multithreading is not necessarily caused by a single thread) multithreading is not necessarily faster than a single thread

Reduce memory Replication

Test by yourself and use data to speak. Don't guess.

2.20 Operation Support

Interface Support: Real-Time query, control commands, data monitoring, Customer Service Processing, etc.

Provides HTTP interfaces for implementation

2.21 disaster recovery and fault plan

Omitted

Three-server architecture

3.1 what is a good architecture?

Meet Business Requirements

Rapid implementation of planning requirements and response to demand changes

System-level stability assurance

Simplified development. Complexity is controlled at the bottom of the architecture to reduce technical requirements for developers. logical development does not depend on the strong technical strength of developers and improves development efficiency.

Comprehensive Operation Support System

3.2 thoughts on architecture practices

Simple. The architecture that meets your needs is a good one.

Design Performance, capture the important 20%, there is no need to refresh the performance from the program code

Hot update is required

People will inevitably make mistakes and try to use a set of mechanisms to ensure logical robustness.