< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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
>