Editing BZFS2 prototype

Jump to: navigation, search

Warning: The database has been locked for maintenance, so you will not be able to save your edits right now. You may wish to copy and paste your text into a text file and save it for later.

The administrator who locked it offered this explanation: Server migration

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
{{IdeaDesign}}
+
#REDIRECT [[BZFS]]
''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 (Similar to the NetConnectedPeer), 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 the current BZFS have been removed to be implemented as 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.
+

Please note that all contributions to BZFlagWiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BZFlagWiki:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel | Editing help (opens in new window)

Template used on this page: