Networking: Session Topology and Simulation Authority

Networking: Session Topology and Simulation Authority

Home

A common mistake when designing a networked virtual world is to lump the networking and gameplay logic together. When someone suggests that their software is "client-server", you should wonder "client-server what?" Confusion is natural because many networking terms have become synonymous with the design strategies they use. Let's start untangling them with a few definitions:

Session: Network layer that connects hosts to each oether
Simulation: Virtual world where users and objects interact.

It's not enough that a bunch of computers want to communicate, there needs to be some kind of structure. There are two distinct parts to the design, the networking logic in the session and the game logic in the simulation.

A session is a virtual connection that links these hosts and determines how they communicate. One computer starts the session, then other hosts join and leave over time. When the last computer leaves the session, the session ends and the network layer is torn down.

While in a session, a host usually exchanges data with the others. It might seem simple enough to simply send messages directly to every member, but in practice that method puts an extremely heavy load on the physical link -- and can degrade performance for everyone on the wire.

This design may work for small games, but simply does not scale up very well. We must actually design a strategy for exchanging data that balances performance and simplicity. The networking model, or topology, will dictate how a given message will be sent or relayed over the network so that it reaches the intended target.

Consider the case where 4 people are playing a game which sends the current keyboard state 30 times a second to every other player. Because it is broadcasting packets, each host sends 90 updates a second -- putting 360 packets on the wire every second. That many packets, no matter how small, will saturate an Ethernet and overload any routers in the way. There must be a better design.

The session is just a communications layer, the real work is performed by the simulation, which maintains the virtual world of objects, actions, and interactions. A simulation running on a single computer can be very simple, but sharing one among several networked hosts is not.

The problem isn't just distributing the work; programmers frequently use threads and synchronization primitives on the same host. The real issue is coping with the latency and poor reliability of network messages. The user expects fine control and instantaneous response, but coordinating changes to the simulation simply take time.

In a real-time "capture the flag" game, several players compete to find and capture resources at the same time. When two players race toward the same flag, the software must ensure that only one of them actually capture it. If we allowed each host to decide which player actually reached the target first, there is a small window where the hosts may come to different conclusions.

To solve this problem we design the simulation so that a specific host, called an authority, makes the decision and all others defer to him. This authority is responsible for managing certain resources: tracking their state (location, ownership) and arbitrating between competing state changes (move, capture, create, destroy, collide).

In general, a simple transaction with the authority will suffice to move an object or capture a flag. In simulations with more than one authority, a host may need to interact with more than one authority to modify multiple objects -- either locking the objects temporarily or just posting the request and letting the authorities sort it out.

For example, a distributed authority model gives each host a portion of the world to administrate. In contrast, a client/server simulation has only one authority, which rules absolutely over the other hosts. Finally, token ring passes authority from host to host, so that each has an opportunity to make changes in turn.

Finally, it's important to note that you can actually build an authority model on a network session with a different kind of topology (eg, a peer-to-peer network session that defers to a single simulation authority). The key is choosing a network model that is relatively fast and a simulation that is relatively simple for your specific needs.