[reSIProcate] [Fwd: Re: [reSIProcate-users] Helper::computeCallId returns the same value]

[Adam Roach]

As we've seen in the past, the Call-ID generation code that DUM uses 
(resip/stack/Helper.cxx:625 on head) can generate colliding Call-IDs 
under high-load conditions. The current code looks like this:

    Data
    Helper::computeCallId()
    {
       static Data hostname = DnsUtil::getLocalHostName();
       Data hostAndSalt(hostname + Random::getRandomHex(16));
    #ifndef USE_SSL // .bwc. None of this is neccessary 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
       DWORD proccessId = ::GetCurrentProcessId();
       DWORD threadId = ::GetCurrentThreadId();
       hostAndSalt.append((char*)&proccessId,sizeof(proccessId));
       hostAndSalt.append((char*)&threadId,sizeof(threadId));
    #endif
    #endif // of USE_SSL
       return hostAndSalt.md5().base64encode(true);
    }

I spoke to Byron just now, and he thinks the comment about "USE_SSL" is 
not accurate. (It would be if the code under getRandomHex() called into 
OpenSSL -- currently, it does not).

To help refresh memories, we've visited this problem in detail before, 
most recently here:

http://list.resiprocate.org/archive/resiprocate-devel/msg06605.html

The conclusion of that thread left me confused -- Alan demonstrated that 
we'll have collisions (albeit rarely) on just about any architecture, 
and that such collisions don't require multithreading to occur. From my 
read of things, Aron's problem (and Ilana's; see 
http://list.resiprocate.org/archive/resiprocate-users/msg00642.html) 
occurs more frequently than Alan's test program.

It seems to me that there are a few things we can do to try and address 
this:

   1. If we're using OpenSSL, make computeCallId call through to OpenSSL
      for its random numbers (there area a few paths to get there, so
      I'm just throwing out the general idea at this point).
   2. Remove the "#ifndef USE_SSL" guards from computeCallId() -- is
      this sufficent?
   3. Do #2, but also salt in a 32-bit thread-local serial number to
      prevent intra-thread collisions

Thoughts? (If no one expresses an opinion in a reasonable amount of 
time, I'll probably do #3).

[It occurs to me that we must have a similar problem with tags and 
branch IDs, albeit without any assert()s being triggered -- I would 
presume that any fix made to Call-ID should also be made to them as 
well, in Helper::computeUniqueBranch() and Helper::computeTag()]

/a
-------------- next part --------------
An embedded message was scrubbed...
From: Adam Roach <adam at nostrum.com>
Subject: Re: [reSIProcate-users] Helper::computeCallId returns the same value
Date: Mon, 13 Oct 2008 09:49:28 -0500
Size: 6438
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20081013/7ed720a0/attachment.eml>