$treeview $search $mathjax
Stratagus  2.2.7
$projectbrief
$projectbrief
$searchbox
-->
         _________ __                 __
        /   _____//  |_____________ _/  |______     ____  __ __  ______
        \_____  \\   __\_  __ \__  \\   __\__  \   / ___\|  |  \/  ___/
        /        \|  |  |  | \// __ \|  |  / __ \_/ /_/  >  |  /\___ \
       /_______  /|__|  |__|  (____  /__| (____  /\___  /|____//____  >
               \/                  \/          \//_____/            \/
    ______________________                           ______________________
                          T H E   W A R   B E G I N S
                   Stratagus - A free fantasy real time strategy game engine

Module - Network

How does it work.

Stratagus uses an UDP peer to peer protocol (p2p). The default port is 6660.

UDP vs. TCP

UDP is a connectionless protocol. This means it does not perform retransmission of data and therefore provides very few error recovery services. UDP instead offers a direct way to send and receive datagrams (packets) over the network; it is used primarily for broadcasting messages.

TCP, on the other hand, provides a connection-based, reliable data stream. TCP guarantees delivery of data and also guarantees that packets will be delivered in the same order in which they were sent.

TCP is a simple and effective way of transmitting data. For making sure that a client and server can talk to each other it is very good. However, it carries with it a lot of overhead and extra network lag.

UDP needs less overhead and has a smaller lag. Which is very important for real time games. The disadvantages includes:

I have choosen UDP. Additional support for the TCP protocol is welcome.

server/client vs. peer to peer

The player input is send to the server. The server collects the input of all players and than send the commands to all clients.

The player input is direct send to all others clients in game.

p2p has the advantage of a smaller lag, but needs a higher bandwidth by the clients.

I have choosen p2p. Additional support for a server to client protocol is welcome.

bandwidth

I wanted to support up to 8 players with 28.8kbit modems.

Most modems have a bandwidth of 28.8K bits/second (both directions) to 56K bits/second (33.6K uplink) It takes actually 10 bits to send 1 byte. This makes calculating how many bytes you are sending easy however, as you just need to divide 28800 bits/second by 10 and end up with 2880 bytes per second.

We want to send many packets, more updated pro second and big packets, less protocol overhead.

If we do an update 6 times per second, leaving approximately 480 bytes per update in an ideal environment.

For the TCP/IP protocol we need following: IP Header 20 bytes UDP Header 8 bytes

With 10 bytes per command and 4 commands this are 68 (20+8+4*10) bytes pro packet. Sending it to 7 other players, gives 476 bytes pro update. This means we could do 6 updates (each 166ms) pro second.

Network packet

Putting it together

All computers in play must run absolute syncron. Only user commands are send over the network to the other computers. The command needs some time to reach the other clients (lag), so the command is not executed immediatly on the local computer, it is stored in a delay queue and send to all other clients. After a delay of NetworkLag game cycles the commands of the other players are received and executed together with the local command. Each NetworkUpdates game cycles there must a package send, to keep the clients in sync, if there is no user command, a dummy sync package is send. If there are missing packages, the game is paused and old commands are resend to all clients.

What features are missing

API How should it be used.

InitNetwork1()

InitNetwork2()

ExitNetwork1()

NetworkSendCommand()

NetworkSendExtendedCommand()

NetworkEvent()

NetworkQuit()

NetworkChatMessage()

NetworkEvent()

NetworkRecover()

NetworkCommands()

NetworkFildes

NetworkInSync

Todo:
FIXME: continue docu
(C) Copyright 1998-2012 by The Stratagus Project under the GNU General Public License.
All trademarks and copyrights on this page are owned by their respective owners.