ietf-nntp Section 11.5 - NEWNEWS

Jim Calvin jcalvin at ll.mit.edu
Fri Nov 17 11:02:50 PST 2000


<snip>

>  >
>  >I don't think we need to care if the server is out by several minutes
>>even, since it should not concern us. That is more than enough to work out
>>what the server's time zone is.
>>
>
>Why would anyone care what the server's time zone is?
>
>>The only command that cares about time is NEWNEWS.
>
>and NEWGROUPS
>
>>  If we ask for all
>>articles received on the server since 001116 031219, then what we actually
>>want is "all articles received since the last time I asked you, which was
>>at 001116 031219 according to my reckoning". The problem is that the time
>>quoted in the NEWNEWS came from the clock on MY machine, and the server
>>will respond according to the clock on ITS machine. So both machines need
>>to be accurate for perfect performance.
>
>Exactly.  Which is why servers SHOULD be accurate.
>
>>  A more realistic solution would be
>>for people to include an overlap (a few minutes) in the time they give in
>>the NEWNEWS command, since it does little harm if a few duplicate
>>Message-IDs are received.
>>
>>Maybe there should be a NOTE to suggest exactly that.
>>
>
>This is good defensive client behaviour to deal with servers' inaccurate
>clocks - but it does not justify servers' having inaccurate clocks.

It'd be nice if servers were all accurate, but that doesn't deal with 
drift between clients and servers. A better way for a client to 
behave is something like the following:

[C] DATE
[S] 111 yyyymmddhhmmss
[C] NEWGROUPS <previously remembered date and time>

The client should remembers the result of the DATE command to use on 
the next NEWGROUPS command. Then the client can't be wrong. Drift 
between systems isn't an issues, etc.
-- 
Jim



More information about the ietf-nntp mailing list