| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
In windows…. If you are using resip
0.9 or earlier – you must make sure that you seed each thread
independently. This is fixed in SVN head. You shouldn’t be ending up with so
many tid collisions if you follow the above rule. Scott From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx]
On Behalf Of Robert Mansfield All, I've read through the previous correspondance on this issue
and am hoping someone can clarify the best practice for a multithreaded
application on widows. In particular the use of the 'Random' class for
generating unique transaction ids. I'm running two windows applications on seperate hosts, one
acting as a UAC, the other a UAS. There are 60 simumtaneous dialogs being
created. During load testing I submit a BYE request to the stack
but the stack doesn't transmit the message to the wire, claiming the
transaction id already exists in the transaction map. The application has two threads, one processing SIP messages
from the stack (g_SipStack->receive()) and the
other thread sending messages to the stack
(g_SipStack->send(sipMessage). The stack object is global to both threads,
but only one thread is responsible for creating and submitting SIP requests. On the UAC side I have seen a duplicate transaction ids
submitted to the TransactionManager from the application, typically a BYE
is discarded because the tid has been used for an ACK from a different dialog. In the creation of both the ACK and the BYE message
the 'via' header branch parameter is instantiated with a call to "via.param(p_branch)". In this particular stack trace instance the transaction id
appears to have been added from a received response, here is a fragment from
the stack trace: #################################################################################################################### DEBUG | 20051221-152514.156 | RT-SIP-00-19-07-5.bb.cc.dd.exe
| RESIP | 1940 | SipStack.cxx:375 | RECV: SipResp: 200 tid=8664a730b52dc246
cseq=INVITE contact=RedwoodDevEngC1P18@xxxxxxxxxx
/ 1 from(wire) DEBUG | 20051221-152521.562 | RT-SIP-00-19-07-5.bb.cc.dd.exe
| RESIP | 1196 | SipStack.cxx:269 | SEND: SipReq: BYE RedwoodDevEngC1P21@xxxxxxxxxx
tid=8664a730b52dc246 cseq=BYE / 2 from(tu) STACK | 20051221-152522.281 | RT-SIP-00-19-07-5.bb.cc.dd.exe
| RESIP:TRANSACTION | 1940 | TransactionState.cxx:155 | Found matching
transaction for SipReq: BYE RedwoodDevEngC1P21@xxxxxxxxxx
tid=8664a730b52dc246 cseq=BYE / 2 from(tu) -> tid=8664a730b52dc246 [
ClientStale/Terminated unreliable target=[ V4 0.0.0.0:0 UNKNOWN_TRANSPORT
connectionId=0 ]] To: <sip:P335544401223@xxxxxxxxxx>;tag=3c6fe50d From: <sip:DNX_TESTC2P8@xxxxxxxxxx>;tag=9b540c2f Via: SIP/2.0/UDP
10.0.0.212:5060;branch=z9hG4bK-d87543-8664a730b52dc246-1--d87543-;rport Call-ID: 4767b466384e6543@UmVkVk9JUA.. CSeq: 2 BYE Content-Length: 0 ##################################################################################################################### So I guess I have two questions: a) if two resiprocate applications are running back to back
would a received tid (generated remotely for dialog A) confuse the stack
when submitting a request with the same tid generated locally for dialog B
(branch parameter unique across space and time)? b) just how random is the tid generated via the Random
class. Should I expect so many 'duplicates' after running just one
iteration of the test? Regards, Rob Mansfield. ============================ Robert
Mansfield Senior
Software Engineer Redwood
Technologies Limited Tel +[44]
(0)1344 304 344 Fax +[44]
(0)1344 304 345 E:mail mailto:rjm@xxxxxxxxxxxxxxx Web http://www.redwoodtech.com ============================ Email
Disclaimer The
information in this email is confidential and may be legally privileged. It is
intended solely for the addressee. Access to this email by anyone else is
unauthorised. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it is
prohibited and may be unlawful. When addressed to our clients any opinions or
advice contained in this email are subject to the limitations of Redwood
Technologies Limited's standard terms and conditions of contract. |