why does recv validate clock drift?
BrianHicks opened this issue · comments
in timestamp.js, recv validates that the received message has not drifted too far from the clock. I'm trying to reimplement this from the paper and your implementation and am running into a problem with this in the following situation:
- generate a timestamp in the present. The state of the clock is now up-to-date.
- receive an timestamp some time in the past. I'm just artificially subtracting two minutes worth of milliseconds to get this.
- it's a clock drift error!
It looks like this implementation will reject any remote messages further in the past than the maximum clock skew. If it doesn't, I don't actually see how! I also kinda see where they mention this check in the original paper but not why it has to be on receive.
So, am I missing something? Is this a bug, or a desired behavior for reasons I'm just not currently getting?
ahhhh, never mind… asking the question clarified it enough in my mind to see the bug in my implementation.
I was adding the offset to the current time instead of the previous timestamp. All good now. 😄
Thank you for making this implementation! It's really helpful for my understanding ❤️