Hacker News Reader

Comment by someweirdperson | Hacker News Reader

Artificial or natural delays, I am somewhat confused that one end measuring/calculating ping can end up with a wrong value. Transmit at local time x, receive at local time y, subtract. It only needs a working local clock.

Second surprising thing is artifical latency added on the client. Anything on the client I would avoid, if possible.

Third, this all looks like magically connecting two ends. But it is packets flowing from one to the other, and the other to the one. Latency could be added to each independently, even on one end, by artificially buffering to-be-send and/or received packets.

What are the implications for game-play with an asymetric latency, e.g. theoretical 0 delay to receive vs. long delay to transmit, or vice versa?

View on HN

The article doesn’t seem to discuss transmit versus receive latency asymmetry, nor did I see it mention jitter (although I admit I skimmed article).

With two cities, a dedicated common connection with measurements for latency in both directions, and real-time tit-for-tat latency adjustment would be appropriate (if remote city A gets latency X, ensure local city B approximately gets latency X on next game tick)

Without that:

0. latency fluctuations could penalise the remote team even though average latency was kept consistent over longer periods,

1. local players could advantage themselves by injecting delays or jitter into remote players during critical periods of play (DoS like network traffic between local and remote cities),

2a. local players could get server updates 10s of milliseconds before remote players (if all latency adjustment added on transmit from player to server), or

2b. local players could get their events updated to the server 10s of milliseconds before remote players (if all latency adjustment added on transmit from server to player).

I think the symmetric delay here makes sense, since you're trying to simulate the latency of a (likely) symmetric connection between another client and the server.

If you only add latency on the transmission, then 2 actions taken at the same time by players with different amounts of physical latency will be processed at different times. If we assume the game clocks on each client and the server are in sync, then this creates a competitive advantage for the player with lower physical latency. For instance, if we have a timing battle (ie: Zhonya's hourglass), where both players know that at time 'T' they must each take an action, and the first to do so comes out on top, then the player with higher physical latency is at a disadvantage.

You can accomplish this by putting it all on the client, all on the server, or a mix of both (what they chose).

For all on the server, you could add latency right after receiving data from the client, but before game code processes it, and before sending data to the client.

That said, there likely were technical considerations involved in their decision to do a mix of both.

That's a good point, I hadn't thought of having independent send a receive delays on the server, simulating a delayed connection from the client's perspective without having it participate.

I now wonder too what those technical considerations are, since having the client add latency requires trusting the client to add the delay and not cheat.

Reply on news.ycombinator.com