| 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.
| + | |
