Click to See Complete Forum and Search --> : Using Winsock to connect to Atomic Clock


BWThorp
June 21st, 1999, 10:46 AM
I would like to write some code to connect to the Atomic clock in Boulder, CO. I have been unable to figure out how to do this. Does anyone have a snippet of code that could get me started? Any help would be greatly appreciated.

BWThorp
June 21st, 1999, 12:09 PM
I tried using CSocket but was unable to retrieve any data. I don't know if I have to do anything special for the port number. Any help would be greatly appreciated.

Jerry Coffin
June 21st, 1999, 12:49 PM
First a warning: if you're connecting via the net, you'll get large and quite unpredictable delays in recieving your reply -- typically on the order of 100 ms, and sometimes more.

There are a couple of RFCs covering connecting to a time server -- RFC 868 gives results to the second. Given that you can't depend on results being much better than that anyway, you may want to use this. It's certainly simpler than the newer ones that allow better resolution in the result you receive. I'll be happy to email source code to retrieve the time from an RFC 868 server and use it to set the system clock under NT if you want it.

If you want to try for more resolution, RFC 1305 attempts to provide it. This is intended to be run full-time to keep clocks in synch with each other. It _attempts_ to compensate for network delays, though I'm not convinced that it's entirely sucessful even at best. This is fairly difficult to implement, and is only really applicable if you have a full-time dedicated connection, not something like a dial-up connection.

The final possibility of which I'm aware is SNTP, RFC 1361. This is a simplified version of RFC 1305 intended purely for clients. It uses the same timestamp format, but quite a few of the fields are more or less ignored.

IIRC, the time server in Boulder implements all of these RFCs, as well as a couple of obsolescent ones such as 959. Of course, there are LOTS of other time servers as well, most of which implement most (if not all) of these as well.

In my experience, if you can find a time-server closer to home, you're likely to get better results from it than going to Boulder -- I even live in Colorado, and connections to Boulder are quite direct for me, but they're still less dependable and accurate than connecting to HP's time-server here in town. I'd also note that in most cases, the physical distance to the server matters less than the number of links involved. However, if you can find something like a local university that uses the same backbone provider(s) as your ISP, chances are it'll give you far better results than connecting to Boulder (unless you're actually in Boulder, and on an ISP that uses the same backbone provider as they do, of course...)


The universe is a figment of its own imagination.