Network Architecture Concept for a Virtual World

When thousands of humans and AI agents share one world, the network quickly becomes the most temperamental part of the system. To keep it manageable, I split it into five layers. Each layer solves a single problem and knows almost nothing about the others.

The rule is simple: dependencies point downward. An upper layer knows only the contract of its neighbor below, and a lower layer knows nothing about the layers above it. On the receive path, data flows against the direction of dependencies, which is why the diagram shows calls and events with different arrows.

Level 5. World Model

This is the model of the world. It decides what each client must know, and what it doesn't need to or isn't allowed to know. Any player command arrives here as a request, not an order: the World Model holds authority over a part of the world and makes the final decision on every command, checking permissions, role, rate, and allowed values. The last word always belongs to the server, which is why the world is hard to cheat.

A client's area of interest (AOI) is computed in two stages: first a coarse selection through a spatial index, then a precise permission check and ranking within a budget. There is no brute-force "every client × every entity" pass on each tick. The simulation, physics, and ECS live behind the World Model and know nothing about network details.

Level 4. Managers

Each manager owns its own data type. Managers don't know about each other and never call levels 1 and 2. They read world data through a read-only contract implemented by the World Model. Each manager owns the schema of its messages and encodes data according to the shared Wire Schemas, which are common to the whole system.

• Event Manager carries events in both directions: a trigger fired, someone did something. Reliable events are not lost: if one is lost, it is resent with the same identifier, and duplicates are filtered out on the receiving side.
• Input Manager handles control. The client sends not coordinates but what the player pressed, and the server computes the position. Each packet carries the last K unacknowledged commands: redundancy instead of retransmitting stale data. This keeps response time low, and a client cannot forge its own position.
• Dynamic Object Manager handles dynamic objects: moving entities around the player and their "ghosts", the copies shown on the player's screen. It sends only what has changed, and what matters most goes first.
• Static Object Manager handles the immovable world: buildings and terrain. This data rarely changes, the client loads it in chunks as it moves, and each chunk has a revision number.
• Observation Manager serves those who observe rather than play: AI agents and tools. They need not individual updates but compact digests and batches of data.
• Durable Operation Manager handles critical operations such as a purchase or an item transfer. They execute exactly once, even if the connection drops in the middle of a request. The result can always be queried by the operation ID.
• Reference Data Manager handles reference data: item descriptions, parameters, and so on. There is a lot of this data, it is versioned, and it changes infrequently. Therefore it is loaded separately from the game channel, like an ordinary file download.

Level 3. Data Flow

The data flow dispatcher. Managers hand it messages wrapped in a service envelope, and it decides what goes out first, what waits, and what has become stale. The envelope holds only service fields: delivery class, priority, expiry, coalescing key, a "what the message is about" tag, and the route. The dispatcher neither knows nor parses the contents.

• Queues, priorities, and expiry are organized per data class. Data from different managers is packed into shared packets, so the client isn't flooded with small messages.
• For data where only the newest version matters, a new message replaces an older one that hasn't been sent yet.
• All queues are bounded, and overflow behavior is defined in advance: some data is replaced, some stops its source, and some is dropped first.
• Credit-based flow control. The dispatcher issues managers a byte limit for the upcoming tick in advance, along with the current maximum message size. A manager doesn't encode what wouldn't be sent anyway, and important data isn't dropped blindly. Stopping the source (backpressure) is a last resort, used only when the credit is already exhausted.
• A message always fits into a single packet. There is a guaranteed minimum (the floor), the current path limit for a specific connection, and the limit for managers (the path limit minus overhead). The architecture does not allow IP-level fragmentation: losing one fragment destroys the whole message.

Level 2. Delivery

This level has two components.

• Connection Dispatcher numbers packets, tracks whether they arrived, and reports upward what happened to what was sent. A packet acknowledgement only means that it reached the receiver's delivery layer, not that the command was applied. It also performs admission control: syntax, sizes, quotas, and rate limits, while the final permission check is done by the world.
• Session Manager keeps track of who is connected and what rights they have. A session outlives a connection: if the link drops, the client can come back, including to a different node, and resume instead of starting over. On resumption the session generation is incremented, and commands from the old generation are rejected.

Level 1. Transport

This level consists of two parts: a single contract and the pluggable technologies that implement it. Upper layers see only the contract.

Packet Transmitter

A single entry point for sending and receiving data. Upper layers ask it to "send reliably" or "send the latest" and never think about sockets, addresses, or packets. The contract is expressed in terms of messages and channels: an unreliable message, a reliable channel with priority, connection events, and channel state (bandwidth, latency, congestion level, maximum message size). This component knows nothing about the world or the game. There are no upward callbacks: incoming events accumulate in a queue, and the layer above drains them in batches at its own pace.

Transport Backends

The concrete technology that actually sends bytes over the network. Which one to use is determined by configuration, not by the code of the upper layers. This is the only place where the dependency is deliberately inverted: backends implement the Packet Transmitter contract themselves, and that is exactly what makes the transport replaceable.

• QUIC (current). A modern protocol on top of UDP. It provides encryption, independent streams, and unreliable messages, so a lost packet doesn't stall everything else.
• DPDK (planned). Receiving and sending packets directly from the network card, bypassing the operating system kernel. This is the path to maximum speed, but encryption and protection would have to be built in-house.
• Mock (for tests). A network simulation: loss, delay, packet reordering. It lets you verify how the system behaves on a poor connection without leaving the test environment.

A backend has two sets of settings: one for clients and one for internal connections between nodes. They differ only in parameters, not in code: externally, server verification and client address changes without reconnecting are needed; internally, mutual certificate verification on every connection. The backend reports its capabilities upward, so a fallback transport without reliable delivery can be plugged in with no changes to the rest of the system.

Where It Runs: Gateway and Simulator

Levels 1-3 run on the Gateway, the node for external connections, which does not own world state. Levels 4-5 run on the Simulator, the process of authoritative simulation. An internal channel connects them: the same QUIC, the same contract, just the Internal profile. To managers it looks as if the dispatcher sits right next to them, so credits, delivery reports, and data ranking keep working.

Why it is done this way:

• A connection spike or an attack hits the Gateway, not the world.
• Networking and simulation scale independently.
• A client holds a single connection even when it sees several parts of the world.
• When a part of the world moves to another server, the client doesn't reconnect: the node simply changes the route.

Who owns which part of the world is decided by the Directory, a separate fault-tolerant service. It grants ownership for a limited time and tracks ownership changes, but takes no part in tick processing: a client command doesn't wait for its response.

What This Gives Us

• Replaceability. The transport can be swapped without rewriting managers or world logic.
• Testability. Every boundary between layers can be substituted: time in tests is advanced manually, and the network is simulated with loss, delay, and reordering. A poor network is reproduced by script.
• One client for everyone. A human and an AI agent connect the same way, through the same code. Only permissions and limits differ, and they are gathered in one place: the session profile.
• Honest channel accounting. Instead of "send it and see what happens", there is a limit known in advance, so work isn't wasted and important data doesn't drown along with the unimportant.
• The server is always right. The client asks, the server decides.
• Physics doesn't wait for the network. The simulation runs at its own pace, and the network reads the ready state at its own. Along the entire path of world state, from physics to the screen, there are no floating-point numbers, only fixed-point arithmetic, so identical input produces an identical result on any platform.