[Devel] CVS commitlog: sip-server/modules/tm mi.c

[Dan Pascu]

On Friday 15 December 2006 16:57, Bogdan-Andrei Iancu wrote:
> Hi Juha,
>
> Juha Heinanen wrote:
> >Stefan Sayer writes:
> > > but then the xmlrpc call would have to wait until final response
> > > (or timeout) of the request, which would not be desirable.
> >
> >you are correct.  getting final reply to invite could last tens of
> >seconds.
>
> yes, but we can cope with that if we have processes for each request -
> see my previous email.

This can lead to a very dangerous result. Simply flooding the proxy with 
INVITEs that never get any answer can start too many processes until the 
machine collapses. Forking is not a particularly efficient way to handle 
multiple requests given it's high overhead, but if that is combined with 
unlimited launching it can lead to nasty results.

I wonder why wasn't an event based mechanism chosen here? You use a select 
or poll based event loop and once you get a request you attach it to the 
event loop and add a callback and a timer. If you got the answer or the 
timer expired you return a reply on that specific channel and then remove 
it from the event loop. Much safer as it can handle much more active 
requests without crashing and burning and also much more efficient 
because it does all this in a single process without any forking and yet 
it doesn't block. All you need is a dedicated process with an event loop.

-- 
Dan