[reSIProcate] Issue with getRandomHex()

[Yannick Guay]

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/20140501/4680161a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: randomness.patch
Type: application/octet-stream
Size: 769 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140501/4680161a/attachment.obj>