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

Editing Network Protocol

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: Archived wiki

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 18: Line 18:
  
 
= Client/Client Communication =
 
= Client/Client Communication =
BZFlag clients send certain information to other clients during a game. This information includes: status, position, orientation, and linear and angular velocity. This state can change quickly and getting it late is no better than not getting it at all. So client-to-client packets are sent using UDP, a datagram protocol.
+
BZFlag clients send certain information to other clients during a game. This information includes: status, position, orientation, and linear and angular velocity. This state can change quickly and getting it late is no better than not getting it at all. So client to client packets are sent using UDP, a datagram protocol.
 
UDP is unreliable, meaning that packets are not guaranteed to be delivered. It's also connectionless, meaning we don't even know if anybody is listening for the message. However, it's also fast because it's so simple. UDP suits our needs because: we need fast delivery; we don't care if a message is lost because another will arrive shortly afterwards; and we don't care if the receiver isn't listening.
 
UDP is unreliable, meaning that packets are not guaranteed to be delivered. It's also connectionless, meaning we don't even know if anybody is listening for the message. However, it's also fast because it's so simple. UDP suits our needs because: we need fast delivery; we don't care if a message is lost because another will arrive shortly afterwards; and we don't care if the receiver isn't listening.
 
BZFlag clients need to send their information to all the other clients. There are several ways to do this. First, each client can send each message to all the other clients. If there are N clients then each message is sent N-1 times. Traffic grows as the square of clients. This is slow and wasteful.
 
BZFlag clients need to send their information to all the other clients. There are several ways to do this. First, each client can send each message to all the other clients. If there are N clients then each message is sent N-1 times. Traffic grows as the square of clients. This is slow and wasteful.
Line 322: Line 322:
 
The call sign is the player's `handle' during the game;  the call sign is used
 
The call sign is the player's `handle' during the game;  the call sign is used
 
to identify the player.  No attempt is made by the server to prevent the
 
to identify the player.  No attempt is made by the server to prevent the
duplication of call signs during a game.  The motto can be anything,
+
duplication of call signs during a game.  The email address can be anything,
including the email address for human players (e.g. username@hostname).
+
but should be the email address for human players (e.g. username@hostname).
BZFlag players can choose `anonymous' instead of their motto.  The call
+
BZFlag players can choose `anonymous' instead of their email address.  The call
 
sign and email address should be NUL terminated ASCII strings, padded with
 
sign and email address should be NUL terminated ASCII strings, padded with
 
NUL's to the required length.  `Length' is 12 + CallSignLen + EmailLen.
 
NUL's to the required length.  `Length' is 12 + CallSignLen + EmailLen.
Line 359: Line 359:
  
  
== Leave game ==
+
== leave game ==
 
Once entered, a player can leave the game at any time.  This should be done by sending
 
Once entered, a player can leave the game at any time.  This should be done by sending
the following message, then closing the connection:
+
the following message then closing the connection:
  
 
   -->    +----+----+----+----+
 
   -->    +----+----+----+----+
Line 371: Line 371:
  
  
== During a game ==
+
== during a game ==
 
There are several types of messages that are delivered at any time after a player
 
There are several types of messages that are delivered at any time after a player
 
enters a game.  Clients must be prepared to handle them in any order.
 
enters a game.  Clients must be prepared to handle them in any order.

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: