This wiki is archived and useful information is being migrated to the main bzflag.org website

BZFS2 prototype

From BZFlagWiki
Revision as of 17:21, 23 April 2007 by Joevano (Talk | contribs)

Jump to: navigation, search
Picture Frame.png This page contains the design document for an enhancement or feature. It is a work of collaborative development, and may not represent the final design. If you are not part of the development or design group, please post comments and suggestions on the talk page and not in the middle of the design.

This is an overview of the BZFS2 prototype released 4/22/2007. This document describes a proof of concept rewrite of BZFS, it does not represent the current state of any release or version of the main project code.

The New Paradigms

Channel - Channels are for transmitting various data at different priorities and with different rights. Players 'tune in' and 'tune out' of channels depending on the state they are in and the rights that are conferred to them.

The channel model has a super channel which every client is connected to immediately upon connecting to the server. Then, there are one or more game channels where the game is actually played, and any game-related data is sent within this channel. There is at least one admin channel which authenticated users are tuned in to for admin-specific data.

Group - The new security model is a layered grouping model. All entities (players, channels, other groups), are within a group, and rights for any entity depend on the rights of a group and all it's ancestor groups.

Task - Tasks can be running tasks or timed tasks, and can be registered either from the server, or from plug-ins.

Networking

Networking is now separate from player data. The base class is Client, with children LocalClient and RemoteClient (RelayClient is planned). The Client abstracts the network implementation away from the server. RemoteClient uses basic sockets, ENetRemoteClient will use ENet, SDLRemoteClient will use SDL-Net.

Message are queued and directed by the Channel. Broadcast messages are broadcast to clients tuned to the channel. Only messages broadcast on the super channel are guaranteed to reach every connected client.

Relay Servers - One method of handling latency over long distances is a relay server, which clients local to the this relay connect to it, and the relay connects to the main server. Messages both ways are batched and fewer packets are sent between a relay and the main than between the main and a direct client player.

Game State

This server engine is designed to allow game state to be kept by the server in an abstracted form. How this will be implemented is yet to be decided.

Plug-ins

Several functions that are part of BZFS currently have been removed to be plug-ins instead. This includes admin functions and voting. This means the server would be packaged with several default plug-ins that add core functionality.

API

Additional API is required to support the admin function plugin, and allow plug-ins to register tasks and commands. By and large, the API does remain the same.

See also