[reSIProcate] [PATCH] Add more and better salt values to callid computation

[Byron Campen]

	The kind of thing I would probably do is

Data
Helper::computeCallId()
{
    static Data hostname = DnsUtil::getLocalHostName();
    Data hostAndSalt(hostname + Random::getRandomHex(16));

#ifndef USE_SSL //!bwc! we don't need this code if we're using openssl
#if defined(__linux__) || defined(__APPLE__)
	pid_t pid=getpid();
    hostAndSalt.append((char*)(&pid),sizeof(pid));
#endif
#ifdef __APPLE__
	pthread_t thread=pthread_self();
    hostAndSalt.append((char*)(&thread),sizeof(thread));
#endif
#ifdef WIN32
	WindowsPidTypeWhateverThatMightBeIAmNotAWindowsPerson  
pid=::GetCurrentProcessId();
    hostAndSalt.append((char*)(&pid),sizeof(pid));
#endif //Of ifdef WIN32
#endif //Of ifndef USE_SSL
    return hostAndSalt.md5().base64encode(true);
}


Calling Data(int) does a int-to-string conversion, which is what I'm  
trying to avoid. Otherwise, this patch looks good, except for the  
windows pid type, but that is my fault :P

Best regards,
Byron Campen

>
> From: Byron Campen [mailto:bcampen at estacado.net]
> Sent: Tuesday, January 23, 2007 1:22 PM
> To: Aron Rosenberg
> Cc: resiprocate-devel at list.resiprocate.org
> Subject: Re: [reSIProcate] [PATCH] Add more and better salt values  
> to callid computation
>
>
>
>             We should determine whether openssl has this problem.  
> If it does not, we could avoid this extra work when we have  
> compiled with openssl. I do agree that we need to patch the code to  
> generate a longer sequence of hex digits (or, at the very least,  
> make it configurable).
>
>
>
> Anyone know off the top of their head whether openssl has this  
> reentrancy problem?
>
> OpenSSL does not have the concurrency problem. Their random number  
> functionality is available through <openssl/rand.h>, but that still  
> requires seeding and can have starvation issues if you request too  
> much data. On different platforms they make use of all sorts of  
> tricks including what I was doing above.
>
>
>
> Also, it would take a lot less CPU to just append the raw bits to  
> the hostAndSalt than to do an int-to-string(Data) conversion.
>
>
>
> Does this look a little cleaner / more efficient? If so, I will  
> submit a revised patch.
>
>
>
> Data
>
> Helper::computeCallId()
>
> {
>
>    static Data hostname = DnsUtil::getLocalHostName();
>
>    Data hostAndSalt(hostname + Random::getRandomHex(16));
>
> #if defined(__linux__) || defined(__APPLE__)
>
>    hostAndSalt += Data(getpid());
>
> #endif
>
> #ifdef __APPLE__
>
>    hostAndSalt += Data(pthread_self());
>
> #endif
>
> #ifdef WIN32
>
>    hostAndSalt += Data(::GetCurrentProcessId()) + Data 
> (::GetCurrentThreadId());
>
> #endif
>
>    return hostAndSalt.md5().base64encode(true);
>
> }
>
>
>
> Aron Rosenberg
>
> SightSpeed Inc.
>
> http://www.sightspeed.com
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070124/f3731ed2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070124/f3731ed2/attachment.bin>