reSIProcate

Mailing Lists

Source Code

Google Search:



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

RE: [reSIProcate] Fwd: [reSIProcate-commit] COMMIT: resiprocate 6128moetje: Added STUN client support

Jason,
 
I had thought about both issues before and I had asked for comments
on this before I commited these changes.
 
Regarding the transport pointer: As long as you know that the lifetime
of this pointer is identical to that of the stack, nothing bad will ever
happen. Looking at the complexity of the stack and the expertise
required to find out how it is supposed to work and how to use it,
I'm not sure if especially this part would need to be made that "safe"
because low-skilled people will probably never be able to use the
stack anyway.
If someone creates his own transport class we already have a similar
situation: the custom transport's lifetime is controlled from outside
of the stack.
The only alternative that came to my mind was to send STUN messages
all the way through the stack same like SIP messages, but I'm not
sure if the amount of changes required to make this work really pays.
Of course I'm open for other alternatives!
 
 
Regarding the mutex: If we assume that each time the "process"
method is called, a single SIP message is processed, and if we compare
the amount of processing that is done on each SIP message, I don't
think that switching the mutex affects the processing time in a significant
way. Perhaps we could avoid the Lock object creation by switching
the mutex on and off manually?
 

Best regards,

Matthias Moetje


From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jason Fischl
Sent: Sunday, April 09, 2006 11:48 PM
To: resiprocate
Subject: [reSIProcate] Fwd: [reSIProcate-commit] COMMIT: resiprocate 6128moetje: Added STUN client support

I'd like to propose that we reconsider this particular interface change. It has a few implications that I am not sure are consistent with our design goals:

- exposes a pointer to a data structure that is not meant to be shared with the application
- requires a mutex to be used in every process call for the UdpTransport

I think we need to consider alternatives and am willing to spend some time this week to have a conference call to review alternatives.

Thanks,
Jason


---------- Forwarded message ----------
From: svn@xxxxxxxxxxxxxx < svn@xxxxxxxxxxxxxx>
Date: Apr 9, 2006 10:20 AM
Subject: [reSIProcate-commit] COMMIT: resiprocate 6128 moetje: Added STUN client support
To: resiprocate-commit@xxxxxxxxxxxxxxxxxxx

Project resiprocate
New Revision 6128
Committer moetje (Matthias Moetje)
Date 2006-04-09 10:20:40 -0700 (Sun, 09 Apr 2006)

Log

 Added STUN client support

Modified:


_______________________________________________
resiprocate-commit mailing list
resiprocate-commit@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-commit