This wiki is archived and useful information is being migrated to the main bzflag.org website
Editing Network Protocol
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 | + | 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 | + | duplication of call signs during a game. The email address can be anything, |
− | + | but should be the email address for human players (e.g. username@hostname). | |
− | BZFlag players can choose `anonymous' instead of their | + | 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 == |
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 | + | the following message then closing the connection: |
--> +----+----+----+----+ | --> +----+----+----+----+ | ||
Line 371: | Line 371: | ||
− | == | + | == 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. |