SourceForge has been redesigned. Learn more.
Close

#46 Allow replacement for async dns resolver

API
open
nobody
General (24)
5
2010-07-18
2010-07-18
No

Our evdns code is okay, but some people want more from a resolver than we currently offer. This is no longer just a simple matter of saying "So don't use evdns if you don't want it," since some of our functions (bufferevent_connect_hostname) now use evdns where available, and others (listener_create_by_hostname, if we make it) might start doing it in the future.

It might be neat to allow a drop-in replacement to be used instead of evdns_getaddrinfo. It's probably something to do at the event_base level.

Alternatively, we could turn evdns into the very best nonblocking resolver code in the world. But do we truly want to maintain a dnssec implementation?

Discussion

  • Nick Mathewson

    Nick Mathewson - 2010-07-18

    To be specific: some drop-in replacements people might conceivably want are:
    c-ares (nonblocking support requires weird APIs that only sorta work with libevent)
    ldns (no apparent nonblocking support)
    Your Platform's Resolver In A Threat Pool.

     
  • Nick Mathewson

    Nick Mathewson - 2010-07-18

    Errr, that's a "Thread Pool", not a "Threat Pool"