UDNS source code revision repository?

[Michael Tokarev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Replying to an old[ish] email...]

30.09.2013 11:27, Simon Josefsson wrote:
> Hi.  I'm evaluating async DNS libraries and I came across UDNS.  Are you still working on it?  Do you have any active plans for TCP support?  Would you accept patches to implement it, if I were to look into it?

Hello Simon.  Please excuse me for a very long delay with replying
to your query.

Not that I'm actively working on udns, it suits my needs for now,
and I don't really use its async capabilities anymore (I don't mess
with DNS nowadays as much as I did a few years back).

Speaking of TCP, -- this has been discussed a few times in the past
already.  The main question is not the implementation, that's just
details.  Tha main question is the interface (API) to use in the
async context.

Currently, it is very easy to integrate udns into a larger application
which uses one or another event loop or is select-based - the library
does not place almost any restrictions on the main event loop of the
application.  This is because it uses just one socket and just two
entry points (udns_timeouts() and udns_ioevent() functions) to be called
inside the event loop.

This is one of the key points of the library: to be easy to use in
an application.

When you introduce TCP, the library will have to create/destroy sockets,
maybe several for every query, and it is not exactly clear how to
integrate this changing sockets into an event loop.

Don't forget that event loops might be different.  For example, linux
provides epool-based mechanism - there, it is best to register i/o
handler right when the new socket is created, instead of trying to
construct set of filedescriptors to be watched right before next
call to select() or similar.  When we have just one filedescriptor,
an application can do this registration when it calls udns_init(),
once.  When the set of sockets is changing, it is not possible
anymore.

Maybe we can go with some sort of callbacks to register/deregister
the sockets, but it becomes quite a bit ugly and complex to use.

So, the main question is the right application interface (API),
the implementation is not a problem once the right way to use
the library in changing-sockets context is found.

On the other hand, more and more resolvers supports EDNS0, which
is also supported by the library, so the need to use TCP in the
first place desreases.

So may be it isn't really worth the effort to implement TCP in
udns?

I dunno.

Cc'ing the mailinglist.  Hope you don't mind...

Thanks,

/mjt

> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iJwEAQECAAYFAlLafJ4ACgkQUlPFrXTwyDhmDwP+MkwanhGsZJazHOq3KqqlCOHN
mOOfFqwwN4ttmhsCR8kpA9fVEEE05zycDyOot+TAFgAXKcXLR2QJxWNbLSk77xkx
BVyl+kAAN2/pHFJGJVJiKLC4vjX+wbfnZxzrf0CLnpiYbP0hGPqoIDPNMrfUvfix
pIW0oGV8tx3LtcRu/GU=
=zdon
-----END PGP SIGNATURE-----