           SPELL=udns
         VERSION=0.4
          SOURCE="${SPELL}-${VERSION}.tar.gz"
   SOURCE_URL[0]=http://www.corpit.ru/mjt/${SPELL}/${SOURCE}
     SOURCE_HASH=sha512:2990d57b3b6bf176a12ee07fd4391921e13634fc8409e8ce4df8dbe7b3556a116ae59ab328a1b6a95ebc94298f6b56ec7197a06a649d8d642b371b8ecef3e40b
SOURCE_DIRECTORY="${BUILD_DIRECTORY}/${SPELL}-${VERSION}"
        WEB_SITE="http://www.corpit.ru/mjt/udns.html"
      LICENSE[0]=LGPL
         ENTERED=20090101
           SHORT="UDNS is a stub DNS resolver library."
cat << EOF
UDNS is a stub DNS resolver library with ability to perform both syncronous
and asyncronous DNS queries.

Easy to use and asyncronous DNS resolver is a problem for a very long
time. Standard libresolv from Berkeley Internet Name Daemon (BIND)
distribution, included in most Unix-like operating systems, is good for
syncronous A (AAAA) and PTR lookups. Other DNS Resource Record (RR) types (such
as MX, TXT and so on) requires parsing of raw DNS packets at the application
level, which isn't a trivial task and requires good knowlege of DNS protocols
and packet structure. While it is possible to add such interfaces to use for
other RR types to standard resolv library, it's main problem remains: it is
not asyncronous. Most applications that requires asyncronous DNS processing
either implements their own resolver modules (which, again, is not a trivial
task, and sometimes leads to incompatibilities with other resolver libraries
and bugs which are difficult to find), or uses forked-resolver model, where
separate process is forked just to perform DNS queries, which requires quite
some resources, especially when an application already have some sort of event
loop in place to multiplex I/O. Asyncronous DNS resolver is a must for many
nowadays applications, such as GUI (GUI-application should not stop processing
user interface events while performing DNS queries), high-performance servers
(such as mail servers) using event-loop model (see for example an excellent
"The C10K problem" page at kegel.com describing various methods to handle
many client requests in parallel).
EOF
