DIGS - Distributed Internet Gaming System

The goal of DIGS is to provide networking services to internet games and game servers. DIGS provides the ability to organize a network of servers in a roughly heirarchical structure. A network of servers can provide any set of services.

Features:

• Transparent access - A client of DIGS does not have to worry about the details of finding an appropriate server.
• Load balancing - Load information is communicated between the hubs and connections are routed to the lowest load service provider.
• Arbitrary point of entry - A user can connect to any hub in the network but the connection may be rerouted for load balancing.
• Automatic incorporation of new hubs and service providers - A new node is added to the system by simply specifiying the parent hub. No existing nodes must be reconfigured.
• Automatic and prompt removal of off-line nodes.
• Heterogeneous service support - Hubs keep track of an arbitrary number of services of different types.

Future Extensions:

• Ping minimization support - The automatic discovery of an appropriate low-ping server.
• Distributed information support - Currently the servers each provide the service independently, unless they coordinate themselves. Games like Ronin may benefit from the ability to distribute information among the servers in a safe and reliable way.
• Support for cyclic and/or arbitrarily constructed networks.

The DIGS Architecture

The Distributed Internet Game System involves the interaction of the following entities:

• Service Hubs - linked together in a network and keep track of available service providers.
• Service Providers - listen on a TCP port and report status to a service hub.
• Service Clients - communicate with the service hubs to find appropriate service providers.

Service Hubs

The service hubs are the core of DIGS. Each service hub keeps track of any number of parent hubs, child hubs, and service providers. A hub's parent hubs must be specified by the hub administrator. Thereafter, each hub reports its status to all of it's parent hubs. Thus, the most natural topology of a DIGS network is that of a tree. Each status report generated by a hub includes the names of all of the services that its child hubs and service providers support, and the minimum load for each service. The DIGS suite will include the standard service hub program, which need not be augmented.

Service Providers

The service providers can be arbitrary processes that listen on a TCP port and await connections, exactly like traditional TCP servers. A service provider is responsible to send status updates to any parent hubs that it wishes to be affiliated with. These status updates are of the same format as those used by the service hubs, but will likely only involve one service name and load. The DIGS suite will include the class DIGSServiceProvider (in C++ and Java) which will be an abstract base class to assist in building service providers that conform to these specifications.

Service Clients

The service clients are users of the DIGS network who make queries of the hubs in order to find connections to named services. The DIGS suite will include the class DIGSClient (in C++ and Java) which will allow arbitrary programs to interface with a DIGS network. The client programs will request services by name from a DIGSClient object and be returned a Socket descriptor.

Operation

When a program wants to access a service using a DIGS network, an instance of the DIGSClient object is created and given the address of one DIGS hub. The program asks the DIGSClient object for a socket to a particular named service. In response to the request the DIGSClient connects to the known hub and sends a message requesting the service. Using information about child hubs and service providers, the hub informs the DIGSClient of the address of another hub or a service provider. The process is repeated until a service provider is returned to the DIGSClient, which passes it on to the requesting program.

Ronin Services (in order of decreasing priority)

• Lobby - coordinates the initiation of battles and other metagame issues
• Player Information Liaison - records changes in character and player information during a battle
• Battle Server - runs a battle simulation, receiving commands and sending events
• Player Validation Officer - validates the player's password and character information
• Card Manager - allows activation and deactivation of cards
• Reroute/Multicast Messenger- resends messages to one or more destinations
• Software Upgrade Genie - negotiates software upgrades

Use of Ronin Services

The Ronin client software uses these services behind the scenes to produce a seamless and unified game environment. During a Ronin session, the client software will first use the Player Validation Officer to log into Ronin. During this phase the player will be given a security signature which will be used to secure all transactions made during the session. Next, the client software will use the Lobby Service to initiate a battle. For a battle, the Battle Server and Reroute/Multicast Messanger services will be requested by the client software as needed.