Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!leah!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!zog.cs.cmu.edu!tgl
From: tgl@zog.cs.cmu.edu (Tom Lane)
Newsgroups: news.software.nntp
Subject: RFC977 update should include TIME command
Summary: Need way to obtain server's clock value
Keywords: RFC977, timestamps
Message-ID: <5322@pt.cs.cmu.edu>
Date: 26 Jun 89 20:00:20 GMT
Organization: Carnegie-Mellon University, CS/RI
Lines: 44

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