Serious advanced question: ping

[Baker]

In NetQuake, reported ping is determined by the client.

1. Is this true in Quakeworld? [Extra credit: What about DarkPlaces server?]
2. How can true ping be determined by the server?

Just a rough skeleton or sketchy explanation should do. I don't believe in the idea of "trust the client".

[ceriux]

baker if your messing with the network code please dont make it like quakeworlds, i hate that movement is always 100% predetermined and editable.

[Error]

isn't ping how fast it takes a client to send a packet and then receive one? or something like that?

[mh]

isn't ping how fast it takes a client to send a packet and then receive one? or something like that?

Yeah, that's all. Nothing else to see here, no cause for alarm.

[Spike]

'reported ping is determined by the client'.
false.
the client echos the server's time. the server calculates the difference between the current server time and the time the client reported, thus ping is determined by the server.
the client can of course report the wrong server time and confuse the server.

1: in quakeworld ping is determined based upon sequence numbers.
if you reply with the wrong sequence, you get a suboptimal connection, and most likely buggy entities.
(specifically, the client says which entity-state sequence it received, the client checks when it sent it, and thus ping is determined)

2a: make it too painful for the ping to be faked by changing protocols to use sequences as in quakeworld.
2b: validate the times the client says are server times. as an nq client always only echos a packet from the server, the times the client reports should always exactly match one of the packets the server sent and should not be duplicated (unless the server sent duplicates of course, which it shouldn't do). send a randomized 'stuffcmd cmd' to ensure that the time is not too inaccurate.
make sure the unreliable packets from the client match the sequence set by the server. you might get dropped packets, but you should never get more unreliable/datagram packets from the client than the server sent to it (warning, clients might start the sequences abnormally high).

[Baker]

'reported ping is determined by the client'.
false.
the client echos the server's time. the server calculates the difference between the current server time and the time the client reported, thus ping is determined by the server.
the client can of course report the wrong server time and confuse the server.

1: in quakeworld ping is determined based upon sequence numbers.
if you reply with the wrong sequence, you get a suboptimal connection, and most likely buggy entities.
(specifically, the client says which entity-state sequence it received, the client checks when it sent it, and thus ping is determined)

2a: make it too painful for the ping to be faked by changing protocols to use sequences as in quakeworld.
2b: validate the times the client says are server times. as an nq client always only echos a packet from the server, the times the client reports should always exactly match one of the packets the server sent and should not be duplicated (unless the server sent duplicates of course, which it shouldn't do). send a randomized 'stuffcmd cmd' to ensure that the time is not too inaccurate.
make sure the unreliable packets from the client match the sequence set by the server. you might get dropped packets, but you should never get more unreliable/datagram packets from the client than the server sent to it (warning, clients might start the sequences abnormally high).

This is what I meant, thanks for the info Spike. In NetQuake there is an evil way to lie to the server what your ping is. In fact, DarkPlaces reports the wrong ping to NetQuake servers, not as an exploit, but I guess as part of some enhanced accuracy philosophy that LordHavoc has --- which I don't really recall his explanation, but commonly you can see 0 ping connections to NetQuake servers from DarkPlaces and 0 ping obviously is not possible even on a LAN.

isn't ping how fast it takes a client to send a packet and then receive one? or something like that?

Yeah, that's all. Nothing else to see here, no cause for alarm.

Actually ... well ... I would prefer to not explain on a public forum. Even though I don't believe in --- ugh I hate this expression --- "security through obscurity". I want to remove the "security through obscurity" aspect of this.

[qbism]

What's the advantage of 0 ping? Says to the server, "I saw it first?"

Am I hearing that we're about to see client-side ping-warping based on the desired outcome of reverse-engineered missile/target collisions and that it only takes 4 lines of code? Server just assumes everyone is fibbing. Unless it's co-op.

Pings, damned pings, and statistics.

[Baker]

What's the advantage of 0 ping? Says to the server, "I saw it first?"

There isn't an advantage of false 0 ping, but the ability to accurately measure ping can give server operators the discretion of allowing or disallowing play.

There are servers where play is more competitive and having some guy with crappy ping show up and want to play can create interference.

[OneManClan]

[Disclaimer: I'm still a newbie, so if this is explained somewhere please give me a link so I can rtfm, thanks]

What is the relationship between Ping and packet loss re: one player having an advantage over another? The wiki on pingsays that Ping 'records any packet loss' in its result.

When hitting 'tab' in qw however, the console [edit: i mean the display] shows Packet Loss in a separate column to Ping. Is packet loss considered a separate issue in qw?

Does this mean the 'packet loss figure' can be used by the server to modify the 'game state' ie 'who shot who and when'? Otoh, if players can fake their pings(?), can they also fake packet loss..?

[qbism]

That wiki article is about an unfortunately named software called "ping" that measures ping and other things. Believe me, I know about being lazy when naming things.

Ping is the round trip time. As Error said, nothing else to see here. Packet loss is a separate measurement that affects ping.

if players can fake their pings(?), can they also fake packet loss..?

Interesting question as to what could be gained. Or maybe it just becomes more likely to be dropped from the server.

[Baker]

What is the relationship between Ping and packet loss re: one player having an advantage over another?

Packet loss is a horrific problem. Ping you can deal with the extent possible.

I have played NetQuake with 25 ping and bad packet loss and was frustrated to the maximum. 25 ping obviously is quite awesome, but packet loss will make you angry.

I have also played Quakeworld with 250 ping, and you get smoked due to the "visual delay".

I'm not sure I have adequately answered your question, but packet loss is a nightmare.

[Sajt]

Actually, technically, multiplayer is fundamentally a nightmare. For the player I mean, more than the networking coding. Don't bother playing any multiplayer games, I've tried it, it's not fun. Just stick with singleplayer and maybe coop. Or even don't play games at all. They're a waste of time.

Networking coding can be fun, because at least it can be solved comprehensively with an elegant system, unlike certain problems in engine programming such as collision detection, which can't be solved at all.

[OneManClan]

if players can fake their pings(?), can they also fake packet loss..?

Interesting question as to what could be gained. Or maybe it just becomes more likely to be dropped from the server.

If the server makes some kind of concession to the HPBs, LPBs could try to fake that they also have a high ping to get an advantage.

I'm not sure I have adequately answered your question, but packet loss is a nightmare.

Thanks Baker. What's considered excellent, average, and crappy packet loss? ie we all know a ping < 50 is excellent, 200+ is sucky, whats the packet loss equivalent? The Quake (qw) display shows 0-1 normally in the 'PL' column, last week (when I had modem issues) it was showing 10-12.

Also, I know the QuakeC can access a players ping via:

Code: Select all

string_variable = infokey(player_entity,"ping");

How do we access a players packet loss?

[Irritant]

There is little in-game you can do about packet loss - it's a function of a poor connection to the server, not the game code. A lost packet is just that, lost. Usually the player notices this most when firing weapons or making a movement change.

[Spike]

r_netgraph in quakeworld, when set to 1, each column shows your ping for that individual frame (clientside calculated, server calculates separately and averages).

A white bar represents a packet which bounced off the server. All is good with the world. Its height will indicate your ping. Typically one screen pixel per ms.

A yellow bar means the server intentionally 'dropped' a packet. Nothing was lost, it'll just be resent a little later - tip: increase your 'rate' cvar/userinfo.

A red bar means a packet was lost on the wire. Its gone for good. The info inside will be resent if it was a reliable packet. If there was a sound effect, you will never hear it. Entity data will be resent based on the last-known-good state anyway, so not really any different from yellow in that regard. But it'll still count against your rate. Red means your ISP sucks.

A blue bar means a packet arrived... But it was bad. The sequence didn't match. Your ISP sucks big time. Super big time. The game is receiving packets in the wrong order from how they were sent! This can happen if you send high packet rates across a multiplexed link, but quake shouldn't be generating packet quantities that could possibly break a well behaved one.

If you get a lot of red/yellow/blue in blocks, your game is screwed. If they only happen periodically then its probably ignorable, just annoying. The packet rate is high enough that a single dropped packet isn't an issue. The game will freeze any time more than 64 packets in a row are dropped, and entity deltas will be disabled until it recovers.
If you get periodic high pings, it means your connection is stalling periodically, buffering packets as it goes. This sucks, and feels worse than regular packet loss.

So yeah, for quakeworld, regular packet loss isn't a problem, the engine was basically designed to drop packets half the time (yellow bars). What'll mess over your game is inconsistant latencies.
Mere high latencies will just feel like regular non-quakeworld quake. :P

OMC, try infokey(foo, "pl"), but its not really useful except maybe for stats at the end of the match. Ping isn't that useful for a mod either.

When it comes to pings, bear in mind that NQ pings will be about a frame higher... I think?

Other games may show 'latency' rather than 'ping'. Its basically the same, but 'latency' does not include rendering time penalties and thus comes out a little lower. Its a pure-network ping that is not quite realistic in the real world, other than as a pure measure of ISP prowess.

Pings:
13 = localhost @ 72 fps
26 = nearby public server
70 = bad isp
100 = other side of europe
200 = western europe to eastern US
300 = satelite link
600 = aol.
3000 = the server is on the moon.
1530000 = the server is on mars.
57600000 = the server is on the voyager 1 spacecraft...