The Arena Project had the ability to network the game as part of the original concept. But going from concept to design to code is a rather bumpy road. This article is intended as an overview of how the Arena networking will work.
Keeping a large number of computers talking reliably to each other over a network is a daunting task. There are several network topologies out there for doing this, though. A network topology is a description of how the group of computers are logically organized. A STAR topology has a central node and a bunch of "arms" protruding from that node to connect the outlying nodes in the shape of a star. A RING has the computer network formed in a circular shape. We chose the RING setup for our project.
The RING topology has some problems. To communicate between computers in the ring, the information packet has to be sent around the ring until it reaches its destination. A reply must do the same. This can cause large delays when there are a lot of computers in the ring. And for a real-time game, this delay could slow the game to an unusable point.
We decided on a different approach to using the ring. A token is sent around the ring from computer to computer. This token is the controlling packet of the game. When a game has the token, it can send out its update packets to all the other computers in the ring. These packets are sent directly to the individual destinations, and not around the ring. When the updates are all sent out, the token is released to the next game in the ring.
The protocol that is being used is connectionless and does not guarantee delivery. So, packets can be lost. This problem can be serious if the token packet gets lost. But the game developers were able to find a solution to this problem.
Update packets are important to keeping the game flowing, but they aren't missed if a couple get lost. At 20 packets per second, a few missing ones will not ruin the game. The token packet, however, requires further thought.
When the token is passed on to the next game, a timer is started. If the timer expires before an update packet is received, then it is assumed the token was lost and a new one is sent out. This works quite well when update packets are not lost.
If the update packet that is used to acknowledge the token is lost, the game which sent out the update packets will receive a new token. The token has already been sent on to the next game, so now there are two tokens in the ring. A couple of things are done to remove the extra token.
First, the retransmitted token has a counter on it which tells whether or not the token is an original or a retransmitted token. If it's a retrans, and the game that sent on the other token knows the other token has arrived safely, the retrans token is acknowledged, but is not sent on. Also, if a game is retransmitting the token, but it receives an update packet from anyone in the ring, it assumes the acknowledgement was lost and then stops retransmitting the token.
This description is necessarily sanitized since including all the information would be longer and more boring than this. If however, this has piqued your interest and you would like to know how to get involved in the Arena Project, or networking in general, send mail to c-remes@uiuc.edu for joining the Arena Project, or mail signet@uiuc.edu to find out how to get involved in the Special Interest Group on Networking.