How often to ping?
Author
hi, in order to implement movement prediction i need to know the ping time every moment, don't i? So how often should i send the ping message? And what problems i might encounter? thanks
Don't use a traditional "ICMP ping", instead use a UDP packet in your protocol flagged as requesting a response.
Ideally these should be sent from the client to the server, so that the server knows it's still there; also you can calculate the round trip time. The server may need to know the ping times, so the client can just send the time from the previous one.
Ideally combine it with some other type of message to avoid wasting packets.
Mark
Ideally these should be sent from the client to the server, so that the server knows it's still there; also you can calculate the round trip time. The server may need to know the ping times, so the client can just send the time from the previous one.
Ideally combine it with some other type of message to avoid wasting packets.
Mark
Pasman,
All I've done in my client and server is store off the last time a reliable packet was transmitted, and when I receive the acknowledgement, I update the ping at that time. This happens to be done every server frame and every client frame (my two apps are sepearate and keep track of what they think they're own ping is to handle retransmissions) and is done with almost no overhead.
I add the time difference to an on-going variable which holds all the ping times added together. When I make a call to get ping I return ( totalPingTime / reliable ack ) * 0.80 to get the best 80% of my packets. My total ping time is a double and my reliable ack is an integer which bumps up by one for each new reliable message being sent out (not every retransmission). This seems to be working well and is done almost without any overhead at all.
Permafried-
All I've done in my client and server is store off the last time a reliable packet was transmitted, and when I receive the acknowledgement, I update the ping at that time. This happens to be done every server frame and every client frame (my two apps are sepearate and keep track of what they think they're own ping is to handle retransmissions) and is done with almost no overhead.
I add the time difference to an on-going variable which holds all the ping times added together. When I make a call to get ping I return ( totalPingTime / reliable ack ) * 0.80 to get the best 80% of my packets. My total ping time is a double and my reliable ack is an integer which bumps up by one for each new reliable message being sent out (not every retransmission). This seems to be working well and is done almost without any overhead at all.
Permafried-
My networking library uses the following heuristic: it pings one peer every 2 seconds, cycling through the list of peers. If there is only one other host, he gets pinged every 2 seconds. If there are 30 others, each one gets pinged once a minute.
There is a difference in unreliable packet pings (which measure actual network latency) and reliable packet pings (which may include one or more retries). However, this is a good thing, because for some calculations you want to know the raw ping time and for others you want to know how long a reliable operation may need to complete.
You can also timestamp regular packets that you know will generate an immediate response, and just make sure the response contains the send stamp and recv stamp. If you can do this, then just reset the "next ping" timer for the host -- depending on your traffic, you may not even have to send a separate ping at all.
Finally, you can try this page for a more detailed explanation.
There is a difference in unreliable packet pings (which measure actual network latency) and reliable packet pings (which may include one or more retries). However, this is a good thing, because for some calculations you want to know the raw ping time and for others you want to know how long a reliable operation may need to complete.
You can also timestamp regular packets that you know will generate an immediate response, and just make sure the response contains the send stamp and recv stamp. If you can do this, then just reset the "next ping" timer for the host -- depending on your traffic, you may not even have to send a separate ping at all.
Finally, you can try this page for a more detailed explanation.
I would overload ping time estimation with other data.
Thus, each packet sent contains a time stamp from that machine (say, in milliseconds) AND the last timestamp received from the other end. This makes it easy to detect ping on both sides, and you can use the time stamp for other things too (like packet ID for acks, or simulation pacing).
Thus, each packet sent contains a time stamp from that machine (say, in milliseconds) AND the last timestamp received from the other end. This makes it easy to detect ping on both sides, and you can use the time stamp for other things too (like packet ID for acks, or simulation pacing).
Author
ok...but i need the ping for movement prediction...and i need it 5 times a second...so i won't get any jumping at all...
If you send packets 5 times a second, and include the send time and the last-received time in each of those packets, then you can calculate the ping 5 times a second.
That being said, if you change your ping estimation wildly 5 times a second, things will be very jittery. You want the estimate to be fairly consistent. Each time you get a new estimate, you should smooth it with something like:
Also, if your movement packets have time stamps, then you should use the information from those time stamps to place the base of the interpolation. Ideally, all time stamps are measured in steps-since-start, with a fixed step size; that'll provide a very solid and robust foundation on which to base your prediction.
That being said, if you change your ping estimation wildly 5 times a second, things will be very jittery. You want the estimate to be fairly consistent. Each time you get a new estimate, you should smooth it with something like:
estimate = estimate * 0.9 + new_estimate * 0.1Also, if your movement packets have time stamps, then you should use the information from those time stamps to place the base of the interpolation. Ideally, all time stamps are measured in steps-since-start, with a fixed step size; that'll provide a very solid and robust foundation on which to base your prediction.
Author
ok...i think i've got that...but everything said here relies on the fact that both client and server have the same time...how is time handled? system time or an internal counter...but that would vary depending on computer hardware so i'd need to syncronize. I've looked into NTP but maybe i didn't get the whole problem right...wouldn't it work if i store on client side the difference between server's system time and client's system time and i'd resync that every n seconds. would this work?
No, it does not rely on the client and the server having the same time. Just read the suggestion, OK?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
