On Mon, 6 May 2002, Garrett Wollman wrote:
> 1) Change the RFC 1323 implementation to use ticks relative to the > time the socket was created. This is fairly easy to do and requires > changes to only a handful of lines of code. (Keep in mind that only > timestamps we send over the network ought to be so treated -- the > timestamps stored in the TCPCB are a separate issue.) For additional > confusion value, consider adding a random bias when each connection is > created. (TCP already bogusly depends on a maximum segment lifetime > of 30 seconds, so segments dallying in the network for days are > probably not a concern. The correct answer for the user who has set > HZ to 1000000 is ``don't do that, then'' -- but this probably ought to > be documented as a limitation.) Is doing this wise? I have this nagging feeling that randomizing (or zeroing on each new connection) the timestamp would degrade its usefulness for PAWS checks and the like. (Don't ask me how, I haven't thought it through fully.) How about this idea: - For inbound connections, use 0 as the start value for the timestamp, as you suggest above. - For outbound connections, generate the timestamp offset using a hash similar to the one used for ISN generation. This way, timestamps won't jump around when connections are broken and reestablished / etc. This is a slight information leak; one can tell that the machine hasn't been rebooted. However, you would have to poll the machine quite often to figure out what the uptime really is. I think that the solution to wrapround with "ticks" is to normalize the value using hz to some known amount. I could certainly code these changes up (I've been thinking along the same lines for a while), but I'd be more than happy to defer to some unknown lurker on the mailing list who wants to make a name for his/her self. :) Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
