GDS – Game Discovery Service
Overview
The GDS is a replicated database system that is used to store and query information about currently active GameNet channels and servers. It is replicated in order to provide increased availability since every client or server using the GameNet API must make use of the GDS to either query for an existing GameNet channel or attempt to create a new one.
In order to provide this functionality, the GDS provides a GDS client class to the RGS subsystem of the GameNet API. The RGS system takes care of communicating with the GDS on behalf of the application. As such, and application is provided with the following interfaces which affect the GDS: Register() and Discover() and Unregister() which is called implicitly by the RGS system on shutdown.
Operation
A peer-to-peer client or the server of a client-server application uses the GameNet Register() call in order to register itself with the GDS and receive a unique GameNet URL. A client that wishes to join an existing game can issue a Discover() command to GameNet which queries the GDS and returns a list of all available games of that type in the form of GameInfo objects.
The structure of a GameInfo object is to set up a hierarchical naming space. A game application is named by its manufacturer code, game code, and version number. The manufacturer code is unique to a game designer, and that designer is responsible for creating unique game codes for all of his or her games. This information is provided by an application using GameNet so that registration or discovery can be done.
Implementation
The GDS System uses JavaGroups running over Ensemble in order to take advantage of group membership and the total ordering of messages. It creates an ensemble channel for the Registration Ring that is used exclusively by the GDS servers. Once a server is started up and its database is in a consistent state, the GDS server then joins another ensemble channel called the Discovery Ring.
The Replication Ring is used by the GDS servers to do database replication. The GDS servers mainly handle three types of operations, query, addition, and deletion. The query operations make no changes to the database, so queries are performed only on the outer Discovery Ring. An addition operation caused by the registration of a server or peer-to-peer client is actually sent out only on the inner Replication Ring by the GDS server used for registering. Deletion operations, due to an un-registration, are sent to the Replication Ring only in the same fashion. Since JavaGroups/Ensemble provides total ordering on messages, this provides consistent updating of all the GDS servers.
The Discovery Ring is used by active GDS servers and the RGS system making use of the "gds.Client" interface. It is used for query, registration, and un-registration requests. The active GDS servers send out an announcement every D seconds. When the RGS client joins the Discovery Ring, it waits until it hears an announcement message. It then sends its request to the GDS server that sent out the announcement, which processes the request. In this manner, a very simple load-balancing scheme is provided. Since the clients join asynchronously, the GDS server, every GDS server has roughly an equal chance to be used by the client.
When a GDS server starts up, it initially only joins the inner replication channel. It then contacts an existing GDS server and requests a state transfer. The existing server then spawns a new thread that packages up an instantaneous view of the database. The thread then slowly trickles the database to the joining GDS server while the existing server also continues to handle clients. During this time, the new GDS server performs addition operations but queues up deletion messages from the Replication Ring. When the database transfer is complete, the queued up deletion messages are processed, bringing the new GDS server into a state consistent with all the others. Once this process is complete, the new GDS server joins the Discovery Ring and advertises its services.