Networking: Status Updates, State Changes

Networking: Status Updates, State Changes

Home

Simulations designed to run on a single machine are often just while-loops that repeatedly poll for input, advance the position of objects, and check for collisions. In a networked simulation, on the other hand, each host must cope with objects that move outside its control and wait for resource arbitration from the simulation authority. Each of these requires the host exchange data over the network.

Networking is nondeterministic, which means packets don't always arrive immediately, correctly, or in the order they were sent -- sometimes they don't arrive at all. Compensating for these problems often means resending packets one or more times. An application must weigh how important it is that the message arrive quickly, reliably, and in order -- since it probably won't get all three.

Once the application has decided the importance of a given message, it is then sent to one or more hosts in the session. As discussed earlier, there are several ways to place data on the wire: datagram, broadcast, transaction, or stream. That's alot of decision-making to perform for each message.

To keep things simple, I recommend condensing these options into two basic types of network communication:

Status update: An unreliable but fast datagram describing the current status of one or more objects.
State change: A reliable and atomic transaction that negotiates a specific change in the simulation.

The status update is simply a datagram (or broadcast) stamped with an increasing unique ID. It describes the current state of the simulation, an object, or just an attribute. Such packets are sent frequently, but not acknowledged or resent if lost, because another will arrive shortly. If datagrams arrive out of order, only the newest is applied, and the "stale" updates are silently dropped.

In contrast, state changes are negotiated with a specific host using reliable networking. These operations must be processed sequentially and atomically, ensuring that the first host to make a request is the only one who succeeds and that complex requests are not interrupted.

While a network stream may be suitable for turn-based games, a realtime shooter should use datagram-based transactions because they are often faster. In either case, the request is sent to the authority, who determines if it's valid or not: can this player capture that object, or has the object already been captured? The authority sends the appropriate response, and propogates the change to the rest of the hosts.

Let's apply this model to a networked space shooter. Every 200ms, the host sends an update packet containing the current position and velocity of the player's ship. Between updates (or if one is lost), other hosts can predict the path of the ship and animate it smoothly. When a signficant event occurs, like crossing the path of a bonus cylinder or an asteroid, the host cannot assume it knows what happened. It must confirm the capture or collision by sending a state change request to the authority, and wait for the response indicating success or failure.

Of course, the amount of data in a status update or state change depends on the nature and size of the simulation. In a game of chess, the entire state of the board can be placed into a single packet after each turn. On the other hand, a massive space game might only send continuous updates about the closest ships, and only the occasional, signficant message about remote players and planets.

A good rule of thumb is to use status updates for messages that make the display smooth and responsive, and state changes to keep the simulation accurate and consistent by obeying well-defined rules. Unfortunately, displaying periodic status updates as a smooth path may lead to inconsistencies when the authority does not approve an expected state change. This and other problems are discussed in depth in various network design articles.