[reSIProcate] Timers: why system time?

[Adam Roach]

To qualify things further, though: in order for this bug to be 
triggered, you would need to have no calls to "Timer::getTimeMs()" for 
over two minutes (131.07 seconds, to be more precise) as the 49.7-day 
boundary rolls around. In a normally operating SIP stack, the chances of 
this happening seem vanishingly small.

So, it's a corner case on top of a corner case. And it only happens on 
WIN32 systems.

/a

Byron Campen wrote:
>     Ok, so this is in the "much more serious" category. I would not be 
> comfortable leaving this be.
>
> Best regards,
> Byron Campen
>
>> Byron Campen wrote:
>>>    Let's say one of these timers is at the top of the heap, and 
>>> whatever error you're thinking about happens. Are you saying that 
>>> not only will that timer be 49 days late, but everything else in the 
>>> heap will be too?
>>
>> Not new timers. But, if we miss the rollover, then everything in the 
>> heap at that time will instantaneously appear to be 49.7 days later 
>> than their original expiration time. New timers will be inserted in 
>> the heap just fine (ahead of the "lost" timers), and expire correctly.
>>
>> The behavior would be similar to using our current stack and setting 
>> the system time to be 49 days in the past while timers are pending.
>>
>> /a
>>>
>>>
>>> Best regards,
>>> Byron Campen
>>>
>>>> Technically, they won't be "lost" as much as "over 49 days late." 
>>>> From a SIP protocol perspective, 49 days is long enough to consider 
>>>> the timer lost for all practical purposes.
>>>>
>>>> /a
>>>>
>>>> Byron Campen wrote:
>>>>>   I can see how we would miss a roll-over with low timer activity, 
>>>>> but I am not sure what you mean by "lose timers". If we have lost 
>>>>> a timer from a timer heap, that implies the heap is now broken, 
>>>>> because that is the only way to "lose" anything. So this is either 
>>>>> much more serious, or much less serious than you have stated.
>>>>>
>>>>> Best regards,
>>>>> Byron Campen
>>>>>
>>>>>> Scott (and any other Windows developers on the list):
>>>>>>
>>>>>> The Windows 49.7-day rollover fix in this patch uses heuristics 
>>>>>> to handle the rollover in an efficient manner -- you can actually 
>>>>>> lose timers if you have relatively low timer activity and a 
>>>>>> multi-minute timer running when the tick count rolls over.  The 
>>>>>> chances of this happening are, admittedly, vanishingly small 
>>>>>> (especially in normal SIP usage). In any case, you might want to 
>>>>>> give that code a quick review to ensure that you're comfortable 
>>>>>> with it.
>>>>>>
>>>>>> Also, I think it's safe to say that it's difficult to test the 
>>>>>> correctness of the code, as step one of any such test plan 
>>>>>> necessarily involves something like: "boot a Windows machine and 
>>>>>> wait 49.6 days." Make sure you're comfortable with that fact as 
>>>>>> well.
>>>>>>
>>>>>> /a
>>>>>>
>>>>>> Alexander wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Here is a patch to use monotonic clock.
>>>>>>> It is 3 modified files from reSIProcate 1.4.
>>>>>>> Attached files have Windows (CLRF) eof-style.
>>>>>>>
>>>>>>> Windows
>>>>>>> =======
>>>>>>>
>>>>>>> GetTickCount() with 16 ms inaccuracy used.
>>>>>>> It is very simple to change it to timeGetTime() etc with 1 ms 
>>>>>>> accuracy,
>>>>>>> but it will require init/fini calls on application level and 
>>>>>>> linking
>>>>>>> with Winmm.lib
>>>>>>> Tested on Windows XP SP2, compiled with VS7.1
>>>>>>>
>>>>>>> Not tested on Windows CE
>>>>>>>
>>>>>>> Linux
>>>>>>> =====
>>>>>>>
>>>>>>> If monotonic clock is not available (compile time and runtime) 
>>>>>>> it will
>>>>>>> fall back to gettimeofday()
>>>>>>> I am not familiar with reSIProcate build system so I use 
>>>>>>> workaround to
>>>>>>> avoid linking with librt:
>>>>>>> syscall( __NR_clock_gettime, ... )
>>>>>>> instead of clock_gettime(...)
>>>>>>>
>>>>>>> IMHO it may not work on other POSIX compliant platforms.
>>>>>>>
>>>>>>> Pass only some basic tests on my Linux PC (2.6.18 kernel)
>>>>>>>
>>>>>>> Any feedbacks appreciated.
>>>>>>>
>>>>>>> Regards
>>>>>>> Alexander Altshuler
>>>>>>> Xeepe team
>>>>>>> http://xeepe.com
>>>>>>> ------------------------------------------------------------------------ 
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> resiprocate-devel mailing list
>>>>>>> resiprocate-devel at resiprocate.org
>>>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>>
>>>>>> _______________________________________________
>>>>>> resiprocate-devel mailing list
>>>>>> resiprocate-devel at resiprocate.org
>>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>
>>>>
>>>
>>
>