Re: [reSIProcate] Mapping SipMessage to TransactionState
Here are the machine details of the two machines under test:
Machine 1
Processor: Pentium 3
Speed: 700 MHz
OS: RH Enterprise Linux 3.0
Machine 2
Processor: Pentium 3
Speed: 700 MHz
OS: RH Linux 9
Both are running resiprocate stack, and talking to each other sending
SUBSCRIBE, NOTIFY, INVITE etc.
One thing to note is that I have a version of resiprocate from April. In
that version, when I run "configure" gives the following error: "
configure:1556: error: cannot find install-sh or install.sh
in . ./.. ./../..". But when I do make after this, it works fine so I
did not spend time to look at the cause of this error. I am too close to
a release to upgrade to 0.9.0 and go through the test cycle.
Thanks
Sandeep
On Sat, 2005-09-17 at 16:46 +0200, Alan Hawrylyshen wrote:
> On 17-Sep-05, at 01:45 , Sandeep Sharma wrote:
>
> > Hi,
> >
> > I figured a way to solve the transaction id mapping issue. I
> > changed the
> > code in BranchParameter to call getCryptoRandomHex() instead of
> > getRandomHex() and also changed the calls in Helper.cxx for computing
> > callid and tag to use cryptorandom, and saw the asserts disappear.
> >
> > What I concluded is that you cannot guarantee unique transaction ids
> > using random(), but using the openssl RAND functions is much better in
> > that regard. Any comments?
> >
>
>
> Yes, you will get more entropy, but at the expense of your entropy
> pool. When getCryptoRandom runs out of entropy, it will typically
> wait for more, assuring that you get high entropy randomness. This
> will cause problems in high performance systems as the stack will
> block waiting for more entropy. If you happen to have an atomic or
> reliable high-entropy source (most of us do not) your approach is
> mathematically better. On fast, high volume systems using crypto
> random can be a real problem. I've seen order of magnitude slow-downs
> and this is why we were using the other random interface.
>
> > Earlier I would see assert in 10 minutes consistently, now I have run
> > fore more than an hour and have not seen the assert. (duplicate
> > transaction id)
> >
>
> On what platform are you seeing this? (OS, Processor Type and Speed)
> I have done a LARGE amount of testing with resiprocate and not had a
> self-generated tid collision in many billions of messages.
>
> > Question: Is it common to tinker with the timer values in os/
> > Timers.cxx?
> > Basically I doubled all the timers since I was seeing timeout (408)
> > getting generated under load and the response would arrive after the
> > timeout. So the timer for SUBSCRIBE now is 64 seconds instead of
> > 32. Can
> > these be changed from the application code (at run time) or they
> > have to
> > be hardcoded in the Timers.cxx file?
> >
>
>
> Common to tinker? Not sure, but you can just set them. They are
> global variables (ugh) and they are referenced as the timers are
> created so changing them will affect only subsequent transactions.
>
>
> Alan Hawrylyshen
> reSIProcate Project Administrator
> http://sipfoundry.org/reSIProcate/
> a l a n a t j a s o m i d o t c o m
>
--
Sandeep Sharma <ssharma@xxxxxxxxxx>