Difference between revisions of "Latency"

From ASSS Wiki
Jump to: navigation, search
(Information about latency by Ekted -- needs a category and whatnots.)
 
m (changed format to match Door Sync)
Line 1: Line 1:
'''Source:''' http://forums.powerballzone.com/read.php?board=5&id=42371
+
Source: http://forums.powerballzone.com/read.php?board=5&id=42371
  
 +
'''[[Mr Ekted]] says:'''
 +
----
 
There's no way to know one-way latency on a network; you can only estimate it. The Subspace protocol does this as follows:
 
There's no way to know one-way latency on a network; you can only estimate it. The Subspace protocol does this as follows:
  
- The client sends a packet with its current time (in milliseconds) to the server every 5 seconds.
+
*The client sends a packet with its current time (in milliseconds) to the server every 5 seconds.
- When the server receives this packet, it immediately replies, sending back the client's time and the current server time.
+
*When the server receives this packet, it immediately replies, sending back the client's time and the current server time.
- When (if) the client receives this reply, it now knows: how long it took (round trip) for the sync exchange, and the server time at some point in the "middle".
+
*When (if) the client receives this reply, it now knows: how long it took (round trip) for the sync exchange, and the server time at some point in the "middle".
  
 
Example:
 
Example:
 
+
<pre>
 
Client send time: 100
 
Client send time: 100
 
Client receive time: 300
 
Client receive time: 300
Line 15: Line 17:
 
Round trip: 200
 
Round trip: 200
 
Server time estimate (at client time 300): 1000 + (300 - 100) / 2 = 1100
 
Server time estimate (at client time 300): 1000 + (300 - 100) / 2 = 1100
 
+
</pre>
 
The actual clients do not use 50%, but 60%. Don't ask me why.
 
The actual clients do not use 50%, but 60%. Don't ask me why.
  
 
All packets that require time use the server time. This includes movement, weapons, and ball packets. If the sync packet exchange suffers an extra delay of 1000ms at the C rounter (from my picture), you would get something like this:
 
All packets that require time use the server time. This includes movement, weapons, and ball packets. If the sync packet exchange suffers an extra delay of 1000ms at the C rounter (from my picture), you would get something like this:
 
+
<pre>
 
Client send time: 100
 
Client send time: 100
 
Client receive time: 1300
 
Client receive time: 1300
Line 27: Line 29:
 
Server time estimate (at client time 1300): 1000 + (1300 - 100) / 2 = 1600
 
Server time estimate (at client time 1300): 1000 + (1300 - 100) / 2 = 1600
 
Actual server time (at client time 1300): 2100
 
Actual server time (at client time 1300): 2100
 
+
</pre>
 
This creates "fake" C2S latency. So for the next 5 seconds, the client will send estimated times that are early by about 500ms, making the server think they were sent much further in the past than they were. If the client were allowed to continue to play under these circumstances, their ship would be displayed incorrectly by about 160 pixels at full speed in PB, and even more for weapons. Even though this latency is "fake", the sync issue is still bad enough that the client cannot be allowed to stay in game.
 
This creates "fake" C2S latency. So for the next 5 seconds, the client will send estimated times that are early by about 500ms, making the server think they were sent much further in the past than they were. If the client were allowed to continue to play under these circumstances, their ship would be displayed incorrectly by about 160 pixels at full speed in PB, and even more for weapons. Even though this latency is "fake", the sync issue is still bad enough that the client cannot be allowed to stay in game.
 +
----

Revision as of 16:23, 26 March 2005

Source: http://forums.powerballzone.com/read.php?board=5&id=42371

Mr Ekted says:


There's no way to know one-way latency on a network; you can only estimate it. The Subspace protocol does this as follows:

  • The client sends a packet with its current time (in milliseconds) to the server every 5 seconds.
  • When the server receives this packet, it immediately replies, sending back the client's time and the current server time.
  • When (if) the client receives this reply, it now knows: how long it took (round trip) for the sync exchange, and the server time at some point in the "middle".

Example:

Client send time: 100
Client receive time: 300
Server time: 1000 (remember that the 2 internal clocks are not the same values)

Round trip: 200
Server time estimate (at client time 300): 1000 + (300 - 100) / 2 = 1100

The actual clients do not use 50%, but 60%. Don't ask me why.

All packets that require time use the server time. This includes movement, weapons, and ball packets. If the sync packet exchange suffers an extra delay of 1000ms at the C rounter (from my picture), you would get something like this:

Client send time: 100
Client receive time: 1300
Server time: 1000

Round trip: 1200
Server time estimate (at client time 1300): 1000 + (1300 - 100) / 2 = 1600
Actual server time (at client time 1300): 2100

This creates "fake" C2S latency. So for the next 5 seconds, the client will send estimated times that are early by about 500ms, making the server think they were sent much further in the past than they were. If the client were allowed to continue to play under these circumstances, their ship would be displayed incorrectly by about 160 pixels at full speed in PB, and even more for weapons. Even though this latency is "fake", the sync issue is still bad enough that the client cannot be allowed to stay in game.