Help with connecting to NIST NTP server on port 123

Question

I can get NIST time in Daytime format using the rt_nist_date_time.llb example posted on ni.com, but I cannot connect to NIST NTP format time data using port 123.  I freely admit to being over my head with this stuff, and have spent much of this Thanksgiving holiday reading about UDP and TCP.
The attached vi summarizes what I've tried so far.  The UDP case is what I thought would work, but I can't come up with a network address that the UDP-open vi likes.  Can anyone out there help this n00b tell the time?
The attached file is supposed to be in 8.0 format, although I'm working in 9.0
Here is a link discussing the time formats: http://tf.nist.gov/service/its.htm 
Jeff 
Solved!
Go to Solution.
Attachments:
UDP.vi ‏17 KB

Answer 1

jstevens wrote:
THANK YOU!!!  I don't think I ever would have come up with connecting the web address to a Read or Write UDP rather than the Open UDP block.  Not to mention starting by opening port zero.
Unlike TCP, UDP is a connectionless protocol. Here's a quick explanation in different words.
A udp packet travels from a [sourceIP, sourcePort] to a [DestinationIP, destinationPort].
UDP open basically reserves a local port used for sending (soucePort) and receiving (incoming packet with that same destinationPort). Since some local ports are always in use, you would generate an error if you would accidentally pick a used port. Picking zero is useful for requests (as in this case!), because the OS will pick an unused ephemeral port. The actual source port number does not matter because the NTP server will just send the reply packet back to whatever port it came from. (If you would write your own NTP server in LabVIEW, you would of course need to set the local port to 123, and would get a conflict if another NTP server is already running on your rig). Writing an NTP server in LabVIEW would be a trivial modification to the current code, try it! . Simply listen for packets on port 123, form a response packet based on the timestamp, and send it to whatever IP/Port it came from (that info is available from udp read) and then go back to listen for new requests.).
UDP write sends a packet to the server using the above opened local port as source port. You can use the same connectionID to write to several other servers and ports, because UDP is connectionless. (TCP is connection based, so a TCP connection involves a defined source/destination pair)
UDP read listens for incoming packets from all over the world at that same local port. It is very unlikely, but theoretically possible that other UDP packets will arrive at that same port, so you could even filter to make sure to read incoming packets until they match the port and IP of the original request. The current code is somewhat vulnerable to a DOS (denial of service) attack for example as follows: Imagine the guy in the next cubicle had means of sniffing your network traffic. He could write a small program that looks for your NTP requests and then immediately starts flooding your IP with meaningless UDP packets to the sourcePort you just used. The current program only reads one packet and thus will never see the return packet from the NTP server.
UDP close frees up the local port and the computer is now no longer listening for packets on that port. Of course you could keep the port open for the duration of the program, especially if you intend to send UDP request once in a while during execution.
Makes sense?
LabVIEW Champion . Do more with less code and in less time .