Terminalogy Overview

In this section, we’ll introduce key concepts in NetCluster.

Server Definition

Belowing is a example of .

The system involves services managed by both Clustech and your own infrastructure.

Clustech-Hosted Services

• License Server: During dedicated server initialization, the server provides account information for verification by the License Server. Once verified, it can establish connections with Domain Servers.

• Domain Server: All game servers connect to a Domain Server, which is identified by an account. Each game utilizes one Domain Server. The Domain Server manages the interconnection logic between servers.

Game Servers

These servers are operated within your infrastructure.

Each level in your game operates independently on multiple servers, coordinated by Level Servers and Visibility Servers to form a cohesive world. Each server has a unique ID within a Domain Server.

• Level Server: Each level is managed by one Level Server. It handles the level's core logic, such as determining player spawn points, broadcasting elapsed level time, updating weather conditions, and more.
• Visibility Server: A level can have multiple Visibility Servers, each managing a specific region. They track the positions of inter-server actors and update their visibility across servers.
• Load Server: Multiple Load Servers can be assigned to a level. These servers offload specific computations (e.g., AI/behavior tree logic) or host players and NPCs. If a level contains static actors, one Load Server with the HostStaticActors flag will host them. This server treats static actors as local, while other servers treat them as proxy actors.

Proxy Actor

When an actor is replicated from its hosting Server A to another Server B, the actor created on Server B is called a proxy actor. Similar to actors replicated to clients, this proxy actor can make server RPC calls to Server A, receive property updates from Server A, and replicate properties to all clients observing it.

Replication types

When NetCluster replicates an actor to other servers, several replication types can be specified using the actor's Tags field:

• NetClusterActor: Actors with this tag can be synchronized to other servers under the management of a Visibility Server.

• NetClusterActor.ServerOnly: These actors synchronize only between servers and are not synchronized to clients.

• NetClusterActor.ControlConnection: These actors automatically synchronize between Control Connections without requiring Visibility Server management.

• NetClusterActor.AlwaysRelevant: These actors automatically synchronize to all servers connected to the same Domain Server.

• NetClusterActor.Manual: These actors do not synchronize by default and require manual synchronization through the OnActorReplicating delegate.

These tags allow you to control how an actor is replicated between servers.

Inter-Server RPC Invocation

By extending Unreal Engine’s networking, NetCluster supports Inter-Server RPC calls, which behave as follows:

Actor Ownership	Not Replicated	NetMutlicast	Server	Client
Client-owned actor	Runs on server	Runs on server and all observed servers and clients	Runs on server	Runs on actor's owning client
Server-owned actor	Runs on server	Runs on server and all observed servers and clients	Runs on server	Runs on server
Unowned actor	Runs on server	Runs on server and all observed servers and clients	Runs on server	Runs on server
Interserver-owned actor	Runs on invoking server	Runs on invoking server	Runs on server where this actor is replicated from	Runs on invoking server

caution

The behavior of the client RPC remains unchanged.

Additionally, an Inter-Server Only RPC has been implemented, restricting its invocation to servers. To define this type of RPC, prefix the function name with InterServerOnly_.

Region ID

Each server instance is assigned a unique Region ID. This ID is used to generate distinct NetworkGUIDs for inter-server actors, ensuring proper identification across the network.

Unified GUID Actor

In certain cases, based on customized gameplay logic, we may have local actors that are independently spawned by each server but should be treated as the same entity across all servers. For instance, each load server might spawn its own GameState actor, and during player migration, it’s crucial that the GameState retains the same GUID across servers. This way, there's no need to update the actor channel or make changes on the client side.

These actors, referred to as Unified GUID Actors, are marked for having a consistent GUID across servers. They should have a stable name, though they do not need to be static actors. The same GUID will be assigned to these actors to ensure consistency across the network.