Dev:Forest - an overlay network for distributed applications

This page describes the high level architecture for the scalable network game system, focusing on the major system components, their interfaces and functionality.

We envision several different implementations of the architecture, for different deployment contexts. These contexts include the Open Network Lab, the Supercharged PlanetLab Platform, Vini and Amazon EC2. Some of these (perhaps all) will be incomplete, but we want to maintain a reasonable degree of consistency across the platforms to minimize the amount of redundant work that will be required. Since the EC2 environment has the greatest potential to serve as a realistic development platform, we will try to keep it as our primary focus. The other environments can be seen more as prototypes, for ideas that we seek to ultimately realize in EC2.

Major Components

The network game system is distributed across multiple sites. Each site has a known geographic location and includes a multiplicity of processing resources of various types. In particular, each site has one or more servers and routers. Servers connect to remote users or clients over the Internet (most often, using UDP tunnels) and communicate with other servers through the routers. Sites are connected by virtual links which have an associated provisioned bandwidth. Multiple routers at a site may share the use of a virtual link going to another site, but must coordinate their data transmissions so as not to exceed its capacity. In addition, each site has a site controller which manages the site and configures the various other components as needed. These ideas are illustrated in the figure below.

Add right figure later

System Data

Decide on what data we want to maintain at a system level and how it should be organized (at least logically). One possibility is to include a DHT that would have one node at each site in the network and that would store various kinds of global system data. Use one-hop routing, that is expect every site to know about all other sites.

Common Interface Elements

The various system components communicate by sending packets of various types. Here we describe the fields that are common to all packets and the basic packet format. Specific protocols used by the various components define additional fields. The description of these fields and formats is given in the specific sections dealing with the components that define the protocols.

The common fields are listed below.

• Version (4 bits). This field defines the version of the protocol suite. The current version is 1.
• Packet Type (8 bits). This field defines the type of the particular packet. The currently defined types are listed below.
  • 20 Subscription Request
  • 21 State Update
• Type-Specific Field (20 bits). This interpretation of this field is determined by the packet type. It is typically used to specify type-specific parameters.
• Source Address (48 bits). This specifies the address of the component that sent the packet.
• Destination Address (48 bits). This specifies the address of the component to which the packet is being sent.
• Session Identifier (32 bits). This field is an optional field. It is required for all packet types that are associated with a particular game session.

The basic packet format is shown below. For those packet types that require additional fields, the space for these fields follows the fields shown above (with the understanding that the session id only appears in formats that are specific to a particular session).

Network State Management

Include neighbor discovery, topology maintenance, etc.

Multicast Tree Routing

foo