[ENet-discuss] UDPX_TIME_OVERFLOW 86400000

[Lee Salzman]

Well, it's tricky. Take for example:

#define ENET_TIME_LESS(a, b) ((a) - (b) >= ENET_TIME_OVERFLOW)

With respect to this, I have to allow for a legitimate positive
difference to exist between "a" and "b", i.e. where "a" really occurs at
a greater time than "b". However, nowhere in ENet are any two values
compared where the difference between "a" and "b" is going to be greater 
than a day (just as some nice reasonable value, thus a day makes sense),
which happens to be 86,400,000 milliseconds. If there is a greater
difference than that, then a time overflow happened, in which case "a"
is really less than "b". This means ENet will never have year 3000 or
year 5 billion problems (if it is still around then), as it handily 
escapes rollover. :)

The overflow handling appeals to reasonable difference in time used
within ENet, not to any specific limit as to what can be stored in the
integer (so long as it is unsigned, anyway). Make sense?

Lee

On Mon, Feb 09, 2004 at 05:00:56PM -0000, Jim Purbrick wrote:
> What's the reasoning behind this value? I would have thought it would be
> ~4294967295 for a unsigned int wrapping clock.
> 
> The reason I ask is that I need to rewrite the clock using our WallClock
> time, which returns a double in seconds. In order to convert it to an ENet
> style millisecond clock I multiply by 1000, fmod with
> std::numeric_limits<int>::max() and then truncate to an integer.
> 
> Because I'm using integers, rather than unsigned ints, I expected to have to
> change the overflow value to ~2147483647, but the existing value of 86400000
> confused me.
>