[Feature Analysis] Ping Measurement

Hey everyone.
I know how hard it is to code features when you don't have a packet sniffer and such. Not just that, I know that analyzing the packet sniff might be difficult for some who don't know how the data is used. Here's my packet log for sending ping:

Packet Log:
My Analysis:
The client sends an item action packet (1009) to the client every 10 seconds, requesting the ping response from the server (to make a round trip measurement). The response is just sending the packet back. You do not edit the time in the packet. This will result in an invalid reading when the client attempt to display the ping.

Picture:

Interesting read, keep it up.

I understand the whisper analysis, but this one had me raise an eye brow asking rusrs??
Every source released has ping implemented, it's not hard to figure out how it works even without a packet logger >__>;

Quote:

Originally Posted by InfamousNoone I understand the whisper analysis, but this one had me raise an eye brow asking rusrs?? Every source released has ping implemented, it's not hard to figure out how it works even without a packet logger >__>;

I did it because I don't trust the programmers here. They take shortcuts to "make things work". I was curious on whether or not you change the time in it, and nope - you don't. Thought I'd save people the time and thought and post my analysis about it.

Common sense would tell you that you don't change the time stamp.

Either way the first thing to logically try is echoing it back and then you go O_O IT WORKS and move on with your day.

And for those want the explanation, here's why:

Timestamps are typically signed with timeGetTime() this should be evident, because it's likely this is how you sign your timestamps in your server as this has become the norm in almost ever source. timeGetTime() is a function that is specific to a persons computer, it's not universal, there by meaning there's no way to predict the delta in the timeGetTime() of your computer, and someone elses (easily). Even if you didn't know this, one would usually assume a time-related value is specific to the computer doing the invoking.

So, we know the client sends the ping packet with a time stamp, and we know we have to send it back. Why would we alter the time stamp? The easiest way of calculating ping is simply signing a value (hence the ts) and finding out how long the trip takes by the server echoing it back, which is simply delta-time. By changing the value, delta time will give a "weird" value.

And lastly,
The client does not send it every 10s, it sends it ever 10s + the time to render a single frame; as well you should not make the assumption the server will receive it every 10s due to network latency.

Quote:

Originally Posted by InfamousNoone Common sense would tell you that you don't change the time stamp. Either way the first thing to logically try is echoing it back and then you go O_O IT WORKS and move on with your day. And for those want the explanation, here's why: Timestamps are typically signed with timeGetTime() this should be evident, because it's likely this is how you sign your timestamps in your server as this has become the norm in almost ever source. timeGetTime() is a function that is specific to a persons computer, it's not universal, there by meaning there's no way to predict the delta in the timeGetTime() of your computer, and someone elses (easily). Even if you didn't know this, one would usually assume a time-related value is specific to the computer doing the invoking. So, we know the client sends the ping packet with a time stamp, and we know we have to send it back. Why would we alter the time stamp? The easiest way of calculating ping is simply signing a value (hence the ts) and finding out how long the trip takes by the server echoing it back, which is simply delta-time. By changing the value, delta time will give a "weird" value. And lastly, The client does not send it every 10s, it sends it ever 10s + the time to render a single frame; as well you should not make the assumption the server will receive it every 10s due to network latency.

The server assigns the time does it not, using packet 1033? I thought that's why TQ introduced it (so the server and client times matched up to do checks like that). Anyways, you're right. A round trip makes more sense. I was just curious.

EDIT: you're right
time zones do matter
i shouldn't assume that tq knows how to properly code a server and client.

Good work bu can u give me a link for a logger and sniffer plz :)

Quote:

Originally Posted by hazemz Good work bu can u give me a link for a logger and sniffer plz :)

[Only registered and activated users can see links. Click Here To Register...] :)

Quote:

Originally Posted by Fаng The server assigns the time does it not, using packet 1033? I thought that's why TQ introduced it (so the server and client times matched up to do checks like that). Anyways, you're right. A round trip makes more sense. I was just curious. EDIT: you're right time zones do matter i shouldn't assume that tq knows how to properly code a server and client.

timeGetTime() is part of the WinAPI and can't be set. The only thing set by the packet 1033 is the date in the client. Not the timestamps.