On Jun 07, 2005 at 14:56, Samuel Osorio Calvo samuel.osorio@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