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 _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
