Paul, I'm sure you're right.
I was highlighting the fact that UDP was used because the original post mentioned wanting to use TCP/IP for synchronization of clocks. Probably he didn't care whether or not it was TCP or UDP on top of IP that was the protocol for the job - hence the "finicky". Incidentally, a point I used to make in teaching ICMP (as part of IP management), ICMP operates at the same protocol level as UDP and TCP, namely directly on top of IP, and it would be possible to write a time-setting client based on the ICMP Timestamp/Timestamp Reply request. I know because I used this potential application as an exercise in C sockets writing and as a very - emphasis on the very - basic experiment to explore the issue of synchronizing time over a network. Your mention of "uncertainty of packet arrival time" reminded me of this little exercise. Chris Mason ----- Original Message ----- From: "Paul Gilmartin" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Thursday, 23 March, 2006 2:33 PM Subject: Re: Clock syncronization between platforms > In a recent note, Chris Mason said: > > > Date: Wed, 22 Mar 2006 03:44:26 +0100 > > > > Incidentally, both these servers use UDP rather than TCP - I know I'm being > > finicky :-) According to RFC 868, TCP is allowed for this "time > > synchronization function" but TIMED uses only UDP. > > > I suspect there's good motivation for preferring UDP. The complex > error recovery for TCP is likely to increase the uncertainty of > packet arrival time. > > -- gil > -- > StorageTek > INFORMATION made POWERFUL ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
