Getting accurate timestamps for received datagrams
Getting accurate timestamps for received datagrams
- Subject: Getting accurate timestamps for received datagrams
- From: Thomas Tempelmann <email@hidden>
- Date: Fri, 27 Mar 2009 10:15:30 +0100
Background:I am still working on code to synchronize the clocks of two network-connected computers.
Each side tries to learn the time of the peer by repeatedly sending UDP datagrams containing its current time for the other to receive.
My software then uses a "smart" algorithm to compare the sender's times with its local receive times, learning the network travel time and guessing the actual time of its peer this way.
(Note: I can not use system-provided times that are sync'd over NTP, as these peers will be end-user computers and I cannot mess with their time settings. Also, their firewall might block such ports. All I have control over are is single open UDP/TCP port for my app.)
Now, for my algo to work,
I need to learn of incoming UDP datagrams ASAP, or learn of their receive time should the system provide me with that somehow.
It appears to me that the BSD and CF socket APIs do not tell me the time the datagrams were received, or do they?
Which leaves me to timestamp them myself once I learn of an incoming datagram.
So my big question is:
Which user-level UDP APIs are as immediate as possible when it comes to delivering incoming datagrams?
For instance, it seems to me that the CF API is polling-based, meaning that if the system is busy waiting for a response from a CD reading process or something else that makes the UI unresponsive, it'll also delay the forwarding of my incoming UDP packets, won't it? Or will a thread take care of that nontheless? Somehow I don't trust the CFRunLoops on this.
And what about BSD sockets. Would it work there? Which mechanisms would I have to use? I'm not familiar with using them. E.g, do I have to use the select() function for that that I've seen with other event-based loops? I'm not sure of its function. Kind of ugly, that whole API :)
--
Thomas Tempelmann,
http://www.tempel.org/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden