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

[Andrei Pelinescu-Onciul]

On Jun 08, 2005 at 10:21, Samuel Osorio Calvo <samuel.osorio at nl.thalesgroup.com> wrote:
> 
> 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!!!!!!!!!


It would require only very little more memory, at least on systems that
use copy-on-write for forking (like linux for example). In this case all
the forked processes start sharing the same memory pages. Only when a
write occurs in some shared page, a copy of it would be created (=> more
physical memory allocated).  Besides on demand forking introduces
forking overhead, which while very small on some system (linux) cannot
be ignored (and can be quite high on other OSes).
Having on-demand forking and starting with let's say 50 children
wouldn't hurt, but I don't think it would introduce any major advantage
compared to starting directly with much more children. I think it would
be even a little slower when the forking starts.
Introducing this in ser has very very little priority right now.

> 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.

Actually if you fork or start a new thread when doing DNS lookups you
would not need async DNS.

I don't think async DNS would be doable with ser. It's very good when
you do not have a lot of state to save (e.g doing a http request, you
just retry the request when the dns answer comes), but not appropiate
for something like ser. 
I might be wrong, so if somebody has an ideea how this could work in
ser, please speak. Who knows, maybe besides my doubts we could find some
corner cases where we could use it.

Probably a better approach would be to cache all the DNS request in ser
(and cache even not resolvable addresses for a small time) and have a
small timeout for ser dns lookups. Even if the request will fail due to
the timeout the answer will arrive sometime in the future and at least
ser DNS cache would be updated. Future request (e.g. retransmissions)
might succeed.


Andrei