[Serusers] Re: [Serdev] ENUM issues - req. for discussion#

[Samuel Osorio Calvo]

Then I see it would take too much effort to add an asynchronous resolver, but I don't think the lack of memory is the right answer: your proposal of using 500 children is more memory demanding than forking, isn't it? You can just add a configuration variable, max_fork=500 and with , for instance, children=3 your deployment will require much less memory than just children=500!!!!!!!!!
Nevertheless, for simplicity (in the sense of less points of failure and a more stable system) it is better to stay with the "common" resolver.

Samuel.


Unclassified.
>>> Andrei Pelinescu-Onciul <andrei at iptel.org> 06/07/05 04:49PM >>>
On Jun 07, 2005 at 14:56, Samuel Osorio Calvo <samuel.osorio at nl.thalesgroup..com> wrote:
> >If DNS is slow, or misconfigured (e.g. a zone is delegated to a 
> >nameserver which is down), the thread will be blocked for several 
> >seconds. E.g. if you use debian woody and 2 nameservers in 
> >/etc/resolv.conf, the timeout is 20 seconds. If you are lucky, the OS 
> >allows configuration of the DNS timeouts. Nevertheless, you have to 
> >consider that a ser thread will be blocked up to 20 seconds. This has 
> >impacts on your configuration:
> 
> I don't know the details but would it be really difficult to use an asyncrhonous resolver, such as resiprocate SIP stack does with ARES?? Besides exec_* calls, the main SER's performance bottelneck is the DNS resolving step thus it would be a great improvement adding asyncronous DNS queries.


Using asynchronous dns would work as long as you have memory to save the
state of the pending dns request. It could be easily attacked in the
same way (lots of DNS requests that will take a long time to resolve =>
out of memory => no more messages processed).
Besides using it would mean saving the complete state of the message and
of the ser processing of the message in the moment the dns request was
made. For example if you make a dns request in module foo, function
bar() you should be able to continue from exactly the same point in
exactly the same state, when you receive the reply. This would mean
something equivalent to saving the whole call trace (the whole stack for
that matter) and a lot of global variables.
The ammount of complexity involved in converting ser to such a model
(where such a detailed state is saved that it makes possible resuming
processing at a later time) would be huge. I don't think this would be
doable in finite time :-)

As an alternative one could fork threads (which would save all the
information involved except all the global vars.), or new processes
(which would save everything). However in this case we would deal with
the forking overhead. This can be attacked too (turning ser into a
fork bomb).
I think it's much better to start ser with lots of children processes
(let's say 500, or the maximum acceptable for your machine configuration).

So, I don't think async. dns would be a solution.

[...]


Andrei