RE: [reSIProcate] transaction id collisions
This Windows issue likely isn't your problem - but it got me looking at the
Random code again....
I ended up modifying the code in Random so that initialize is called per
thread in windows - by using a TLS (Windows Thread Local Storage) variable.
I will commit this change soon. With this change the code from ThreadIf can
(and will) be removed.
-----Original Message-----
From: Scott Godin
Sent: Thursday, June 02, 2005 4:17 PM
To: 'jason@xxxxxx'; david Butcher
Cc: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] transaction id collisions
Note: There is a call to srand in ThreadIf's threadwrapper routine - to
work around the Windows issue. But it is still a concern for windows
applications that are generating SipMessage's from multiple threads (not
created via ThreadIf). Such applications must be careful to call srand,
themselves for each thread. I suppose we could change code in Random.cxx to
initialize per thread (for Windows only?).
-----Original Message-----
From: Fischl jason [mailto:jason.fischl@xxxxxxxxx]
Sent: Thursday, June 02, 2005 2:54 PM
To: david Butcher
Cc: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] transaction id collisions
This behavior is windows specific.
On 6/2/05, david Butcher <david@xxxxxxxxxxxxxx> wrote:
> Quoting Scott Godin <slgodin@xxxxxxxxxxxx>:
>
> > By tid collisions, do you mean that resip is generating duplicate tids
for
> > different requests?
>
> Apparently. I have to instrument to prove it.
>
> > I've seen this behavior if you forget to call srand on every thread in
your
> > application that is creating requests. Even if you only use 1 thread,
when
> > you restart your app and you haven't called srand, it will use the same
> > tid's it used the last time you started.
>
> random()'s state is in thread data? if that is the case then
resip::Random's
> initialize strategy is broken -- it initializes as a singleton.
>
> thanks,
> david
>
> >
> >
> > -----Original Message-----
> > From: david Butcher [mailto:david@xxxxxxxxxxxxxx]
> > Sent: Wednesday, June 01, 2005 7:03 PM
> > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: [reSIProcate] transaction id collisions
> >
> > We're seeing transaction id collisions in a proxy built on a slightly
out of
> > date version of resiprocate.
> >
> > It seems that straight ahead random collision is extremely unlikely.
> >
> > Under what conditions can a transaction id collision occur? Some sort of
> > replay
> > attack? Can this cause an assert?
> >
> > david
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>