Re: A simple flow control scheme.

Ranga,

I have seen other cases where TCP outperformed UDP. This probably has to do 
with the fact that transactions live much shorter when using TCP, hence much 
less memory is used (because it is released sooner), hence less GC and 
better overall performance. Especially when running everything on only 1 
machine, the TCP overhead disappears and regular TCP flow control mechanisms 
don't kick in. Create a graph of memory usage (eg using jconsole) for both 
UDP and TCP and you will see

I also noticed the queue limiting code for UDP (with hardcoded low/hi 
watermark) , IMHO that's not a good idea. Suggestion to at least make it 
optional (off by default), and the low/high levels configurable.

Regards,
Jeroen

M. Rangnathan wrote:
> Hi folks,
>
> Noting that TCP outperforms UDP by a factor of 2 for
> test.load.concurrency, I added a mechansm to limit the size of  the
> client tranasaction table. Basically, if the mechanism is enabled (
> using the gov.nist.javax.sip.MAX_CLIENT_TRANSACTIONS property -- see
> SipStackImpl javadoc ), the caller blocks until the value falls below
> a threshold when you go to create a new client transaction. The
> danger is of course that if the caller blocks, that could lead to
> deadlock if the caller is not re-entrant. Thus this feature is "off"
> by default.
> I am still not able to match TCP performance or even imporove the
> performance using UDP no matter what I do with flow control  but
> perhaps somebody can look at that code ( see SIPTransactionStack.java
> ) and comment about better means of doing flow control for UDP.  In
> any case, this is a safety mechanism for servers to limit what the
> application can do ( i.e. if an application overwhelms the poor SIP
> Stack in a SLEE environment). If you are writing server applications
> of this kind (i.e. containers and whatnot where you expect third
> party code to run), it could be of interest to you.
>
> Regards,
>
> Ranga