Sign in to follow this  
pasman

How often to ping?

Recommended Posts

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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-

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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:


estimate = estimate * 0.9 + new_estimate * 0.1


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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this