Network Latency - Revision history

Simpsoa: Finalising

2009-04-13T02:31:11Z

Finalising

← Older revision		Revision as of 02:31, 13 April 2009
Line 26:		Line 26:

	Using [[Ping]] is a simple way to find your latency relative to some host address.		Using [[Ping]] is a simple way to find your latency relative to some host address.
-

	==Issues==		==Issues==
	===Streaming media===		===Streaming media===
-	Latency in [[streaming]] video or audio is not itself an issue, and (ideally) only delays by an absolute amount roughly equal to the ~~packets~~' average latency. Sudden spikes in latency may cause the ~~media~~ to be interrupted, though [[buffering]] is effective at preventing this to a point. Latency however becomes an issue when communication or interactivity is involved. Live television broadcasts have noticeable latency due to the nature of their transmission, ~~and~~ becomes apparent during satellite interviews and the like.	+	Latency in [[streaming]] video or audio is not itself an issue, and (ideally) only delays receipt by an absolute amount roughly equal to the connection's average latency. Sudden spikes in latency may cause the stream to be interrupted, though [[buffering]] is effective at preventing this to a point. Latency however becomes an issue when communication or interactivity is involved. Live television broadcasts have noticeable latency due to the nature of their transmission, which becomes apparent during satellite interviews and the like. This delay is a common problem with [[VoIP]] services such as [http://www.skype.com/intl/en/ Skype]

-	~~===Quantum Computing===~~
	===Real-Time Gaming===		===Real-Time Gaming===
	[[Image:Lag_compensation.jpg\|thumb\|right\|450px\|An example of lag compensation in Counter-Strike: Source. The man running left shows the player's actual position on the server, whereas the coloured boxes show their position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]		[[Image:Lag_compensation.jpg\|thumb\|right\|450px\|An example of lag compensation in Counter-Strike: Source. The man running left shows the player's actual position on the server, whereas the coloured boxes show their position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]
	[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.		[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.

-	Modern [[game engines]] such as Valve Software's Source Engine implement a number of lag compensation techniques<sup>[1]</sup>. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as '''client-side prediction'''.	+	Modern [[game engines]] such as Valve Software's Source Engine implement a number of lag compensation techniques<sup>[1]</sup>. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as ''client-side prediction''.

-	In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).	+	In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a [[naive]] collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).

	==Potential Uses==		==Potential Uses==
		+	Though reducing network latency is nearly always desireable, it is possible for applications to take advantage of its existence in order to provide services not otherwise possible. An article in Computer Networks journal describes a method whereby it is possible to implement a lag compensation system in an online multiplayer game using network latency that simulates a form of [[time dilation]].<sup>[2]</sup> The end result is that through using what are called ''local perception filters'' a fully synchronized game can appear to be going in slow motion for short periods to some players but not others. If implemented naively, this disparity in game speeds would cause players to desynchronize.

-	~~Though reducing network latency is nearly always desireable, it is possible for applications to take advantage of its existence in order to provide services not otherwise possible~~. ~~An article in Computer Networks journal describes a method whereby it is possible to implement a lag compensation system in an online multiplayer game using network latency that simulates a form of~~ [~~[time dilation]~~].~~<sup>~~[~~2]<~~/~~sup> The end result is that through using what are called ''~~local perception filters'' a ~~fully synchronized game can appear to be going in slow motion for short periods to some players but not others~~.	+	==References==
		+	*1. [http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking Source Engine Multiplayer Networking]
		+	*2. [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6VRG-4G94G99-2&_user=10&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=64b8d82ca3ba63232b0e8712ce061840 Realizing the bullet time effect in multiplayer games with local perception filters]
		+	* [http://compnetworking.about.com/od/speedtests/a/network_latency.htm About.com, Network Bandwidth and Latency]
		+	* [http://developer.valvesoftware.com/wiki/Lag_Compensation Valve development wiki page on lag compensation]

-	<ref>{{cite journal \|title=Realizing the bullet time effect in multiplayer games with local perception filters \|author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen \|journal=Computer Networks \|volume=49 \|issue=1 \|pages=27-37 \|date=31 May 2005}}</ref>
-
-	~~==References==~~
-	*1. http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
-	*2. http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6VRG-4G94G99-2&_user=10&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=64b8d82ca3ba63232b0e8712ce061840
-	*3. https://developer.mozilla.org/En/Link_prefetching_FAQ
-	*4. http://developer.valvesoftware.com/wiki/Lag_Compensation
	==See Also==		==See Also==
	*[[Packet-switching]]		*[[Packet-switching]]
Line 58:		Line 54:
	*[[Computer Networking]]		*[[Computer Networking]]
	*[[Bandwidth]]		*[[Bandwidth]]
		+
	==External Links==		==External Links==
-	http://www.michaelnygard.com/blog/2007/11/architecting_for_latency.html	+	*[http://www.michaelnygard.com/blog/2007/11/architecting_for_latency.html Wide Awake Developers, Architecting for Latency]
		+	*[http://www.wikihow.com/Test-Network-and-Internet-Latency-(Lag)-in-Microsoft-Windows wikiHow, Instructions for testing latency in Microsoft Windows]

Simpsoa at 02:13, 13 April 2009

2009-04-13T02:13:58Z

← Older revision		Revision as of 02:13, 13 April 2009
Line 16:		Line 16:
	===Distance===		===Distance===
	Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.		Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of [http://en.wikipedia.org/wiki/Relativity Relativity]. This is particularly an issue in the field of [http://en.wikipedia.org/wiki/Space_Exploration Space Exploration], where the round-trip time of communication is commonly measured in minutes or hours. Because of this, [http://en.wikipedia.org/wiki/Rover_(space_exploration) rovers] must be programmed with some level of [[artificial intelligence]] so that moment-to-moment decisions can be made autonomously.
		+
		+	Due to communication over large distances, [[satellite]] [[internet]] connections naturally have a large amount of latency regardless of bandwidth.

	==Measuring Latency==		==Measuring Latency==
Line 27:		Line 29:

	==Issues==		==Issues==
-	===~~Web Surfing~~===	+	===Streaming media===
		+	Latency in [[streaming]] video or audio is not itself an issue, and (ideally) only delays by an absolute amount roughly equal to the packets' average latency. Sudden spikes in latency may cause the media to be interrupted, though [[buffering]] is effective at preventing this to a point. Latency however becomes an issue when communication or interactivity is involved. Live television broadcasts have noticeable latency due to the nature of their transmission, and becomes apparent during satellite interviews and the like.
		+
	===Quantum Computing===		===Quantum Computing===
	===Real-Time Gaming===		===Real-Time Gaming===
-	[[Image:Lag_compensation.jpg\|thumb\|right\|~~500px~~\|An example of lag compensation in Counter-Strike: Source. The man running left shows the player's actual position on the server, whereas the coloured boxes show their position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]	+	[[Image:Lag_compensation.jpg\|thumb\|right\|450px\|An example of lag compensation in Counter-Strike: Source. The man running left shows the player's actual position on the server, whereas the coloured boxes show their position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]
	[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.		[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.

-	Modern [[game engines]] such as Valve Software's Source Engine <sup>[x]</sup> ~~implement a number of lag compensation techniques~~. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as '''client-side prediction'''.	+	Modern [[game engines]] such as Valve Software's Source Engine implement a number of lag compensation techniques<sup>[1]</sup>. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as '''client-side prediction'''.

	In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).		In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).
Line 39:		Line 43:
	==Potential Uses==		==Potential Uses==

-	Though reducing network latency is nearly always desireable, it is possible for applications to take advantage of its existence in order to provide services not otherwise possible. An article in Computer Networks journal describes a method whereby it is possible to implement a lag compensation system in an online multiplayer game using network latency that simulates a form of [[time dilation]].<sup>[x]</sup> The end result is that through using what are called ''local perception filters'' a fully synchronized game can appear to be going in slow motion for short periods to some players but not others.	+	Though reducing network latency is nearly always desireable, it is possible for applications to take advantage of its existence in order to provide services not otherwise possible. An article in Computer Networks journal describes a method whereby it is possible to implement a lag compensation system in an online multiplayer game using network latency that simulates a form of [[time dilation]].<sup>[2]</sup> The end result is that through using what are called ''local perception filters'' a fully synchronized game can appear to be going in slow motion for short periods to some players but not others.
		+
	<ref>{{cite journal \|title=Realizing the bullet time effect in multiplayer games with local perception filters \|author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen \|journal=Computer Networks \|volume=49 \|issue=1 \|pages=27-37 \|date=31 May 2005}}</ref>		<ref>{{cite journal \|title=Realizing the bullet time effect in multiplayer games with local perception filters \|author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen \|journal=Computer Networks \|volume=49 \|issue=1 \|pages=27-37 \|date=31 May 2005}}</ref>

	==References==		==References==
-	~~{{reflist}}~~	+	*1. http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
-	http://en.~~wikipedia~~.org/~~wiki~~/~~Link_prefetching~~	+	*2. http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6VRG-4G94G99-2&_user=10&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=64b8d82ca3ba63232b0e8712ce061840
-	http://developer.valvesoftware.com/wiki/~~Source_Multiplayer_Networking~~	+	*3. https://developer.mozilla.org/En/Link_prefetching_FAQ
		+	*4. http://developer.valvesoftware.com/wiki/Lag_Compensation
	==See Also==		==See Also==
-	~~http://www.michaelnygard.com/blog/2007/11/architecting_for_latency.html~~	+	*[[Packet-switching]]
		+	*[[Multiplayer Games]]
		+	*[[Ping]]
		+	*[[Computer Networking]]
		+	*[[Bandwidth]]
	==External Links==		==External Links==
		+	http://www.michaelnygard.com/blog/2007/11/architecting_for_latency.html

Simpsoa at 00:35, 13 April 2009

2009-04-13T00:35:27Z

← Older revision		Revision as of 00:35, 13 April 2009
Line 18:		Line 18:

	==Measuring Latency==		==Measuring Latency==
		+	[[Image:Ping.JPG\|thumb\|right\|350px\|Using Ping to calculate network latency in Microsoft Windows XP.]]
	Network conditions constantly fluctuate, and so measuring the latency in transmitting a packet between the same two endpoints multiple times can have differing results. Because of this, the latency of any single packet may not be a meaningful measurement. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.		Network conditions constantly fluctuate, and so measuring the latency in transmitting a packet between the same two endpoints multiple times can have differing results. Because of this, the latency of any single packet may not be a meaningful measurement. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.

Line 26:		Line 27:

	==Issues==		==Issues==
		+	===Web Surfing===
	===Quantum Computing===		===Quantum Computing===
	===Real-Time Gaming===		===Real-Time Gaming===
-	[[Image:Lag_compensation.jpg\|thumb\|right\|~~600px~~\|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show ~~his~~ position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]	+	[[Image:Lag_compensation.jpg\|thumb\|right\|500px\|An example of lag compensation in Counter-Strike: Source. The man running left shows the player's actual position on the server, whereas the coloured boxes show their position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]
	[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.		[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.

Line 35:		Line 37:
	In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).		In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).

-	==~~Compensating for latency~~==	+	==Potential Uses==
-	~~When a noticeable latency is unavoidable, some method of hiding the latency from the user needs to be employed. One strategy for this is prefetching~~	+
-		+
-	~~Suppose that a piece of real-time software needs to communicate with a server acting as an authority on the application's state, and that the network has a round-trip latency of 100 milliseconds.~~	+
-	~~===Prefetching===~~	+
-	~~Some web browsers (such as Mozilla Firefox <sup>[x]</sup>)~~	+
-		+
-	~~===Prediction===~~	+
-		+
-		+
-	~~===Interpolation===~~	+
-	~~[[Image:Interpolation.gif\|right\|]]~~	+
-	~~Programs which~~	+
-		+
-		+

		+	Though reducing network latency is nearly always desireable, it is possible for applications to take advantage of its existence in order to provide services not otherwise possible. An article in Computer Networks journal describes a method whereby it is possible to implement a lag compensation system in an online multiplayer game using network latency that simulates a form of [[time dilation]].<sup>[x]</sup> The end result is that through using what are called ''local perception filters'' a fully synchronized game can appear to be going in slow motion for short periods to some players but not others.
	<ref>{{cite journal \|title=Realizing the bullet time effect in multiplayer games with local perception filters \|author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen \|journal=Computer Networks \|volume=49 \|issue=1 \|pages=27-37 \|date=31 May 2005}}</ref>		<ref>{{cite journal \|title=Realizing the bullet time effect in multiplayer games with local perception filters \|author=Jouni Smed, Henrik Niinisalo, and Harri Hakonen \|journal=Computer Networks \|volume=49 \|issue=1 \|pages=27-37 \|date=31 May 2005}}</ref>
-

	==References==		==References==

Simpsoa at 23:59, 12 April 2009

2009-04-12T23:59:57Z

← Older revision		Revision as of 23:59, 12 April 2009
Line 18:		Line 18:

	==Measuring Latency==		==Measuring Latency==
-	~~Due to fluctuating network~~ conditions, the latency ~~of individual packets within~~ the same ~~session of communication~~ can ~~vary wildly~~. Because of this, the latency of any single packet may not be meaningful. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.	+	Network conditions constantly fluctuate, and so measuring the latency in transmitting a packet between the same two endpoints multiple times can have differing results. Because of this, the latency of any single packet may not be a meaningful measurement. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.

-	A simple solution to both of these problems is calculating latency using average round-trip time. ~~Finding the round~~-trip ~~time of~~ communication can be ~~done~~ from a single host, and taking the average latency over several packets provides a ~~more stable and representative~~ estimate of the ~~expected~~ delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.	+	A simple solution to both of these problems is calculating latency using average round-trip time. Round-trip communication times can be measured from a single host, and taking the average latency over several packets provides a reasonable estimate of the delay needed for future packets to arrive. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher. Also, the time a host takes to process packets is typically not included when calculating a round-trip time, but users and applications waiting for data will experience this delay just the same.

-	~~Note, the time that a remote host takes to process a packet~~ is ~~typically not included when calculating~~ a ~~round-trip time~~.	+	Using [[Ping]] is a simple way to find your latency relative to some host address.
-	==Issues ~~caused~~ ==	+
		+
		+	==Issues==
	===Quantum Computing===		===Quantum Computing===
	===Real-Time Gaming===		===Real-Time Gaming===

Simpsoa at 22:45, 12 April 2009

2009-04-12T22:45:53Z

← Older revision		Revision as of 22:45, 12 April 2009
Line 57:		Line 57:
	http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking		http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
	==See Also==		==See Also==
		+	http://www.michaelnygard.com/blog/2007/11/architecting_for_latency.html
	==External Links==		==External Links==

Simpsoa: /* Issues Caused by Latency and Solutions */

2009-04-12T22:22:28Z

Issues Caused by Latency and Solutions

← Older revision		Revision as of 22:22, 12 April 2009
Line 23:		Line 23:

	Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.		Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.
-	==Issues ~~Caused by Latency and Solutions~~==	+	==Issues caused ==
	===Quantum Computing===		===Quantum Computing===
	===Real-Time Gaming===		===Real-Time Gaming===
Line 31:		Line 31:
	Modern [[game engines]] such as Valve Software's Source Engine <sup>[x]</sup> implement a number of lag compensation techniques. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as '''client-side prediction'''.		Modern [[game engines]] such as Valve Software's Source Engine <sup>[x]</sup> implement a number of lag compensation techniques. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as '''client-side prediction'''.

-	In order to mitigate the discrepancies between the server~~'s gamestate~~ and ~~the~~ clients', latency can be factored into critical ~~gameplay~~ calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state.	+	In order to mitigate the discrepancies between the server and clients, latency can be factored into critical gamestate calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state. Though some mathematical imprecision may result, this much more closely aligns the events of the game with what each player is seeing (shown on the right).

	==Compensating for latency==		==Compensating for latency==

Simpsoa: /* Effects */

2009-04-12T22:02:36Z

Effects

← Older revision		Revision as of 22:02, 12 April 2009
Line 23:		Line 23:

	Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.		Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.
-	==~~Effects~~==	+	==Issues Caused by Latency and Solutions==
	===Quantum Computing===		===Quantum Computing===
	===Real-Time Gaming===		===Real-Time Gaming===

Simpsoa: /* Real-Time Gaming */

2009-04-12T21:58:37Z

Real-Time Gaming

← Older revision		Revision as of 21:58, 12 April 2009
Line 27:		Line 27:
	===Real-Time Gaming===		===Real-Time Gaming===
	[[Image:Lag_compensation.jpg\|thumb\|right\|600px\|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show his position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]		[[Image:Lag_compensation.jpg\|thumb\|right\|600px\|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show his position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]
-	[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' ~~inputs~~ and the game's response. Modern games ~~of this type~~ are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to ~~mentally~~ compensate for the delay by performing ~~input~~ earlier than actually desired.	+	[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' input and the game's response. Modern online games are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to manually compensate for the delay by performing actions earlier than actually desired.

-	Modern [[game engines]] such as Valve Software's Source Engine <sup>[x]</sup> implement a number of lag compensation techniques. To eliminate the ~~apparent~~ delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as '''client-side prediction'''.	+	Modern [[game engines]] such as Valve Software's Source Engine <sup>[x]</sup> implement a number of lag compensation techniques. To eliminate the perceived delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as '''client-side prediction'''.

-	~~Client-side prediction is based off~~ the ~~assumption that basing~~ gameplay ~~events off of~~ clients' ~~individual latencies as well as~~ the server's ~~authoritative state provides~~ a ~~smoother experience~~. ~~Whenever a predicted effect~~	+	In order to mitigate the discrepancies between the server's gamestate and the clients', latency can be factored into critical gameplay calculations. For example, suppose the server wants to check if player A shoots player B. Since the clients' predictions are not perfectly accurate, clients can never be sure of the server's exact gamestate, and a naive collision check would make it impossible to hit player B consistently. Instead, the server looks back in time (according to player A's round-trip latency) and checks to see if player A's hit would be successful according to that state.

	==Compensating for latency==		==Compensating for latency==

Simpsoa: Much new content in gaming section

2009-04-12T21:22:27Z

Much new content in gaming section

← Older revision		Revision as of 21:22, 12 April 2009
Line 26:		Line 26:
	===Quantum Computing===		===Quantum Computing===
	===Real-Time Gaming===		===Real-Time Gaming===
-	[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' inputs and the game's response. Modern games of this type are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to mentally compensate ~~their actions~~ for the delay~~, but most games now use some method of client-side prediction in order to avoid the need to~~.	+	[[Image:Lag_compensation.jpg\|thumb\|right\|600px\|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show his position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]]
		+	[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' inputs and the game's response. Modern games of this type are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to mentally compensate for the delay by performing input earlier than actually desired.

-	==~~Mitigation strategies~~==	+	Modern [[game engines]] such as Valve Software's Source Engine <sup>[x]</sup> implement a number of lag compensation techniques. To eliminate the apparent delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as '''client-side prediction'''.
		+
		+	Client-side prediction is based off the assumption that basing gameplay events off of clients' individual latencies as well as the server's authoritative state provides a smoother experience. Whenever a predicted effect
		+
		+	==Compensating for latency==
		+	When a noticeable latency is unavoidable, some method of hiding the latency from the user needs to be employed. One strategy for this is prefetching
		+
		+	Suppose that a piece of real-time software needs to communicate with a server acting as an authority on the application's state, and that the network has a round-trip latency of 100 milliseconds.
	===Prefetching===		===Prefetching===
		+	Some web browsers (such as Mozilla Firefox <sup>[x]</sup>)

	===Prediction===		===Prediction===
		+
		+
	===Interpolation===		===Interpolation===
		+	[[Image:Interpolation.gif\|right\|]]
		+	Programs which
		+


Line 40:		Line 54:
	==References==		==References==
	{{reflist}}		{{reflist}}
		+	http://en.wikipedia.org/wiki/Link_prefetching
		+	http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
	==See Also==		==See Also==
	==External Links==		==External Links==

Simpsoa at 23:22, 8 April 2009

2009-04-08T23:22:37Z

← Older revision		Revision as of 23:22, 8 April 2009
Line 7:		Line 7:
	*The perceived delay in communication between hosts		*The perceived delay in communication between hosts

-	~~The~~ round-trip time of a packet is ~~also~~ commonly known as '''ping'''.	+	In [[online]] [[multiplayer games]], the round-trip time of a packet is commonly known as '''ping'''.

	==Causes==		==Causes==
Line 25:		Line 25:
	==Effects==		==Effects==
	===Quantum Computing===		===Quantum Computing===
-	~~===Space Exploration===~~
	===Real-Time Gaming===		===Real-Time Gaming===
-	[[Real-time]] [[online]] multiplayer [[games]] suffer from network latency, causing a delay between the players' inputs and the game's response. ~~Games~~ of this type are typically designed to use a [[client-server networking]] model. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. ~~Initially~~ the only ~~way to circumvent this~~ was for players to mentally compensate their actions for the delay, but most games now use some method of client-side prediction in order to avoid the need to.	+	[[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' inputs and the game's response. Modern games of this type are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to mentally compensate their actions for the delay, but most games now use some method of client-side prediction in order to avoid the need to.

	==Mitigation strategies==		==Mitigation strategies==