Re: UDP Sockets & Clock Synchronization
Re: UDP Sockets & Clock Synchronization
- Subject: Re: UDP Sockets & Clock Synchronization
- From: Zack Morris <email@hidden>
- Date: Tue, 05 Mar 2002 23:33:15 -0700
on 2/28/02 9:06 AM, Zack Morris at email@hidden wrote:
>
> If the SO_TIMESTAMP option is enabled on a SOCK_DGRAM socket, the
>
> recvmsg() call will return a timestamp corresponding to when the
>
> datagram was received. The msg_control field in the msghdr structure
>
> points to a buffer that contains a cmsghdr structure followed by a
>
> struct timeval. The cmsghdr fields have the following values:
>
Wow, this could save my life! I've been talking to people about how I
>
thought sockets was flawed because without a time stamp, you can't do clock
>
synch for games (glad I'm wrong). Everyone's ideas about the separate
>
thread are good, except for OS 9. I looked into pthreads, and as far as I
>
can tell, they are cooperative, which I believe means they would only get
>
called at WaitNextEvent(), which is every 33 ms. There might be other OS
>
calls that yield to the thread manager, or most likely the GUSI calls like
>
recv do this automatically, but I would still only call them in one place in
>
the loop (every 33 ms). Can I get this time stamp information through GUSI?
>
If not, can I make a filter of some sort where I can intercept the message
>
in a notifier and tag a time stamp to it?
Hey, just wanted to let everyone know that the SO_TIMESTAMP option
worked perfectly! I haven't been able to test any latencies yet because I
have to get the clock synch code working. Then I need to make sure that I
get the same clock trying from both directions on the LAN and that the skew
is less than 30ms during game play (then comes modem tests...)
I was just wondering if anyone knew of similar time stamp code for OS 9.
I'd like to avoid asynch code if possible. You might all think I'm crazy
for this, but I'm going to get the rest of the sockets stuff working in 10,
and then "wrap" my old OT code in a subset of the sockets API. This is
mostly because sockets appears to be a higher level API to me (and I will be
able to talk to my partner in "sockets" since he is not versed in network
programming), but this might be a matter of opinion (yes, I know OT works on
both 9 and X) Plus, if we port to windows, most of the work will be done
for us ...except for the fact that recvmsg() doesn't exist in winsock
(sigh, there is always something). Please tell me I'm wrong about this...
If I could do all of this with simple nonblocking endpoints, it would
save me an infinite amount of grief. Once again, I'm still worried about
UDP timestamps...but UDP is easy enough to put in an asynch notifier if
worse comes to worse (and then atomically queue the packets). I have put
GUSI to the side for now because I don't know what latencies it has under
the hood and it does not seem all that hard to "port" the few sockets
routines that I need. Thank you all for your help,
Zack Morris
Z Sculpt Entertainment
email@hidden
http://www.zsculpt.com
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.