[reSIProcate] Issue with getRandomHex()

[Scott Godin]

Hi Yannick,

Thanks for keeping us posted about your findings.  I'm still baffled why
others aren't seeing this, when your test platforms are pretty standard.
 Out of curiosity - does rutil/test/testRandomHex show that there is a
uniqueness issue?

Daniel Pocock - Have you seen anything like this on your *nix platforms?

Scott


On Fri, May 9, 2014 at 2:17 PM, Yannick Guay <yannick.guay at gmail.com> wrote:

> Hi Scott,
>
> I made more testing recently, trying to isolating the problem a little
> more. The first thing I tried was to execute the same set of tests on a
> different platform (Debian 6.0.6 64bit) and I'm seeing the exact same
> problem.
>
> I will conduct more testing next week and, as well, I will try the patch I
> suggested last week on Debian. In the interim please let me know if you
> have any comments.
>
> FWIW: our system will be deployed on ESXI so all tests are conducted on
> VMWare, not bare metal.
>
> best regards,
> -Yannick Guay
>
>
>
> 2014-05-01 10:45 GMT-04:00 Yannick Guay <yannick.guay at gmail.com>:
>
> Hi again,
>>
>> A colleague here pointed me at another API which I tried (srand48 and
>> lrand48, also part of standard library) and that seems to work better for
>> me. The replacements exist on all modern Unix platforms (Solaris, Mac OS X,
>> FreeBSD, Linux).
>>
>> Although Evan Jones describes this as not being thread safe (read this
>> post here <http://www.evanjones.ca/random-thread-safe.html>), this could
>> be a good starting point to work around the issue. I have only tested my
>> scenario where the DUM is generating new transaction id and I've had
>> success with it. I believe that's because all request for random numbers is
>> coming from a single thread.
>>
>> I'm aware that not everybody is suffering of this but I'm confident it's
>> solving a real issue so I'm posting the patch for review. Perhaps we should
>> confirm whether it is safe to use by running a wider range of tests?
>>
>> thanks,
>> -Yannick
>>
>>
>> 2014-05-01 8:48 GMT-04:00 Yannick Guay <yannick.guay at gmail.com>:
>>
>> Hi Scott,
>>>
>>> We've started using 1.9 as of  last week on Centos 6.3. I've tested the
>>> Random class separately and made it issue 20 8 byte long values without a
>>> problem, I can hardly identify what could cause this? I will keep
>>> investigating on my side and would be very thankful if anybody can give any
>>> sort of recommendation on how to get that fixed.
>>>
>>> thanks,
>>> -Yannick
>>>
>>>
>>> 2014-04-30 17:02 GMT-04:00 Scott Godin <sgodin at sipspectrum.com>:
>>>
>>> Hi Yannick,
>>>>
>>>> What resip release are you using?  There was quite a bit of work put
>>>> into the Random.cxx class a couple years ago to ensure random number
>>>> generator is seeded automatically for each thread (see
>>>> Random::initialize()).  If you are on an older release you may want to
>>>> compare your version Random.cxx with the latest one from SVN.  Note also -
>>>> there is a lot of platform depend code branches in this init logic, so your
>>>> platform may be playing a role here.  What platform are you using?
>>>>
>>>> Scott
>>>>
>>>>
>>>> On Wed, Apr 30, 2014 at 3:50 PM, Yannick Guay <yannick.guay at gmail.com>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I ran into an issue with DUM generating same transaction id several
>>>>> times when my b2bua is handling multiple simultaneous calls.
>>>>>
>>>>> I'm using DialogUsageManager::makeInviteSession() which generates a
>>>>> proper branch parameter for the outgoing call but when it's time to send
>>>>> them down to the stack the branch parameter is set again
>>>>> by DialogUsageManager::send() (line 1036 or so), but same value gets reused
>>>>> for all calls. As a result, only the first call gets out of my gateway, all
>>>>> other subsequent calls are considered bad and eventually get dropped by
>>>>> TransactionState.
>>>>>
>>>>> Here is the line that I'm finding in log files.
>>>>> 2014-04-30T15:12:27.854-04:00 Warning - B2BUA TU sent us a duplicate
>>>>> INVITE: fix this!
>>>>>
>>>>> My knowledge of srandom and random is rather limited but I trust after
>>>>> giving it a seed, then it should always hand off unique values?
>>>>>
>>>>> Any Ideas what I'm doing wrong?
>>>>>
>>>>> Best Regards,
>>>>> -Yannick Guay
>>>>>
>>>>> _______________________________________________
>>>>> resiprocate-devel mailing list
>>>>> resiprocate-devel at resiprocate.org
>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140510/300e40b5/attachment.htm>