Has anyone tried to do time sync over 3g? <br><br>I'm trying to synchronize an iphone game where one client is wifi and another is over 3g. I think the problem is that one direction of travel is faster than the other<br>
<br>ex.<br>client sends time-request packet to server<br>server stamps and responds<br>client takes the last send time, current time, figures out the <b>average</b> latency and adjusts the time to predict where the server is right now<br>
<br>the client seems to always be a little bit off though and I think it's because the sending and receiving speed / packet delays are different. This would mean the client is <i>always</i> over or under compensating. <br>
<br>Does anyone have any insights on this? It's for a real-time game so the clock really does need to be sync'd to a high precision<br><br>thanks in advance,<br clear="all">--<br>Bill Kouretsos<br>tel \ 647.477.3817<br>
<a href="http://littleguygames.com">littleguygames.com</a><br>
<br><br><div class="gmail_quote">On Wed, Mar 3, 2010 at 1:58 AM, Syed Setia Pernama <span dir="ltr"><<a href="mailto:syedhs@yahoo.com">syedhs@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yes this is a common 'challenge' in network game. The best link I have so far is this: <a href="http://www.mine-control.com/zack/timesync/timesync.html" target="_blank">http://www.mine-control.com/zack/timesync/timesync.html</a><br>
<br>
The algorithm from the article:-<br>
<br>
1. Client stamps current local time on a "time request" packet and<br>
sends to server<br>
2. Upon receipt by server, server stamps server-time and returns<br>
3. Upon receipt by client, client subtracts current time from sent time and divides by two to compute latency. It subtracts current time from<br>
server time to determine client-server time delta and adds in the<br>
half-latency to get the correct clock delta.<br>
(So far this algothim is very similar to SNTP)<br>
4. The first result should immediately be used to update the clock<br>
since it will get the local clock into at least the right ballpark (at<br>
least the right timezone!)<br>
5. The client repeats steps 1 through 3 five or more times, pausing a<br>
few seconds each time. Other traffic may be allowed in the interim, but should be minimized for best results<br>
6. The results of the packet receipts are accumulated and sorted in<br>
lowest-latency to highest-latency order. The median latency is<br>
determined by picking the mid-point sample from this ordered list.<br>
7. All samples above approximately 1 standard-deviation from the median are discarded and the remaining samples are averaged using an<br>
arithmetic mean.<br>
<div class="im"><br>
<br>
----- Original Message ----<br>
From: Alexander Shyrokov <<a href="mailto:sj@sjcomp.com">sj@sjcomp.com</a>><br>
To: <a href="mailto:enet-discuss@cubik.org">enet-discuss@cubik.org</a><br>
Sent: Wed, March 3, 2010 6:41:51 AM<br>
Subject: [ENet-discuss] Time synchronization client/server/client communication.<br>
<br>
Hello,<br>
<br>
I have multiple clients connected to the server. The server echos the received data from any single client to the rest of the clients. I would like to know the time when a packet is sent by the original client. How do I do that? It is clearly a very common situation in games. I get position of a player with the velocity. Given that some time elapsed since the packet was sent I can estimate current position by using elapsed time and the velocity to get the offset.<br>
<br>
<br>
<br>
</div><div><div></div><div class="h5">_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
</div></div></blockquote></div><br>