The dptab module

Last update: 16 Aug 1997

History

The Activenet dp library has to propagate four different tables of data: sessions, players, variables, and groups. The code to propagate these tables was originally written over more than a year, and each table is propagated differently. Worse yet, the player table doesn't propagate very well; it has trouble with more than 16 players in a room!

Goal

The goal of dptab is to replace the four different table propagation methods in dp with one well-understood, high-performance table propagation module. It should be able to handle a hundred players in a room without any trouble.

It should also be easily adaptable for use by games that need to propagate game-specific data between the game clients and the game server.

dptab will sit between dpio (the reliable transport module) and dp2 (the big lobbies version of the Activenet API). It provides building blocks for reliably mirroring tables (e.g. session tables, player tables, or game-specific data tables) between client and server, server and master server, or between peers in a game.

See src/doc/arch.htm for more overview of how the new dp2 works.

Unimplemented Features

Code

Regression test

The regression test currently only checks whether a table entry is properly propagated around a ring of hosts which agree to subscribe to a table from their left neighbor and publish the same table to their right neighbor. It also prints out propagation time.

Prototype users of the module

dptab and dp2 are now linked in to the dp2, dp2d, anet2, and anet2d libraries (static, static debugging, dynamic, and dynamic debugging, respectively; released applications should be linked to anet2.) The game server will eventually be rewritten to use dptab. Here are trivial protoypes of client and server demonstrating a three-tiered system (master server, slave servers, and clients) for distributing session info:
Back to unit test index
Up to Activenet Source Packing List
Dan Kegel