On Nov 2, 2007 at 2:42 AM Tomasz Sterna wrote: > I had started implementing asynchronous DNS resolving in jabberd, > to really fix problem of resolver timing out requests by accumulation. > > If there are 20 requests to process at the moment, and each takes 5 > seconds to resolve (default libresolv timeout), then with 30 seconds > request timeout (default jabberd timeout), resolver will process only 6 > first requests, with 14 failing with timeout when resolver didn't even > try to resolv it. > I tried to fix it by prolonging timeouts, but it hurts on the user > experience point of view - when a request takes more than 30 seconds to > finish, users tend to cancel it and retry. Answer after 5 mins of > waiting is not an option. > > So, the real solution is to implement asynchronous DNS resolving. > I'm going to use UDNS http://www.corpit.ru/mjt/udns.html library. > Is everyone OK with it?
I've never used a library for asynchronous DNS, but this one looks good to me. FYI Pidgin has two homegrown async DNS implementations, one forks child processes and talks to them with pipes, and one spawns threads. Using this library seems like a better idea than implementing either of those methods yourself. > And the second question arises. > With async DNS, we are able to ditch the whole resolver component > completely - s2s will be perfectly able to do the resolution by itself. > Resolver component was only needed to delegate the blocking DNS > resolution requests to another process. > I do see a use for resolver component in big, distributed deployments, > to do central name-resolution for all present s2s components. > But as for now, the resolver does only resolving. The name-2-address > mappings are cached... but in the s2s itself! > So, with the current design, we could move the resolution to s2s and > loose nothing. Or we could move the caching to resolver. > The s2s based resolving could also help in split-horizon DNS cases. > I personally am after the first option. Am I loosing something, or we > could just go with ditching the resolver? Getting rid of resolver seems like a good idea to me. If big, distributed deployments really want to do central name-resolution they could easily run a caching DNS server and have all DNS queries proxied through that. > And then, if we do left resolver behind, does it justify raising the > minor number of jabberd version. It sure is architectural change, and I > think we should release the ADNS branch under 2.2.x line. Raising the minor number sounds like a good idea to me. And it'll help people see that jabberd really is under active development. -Mark _______________________________________________ Jabberd2 mailing list [email protected] http://lists.xiaoka.com/listinfo.cgi/jabberd2-xiaoka.com
