This article describes networking issues in such as lag and jitter in BZFlag.
Jitter is a term for the variation in lag over time.
In very simple terms, if one were to ping a network host 2 times and each time it responded in 100 milliseconds, one can say that its jitter is 0 ms. If instead, the 2 ping times were 75 and 100 milliseconds, one could say the jitter is 25 ms. Of course the jitter calculations performed in BZFlag are a little more complex than that, incorporating averaging and smoothing over time.
Coders interested in jitter in BZFlag's context may wish to study LagInfo.cxx from the BZ source. It can be found in bzflag/game/Source Files/ (VS08) or src/game/ in a ordinary file browser.
The term Lag is a shorthand version for the concept of Network Latency. It represents the real world delay in sending messages from one computer to another over a network. All network connections have latency.
Lag is the network latency of a connection, or the time it takes for a network packet to travel from one host to another. Due to the speed of light, all network transmissions take some time, there is no such thing is a true "0" lag.
Different types of internet connections have different latency characteristics, dependent on the technologies they use. Most modern broadband systems ( like cable modems or DSL ) have a minimum latency that measures in a few milliseconds. Modems can have minimum latencies that measure in the 10s to 100s of milliseconds. The bandwidth rating of a network connection has little impact on it's minimum latency. A DSL line rated at 3 megabits in bandwidth often has the same latency as one rated at 1 megabit.
The distance along the network a message travels will also increase the time it takes to reach its destination. The more hubs, routers, and switches the packets have to travel ( or hops ) will add additional time, as each hop takes some time to complete. Hosts that are more physically distant usually have more hops between them, due to the nature of the internet.
Lag and BZFlag
Latency affects real time games in a very specific manner. A message sent from one user to the server will take some time to reach the server. This means that by the time the server receives a position update from a player, that user may have (and probably has) already moved from that position. Additional time is spent sending the message from the server to the other players. Depending on the latency of the various network connections, each player will get the update message at a different real world time.
The short version of this is, when you get a message, the client isn't there anymore. This presents problems for messages that are time sensitive, such as positional updates, and shots.
The current version of BZFlag (v.2.0.10) does not do any type of latency compensation on player messages. This means that the player you see on your screen is not where he is on his screen. This can produce an error in the perceived game states between the 2 users. One user may shoot where he believes the other is, and in his view score a hit, while on the other user's screen he has moved away from the position and saw a clear miss. The first user simply has not received his new positional update yet, because it is in the middle of network transmission.
The BZFlag server has a method for measuring the latency of each client, and displaying it as a numeric value in milliseconds. You can check lag for all players by using the command /lagstats while playing (just send /lagstats as a chat message). Lagstats shows an approximation of the amount of time it takes for a network message to go back and forth from one player to the server and back again, not the amount of time it takes to go from one player to another player. For example, if you fire a shot, your client sends a message to the server, giving shot direction and speed. The server then relays this information to all the other clients.
Other lag-related problems are "missing" or "dropped" packets and "jitter". These can occur if there are more severe network problems which cause messages between players and the server to simply get lost, or to be delayed by inconsistent amounts of time. In an attempt to keep this explanation simple, these problems will not be covered here, other than to say that they compound the effects of lag to an even higher degree.
Lag affects what you see while playing BZFlag, especially if the delay is high. The most common effect seen is "shots going through other tanks." Many times you will hear players say "my shot went through you", or "why didn't you die." Many people have been accused of cheating due to the sometimes misunderstood effects of lag.
How to fix lag depends on what is causing it.
|Slow Internet Connection||Lag can be caused by a slow internet connection, such as dial-up. In that case, find a server that is more allowing, or get a better connection.|
|Satellite Internet||Satellite internet causes too much lag for BZFlag.|
|Automatic Updates||Make sure software is not running scans for automatic updates in the background.|
|Downloads||Don't download something and play BZFlag at the same time.|
|Internet-intensive programs||Other programs, such as other people playing an online game on your network, can cause lag.|
|Distant Server||Try a different server. Often, lag is just caused by distance.|
The lag test program
On the right, is a capture from a test program created by Chestal. This test program allows us to accurately capture and replay events which occur in BZFlag. With a small modification to the BZflag client program, it is possible to log tank movements and shots to a file. This file can then be analyzed with a special visualization program. In this sample, you can see two tanks, surrounded by circles which are their 'hit-zones'. Any shots which intersect the hit-zone circle should result in an exploding tank! The green tank represents the player who was logging, other tank(s) are always red. Here, the green tank was lucky enough to avoid both shots by squeezing between them!
NOTE: The tools mentioned here are not generally available, due to the large size of the log files created, and requirements of the visualization tool. There was some progress on this (automatic playback, height indicator, map displaying, callsigns) but the results are not available to the public, either.
A real, common example of lag.
Here is a rather common example of a near-miss (no tanks exploded in this sequence). This is a real example, not an illustration. All three tankers were running the special logging client described above, and these images visualize all three captured logs at approximately the same moment. Note that even though lag was relatively low (all players were below 100ms), these captures show that each player sees something a bit different. Keep in mind that the green tank in each image is the one who's log is being shown. Click on any image for a full screen capture of the visualization tool.
TANK B's LOG:
Here we see tank B's point of view. From here, we see a shot which appears to hit tank A. In fact from this tank's point of view, it clearly does hit tank A.
(Note: Tank B lag was approx. 50ms)
TANK A's LOG:
And, here is tank A's point of view. The shot here has missed tank A. Keep in mind that tank A is moving forward here.
(Note: Tank A lag was approx. 90ms)
TANK C's LOG:
Tank C sees something similar to what tank B saw.
(Note: Tank C lag was approx. 25ms)
So, what happened?
Probably the most important factor to keep in mind here is that it is a player's OWN client which determines when he/she is hit, as it has the most accurate representation of its own tank location. Your tank's position is calculated locally, without any lag.
So, tank A did not explode, because it 'knew' that it had moved forward to avoid the shot. Due to the delay from lag, tanks B and C still saw tank A at its old position which had occurred a little over 1/10 second ago, so it appeared to them that the shot went through.
In conclusion, not only can understanding lag make you a better player, but it can also explain why shots seem to go through other tanks. In general, your shots will be much more accurate if you compensate for lag by shooting where you opponent will be in 100ms, or whatever you and your opponent's combined lag is. Of course, if your opponent is constantly switching directions, this can be difficult.
Packetloss is a term used in networking to describe an event where some of the data sent between computers does not reach the intended destination.
This loss of data can have detrimental effects on software that is expecting the data. In the case of BZFlag this data loss causes player tanks to not show correctly on remote clients and causes the game play mechanics to fail.
Many BZFlag game servers will force a user to disconnect if his/her packetloss is too high in order to ensure a playable game for the rest of the players.
BZFlag can display a packet loss percentage in its lagstats. This represents an approximation of the current data loss for the user. The number is computed by keeping track of how many lagping (MsgLagPing) packets are sent and how many are received. This ratio is the packetloss.
All packetloss happens in the network layer of a connection. The most common cause is a weak or intermittent network connection on a client's network. Low frame rate can cause Lag but not packetloss.
By far the most common reason for both high packetloss and high Jitter is poor wireless networking at the client end. Wireless networks are easily interrupted by interference from other radio signals. This includes both WIFI, cellular, and satellite connections. Many of these connection technologies are not suited for high speed gaming.
The most basic thing to try when attempting to resolve WIFI related issues is to connect client directly to the internet over an Ethernet cable. If that is not possible then changing the channel that the WIFI uses may help to reduce interference. Other issues are often are often not repairable by the end user, or just a limitation of the connection technology (i.e. satellite).
The route from the client to the server can also have packetloss, especially if the server is a long physical distance from the client, or the internet route is complex. These types of issues generally can not be resolved by the end user and are simply the nature of internet data transmissions.