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

[Matthias Moetje - TERASENS GmbH]

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 at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] 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 at sipfoundry.org < svn at sipfoundry.org
<mailto:svn at sipfoundry.org> >
	Date: Apr 9, 2006 10:20 AM
	Subject: [reSIProcate-commit] COMMIT: resiprocate 6128 moetje:
Added STUN client support
	To: resiprocate-commit at list.sipfoundry.org 
	
	
Project	 resiprocate	
New Revision	 6128
<http://scm.sipfoundry.org/viewsvn/resiprocate?view=rev&rev=6128> 	
Committer	 moetje (Matthias Moetje)	
Date	 2006-04-09 10:20:40 -0700 (Sun, 09 Apr 2006)	

	Log

	 Added STUN client support
	 
	

	Modified:


	*	main/resip/stack/SipStack.cxx
<http://scm.sipfoundry.org/viewsvn/resiprocate/main/resip/stack/SipStack
.cxx?r1=6127&r2=6128&diff_format=l> 
	*	main/resip/stack/SipStack.hxx
<http://scm.sipfoundry.org/viewsvn/resiprocate/main/resip/stack/SipStack
.hxx?r1=6127&r2=6128&diff_format=l> 
	*	main/resip/stack/UdpTransport.cxx
<http://scm.sipfoundry.org/viewsvn/resiprocate/main/resip/stack/UdpTrans
port.cxx?r1=6127&r2=6128&diff_format=l> 
	*	main/resip/stack/UdpTransport.hxx
<http://scm.sipfoundry.org/viewsvn/resiprocate/main/resip/stack/UdpTrans
port.hxx?r1=6127&r2=6128&diff_format=l> 


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060410/8e0cceda/attachment.htm>