[ovs-dev] DNS support options

[Lance Richardson]

----- Original Message -----
> From: "Ben Pfaff" <blp at ovn.org>
> To: "Lance Richardson" <lrichard at redhat.com>
> Cc: dev at openvswitch.org
> Sent: Tuesday, August 8, 2017 4:49:52 PM
> Subject: Re: [ovs-dev] DNS support options
> 
> On Tue, Aug 08, 2017 at 04:16:21PM -0400, Lance Richardson wrote:
> > > From: "Ben Pfaff" <blp at ovn.org>
> > > To: "Lance Richardson" <lrichard at redhat.com>
> > > Cc: dev at openvswitch.org
> > > Sent: Tuesday, August 8, 2017 3:48:15 PM
> > > Subject: Re: [ovs-dev] DNS support options
> > > 
> > > On Tue, Aug 08, 2017 at 02:59:21PM -0400, Lance Richardson wrote:
> > > > > From: "Ben Pfaff" <blp at ovn.org>
> > > > > To: dev at openvswitch.org
> > > > > Sent: Tuesday, August 8, 2017 2:43:17 PM
> > > > > Subject: [ovs-dev] DNS support options
> > > > > 
> > > > > Open vSwitch currently supports only IP addresses for specifying
> > > > > OpenFlow and OVSDB remotes.  It would be nice to support DNS names.
> > > > > Open vSwitch can't afford to let DNS resolution block processing, so
> > > > > it
> > > > > needs some way to resolve DNS asynchronously.  I've come up with the
> > > > > following solutions so far:
> > > > > 
> > > > >         * Implement it ourselves using threads.  Probably, this would
> > > > >         be
> > > > >           a single worker thread that loops through calls to
> > > > >           getaddrinfo().
> > > > > 
> > > > >         * glibc has getaddrinfo_a(), an asynchronous version of
> > > > >           getaddrinfo().  *BSD and Windows do not have this function,
> > > > >           so
> > > > >           we would still need to implement it ourselves (probably
> > > > >           using
> > > > >           threads) if we adopted this approach, so it might be more
> > > > >           work
> > > > >           than the first solution.
> > > > > 
> > > > >         * Use an external asynchronous DNS library.  GNU adns looks
> > > > >         like
> > > > >           a good choice:
> > > > >           http://www.chiark.greenend.org.uk/~ian/adns/.
> > > > >           It has a port to Windows but I don't know whether it's
> > > > >           up-to-date.
> > > > > 
> > > > 
> > > > With adns_beforepoll()/adns_afterpoll(), it looks like adns might be
> > > > easy
> > > > to integrate on top of lib/poll-loop.c.  Not requiring a separate
> > > > thread
> > > > seems like a plus.
> > > 
> > > Oops, I just realized that adns is GPL'd, which means that linking it
> > > against OVS would force OVS to be GPL'd, so it's probably not a good
> > > choice.
> > > 
> > > Other possible choices:
> > > 
> > >         - c-ares (https://c-ares.haxx.se/).  Main disadvantage seems to
> > >           be that it's very "select" oriented.
> > > 
> > 
> > c-ares has an API to retrieve the set of socket descriptors that need to
> > be monitored for readability/writability, so integration shouldn't be much
> > work. A socket creation callback function can be registered as well, not
> > sure if it would be needed but it's nice that it's there. Looks like a
> > fairly active project with some contributors I recognize.
> 
> This API?  https://c-ares.haxx.se/ares_fds.html
> It seems inconvenient because it returns the fds as a fd_set, which the
> caller then has to scan for 1-bits.
> 
> This is however a fairly petty grievance if it's the only downside.
> 

I was looking at this one:

   https://c-ares.haxx.se/ares_getsock.html