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.
The DIGS Architecture
The Distributed Internet Game System involves the interaction of the following entities:
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.
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.
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.
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)
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.