Re: [reSIProcate] Mapping SipMessage to TransactionState
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?
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)
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?
Thanks in advance
Sandeep
On Tue, 2005-09-13 at 13:08 -0700, Jason Fischl wrote:
> On 9/13/05, Sandeep Sharma <ssharma@xxxxxxxxxx> wrote:
> > Hello,
> >
> > Thanks for the explanation. On further testing, I find that under a load
> > test, I always end up with a scenario when the transaction id is
> > repeated. An example: A SUBSCRIBE was sent, it was assigned a
> > transaction id (getRandomHex()), and stored in transaction map. While we
> > are still waiting for the response for this (after about 12 seconds),
> > another message, (say INVITE) gets allocated the same transaction id as
> > the earlier SUBSCRIBE causing all sorts of asserts.
> >
> > So I am seeing strong evidence that the getRandomHex() is not returning
> > "unique" values, which is against the intended behavior as per my
> > understanding of the stuff. It always seems to happen under load test.
> >
> > Before I dig more into it, I would like to ask if anyone has seen this
> > sort of issue. Anything I could be missing at the application layer? I
> > am not using DUM, using version of resiprocate from April. I am calling
> > reset() on the branch parameter on the Via header of all my messages.
>
> Can you please provide an ethereal trace showing the behavior.
--
Sandeep Sharma <ssharma@xxxxxxxxxx>