[reSIProcate] Timers: why system time?

[Byron Campen]

	So, maybe on win32 we need to have something call getTimeMs() every  
minute? A heartbeat timer of some sort?

Best regards,
Byron Campen

> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2482 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20081031/7fb2694e/attachment.bin>