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

Re: [reSIProcate] throughput restriction in UdpTransport and MacOS logging


On 6/3/06, Alan Hawrylyshen <alan@xxxxxxxxxxxx> wrote:

On 2006.06.03, at 15:00 , Bruce Lowekamp wrote:

> In UdpTransport::process() the code seems to be restricted to handling
> one incoming message and one outgoing message per call:
>   if (mTxFifo.messageAvailable() && fdset.readyToWrite(mFd))
> ...
>   if ( fdset.readyToRead(mFd) )
>
> any reason those shouldn't be while (foo) to process messages a bit
> faster?  I made the change in my version and it seems to work fine,
> and solves a problem we were having with excessive retransmits.
>
>

My concern here is that you could cause starvation; denying the other
threads (or sections) of the stack their slice of time.
If you do process more than a single message, it MUST be bounded so
it will exit after a finite amount of time, even in the presence of
excessive UDP load.

I see your point.  I don't know what a reasonable/universal value
would be here.  In our case I can be reasonably confident that I don't
need to worry about it, but hard coding in something like 20 would
probably work just as well for us, but seems ugly.

I know that Dum::process returns a bool indicating whether there are
more events to process.  I don't know how many people have a problem
like this, but if SipStack::process returned something similar
(filtering up from Transport::process), it would be fairly easy to fix
the problem at the app layer or wherever mStack.process() is being
called  (although that requires programmer effort to address the
problem).  Don't know if there was a reason Dum is written that way
but the stack isn't.

Bruce