tgl@zog.cs.cmu.edu (Tom Lane) (06/27/89)
Herewith a small suggestion for the next version of the NNTP RFC. (Possibly this has already been discussed, but I haven't heard about it.) At CMU we've been successfully using NNTP polling (passive send) with the NEWNEWS command, and a homebrew polling program at the far end. We've discovered a crucial flaw in the current RFC977 specification: there is no way for the client to discover the server's clock value, and thus no good way to determine the right cutoff time to specify in a NEWNEWS command. The client cannot simply assume that his own clock setting matches the server's; any skew provides a window for articles to be dropped. Our current solution is for the client to use its own clock time (at the start of the previous session), less 15 minutes, as the NEWNEWS cutoff time. This is ugly, results in considerable re-offering of articles (almost 50%, because we poll every half hour), and can still fail if the skew somehow is larger. I suggest that the next version of the RFC add a server command "TIME" (or GETTIME, or whatever) that instructs the server to return its current local clock time. The response might as well be formatted for direct consumption by NEWNEWS: time 2xx 890626 154350 if it worked right now. (One might also add the local timezone, e.g., EDT. This could be ignored by a client program.) A client using a polling protocol would then issue a TIME command just before NEWNEWS. On successful completion of the NEWNEWS session, the TIME result would be saved as the cutoff time to use in the next session. (If the session fails halfway through, the client would reuse the previous cutoff time, at no cost except some duplicate article ID offerings.) This method makes no assumptions about clock skew, and eliminates concerns about client vs. server timezone (presumably the issue that sparked inclusion of the GMT option in NEWNEWS). This method requires only that the server's clock be monotonic, which is necessary in any case. -- tom lane Internet: tgl@zog.cs.cmu.edu UUCP: <your favorite internet/arpanet gateway>!zog.cs.cmu.edu!tgl BITNET: tgl%zog.cs.cmu.edu@cmuccvma
fair@Apple.COM (Erik E. Fair) (06/27/89)
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