Network Lag Counter Measures Discussion

Blitz3D Forums/Blitz3D Programming/Network Lag Counter Measures Discussion

Techlord

(Posted 2004) [#1]

In developing PPF2K4.5 Network Architecture my primary focus is addressing Network Lag. I would like to discuss counter measures and what others are doing to minimize network lag using Blitz Network.

My Network implementation is designed around the principle that the Server is the Game Authority managing all gameworld logic, while the Client is I/O Interface to Render a 'copy' of the Server's GameWorld and transmits inputs from player to the server.

I'm using a combination of TCP and UDP protocols. TCP for Mandatory Data (Initial GameWorld State), UDP for 'Twitch' Data (Updates and Client Input). I'm implementing my own UDP Tx/Rx data checking systems on the Server/Client. I'm Tx/Rx data in packets of specific byte size, vs streams. This includes text messages (chat) too.

I'm implementing the following anti-lag techniques:
1. Transmit to only players who need the data
2. Transmit only data of game objects that have changed state.
3. Interpolation
4. Compression

I'm aware of other awesome Blitz Network libraries out there, however, I would like to direct this discussion towards those interested in developing their own.

skidracer

(Posted 2004) [#2]

I'm more inclined (without any experience mind you) to suggest that it is better to have a constant throughput on connections than using any method that results in variable size and number of packets.

The maximum number of players should dictate the network requirements not some variable hard to calculate usage that will be both hard to test and play havoc with any routing / compression between machines.

Techlord

(Posted 2004) [#3]

skidracer: I'm more inclined (without any experience mind you) to suggest that it is better to have a constant throughput on connections than using any method that results in variable size and number of packets.

I would agree. Implementing a method to create a constant throughput on connections is where the challenge lies. TCP only guarantees the data will 'eventually' get to its destination, it says nothing about how long it will take. UDP doesnt guarantee anything, which ironically is its speed benefit as no checks are made.

I'm attempting to deal with this by 'continuously' transmitting packets of fixed size via UDP, regardless if they contain data or empty. The concept is very similar to Asynchronous Transfer Mode (ATM) Cells.

In my research, others discuss using data transmission duplication techniques as in sending two or more packets with same info in succesion. I'm considering this as well.