Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!fair
From: fair@Apple.COM (Erik E. Fair)
Newsgroups: news.software.nntp
Subject: Re: RFC977 update should include TIME command
Message-ID: <32688@apple.Apple.COM>
Date: 26 Jun 89 23:53:38 GMT
References: <5322@pt.cs.cmu.edu>
Organization: USENET Protocol Police, Western Gateway Division
Lines: 28

Actually, I was thinking of requiring every NNTP site to run NTP
(Network Time Protocol) along side NNTP (since the protocol name is a
proper substring of NNTP, why not? Also, I think that Dave Mills does
neat work). That way we don't have to modify NNTP at all because all
the servers will be synced to the nearest millisecond of UTC. Nothing
like using a thermonuclear device to kill a mosquito.

Of course, the nntpxfer program could also query the remote NNTP server
with TCP or UDP time protocol to determine clock skew naturally, you'll
have to account for round-trip time in transmitting that timestamp. You
can get one-shot NTP timestamps with that problem already taken care
of. But then I suppose that would force people from other network
environments (e.g. DECNET, AppleTalk, DataKit, OSI) to have network
time protocols in order to have netnews. Dear me.

If all else fails, you can just do what you suggested, and burn a
little more CPU by asking for a little more than you want of the past.
I don't think that an hour lag would be that bad; after all, DBM is
fast, and the incremental amount of network traffic is small.

What I think I'm trying to say is that I think that the problem is
external to NNTP, and adding yet another way to get the time over the
network would not be a good idea (there are already four or five). Is
it so unreasonable to expect that when your computer says that it's
midnight, that it really is? This problem will go away when NTP is
released, which will be moderately soon.

	Erik E. Fair    apple!fair      fair@apple.com