Re: [ANN] lsocket - Another library for sockets in lua

[Sean Conner <sean@...>]

It was thus said that the Great William Ahern once stated:
> On Wed, Mar 27, 2013 at 06:23:41PM -0400, Sean Conner wrote:
> > It was thus said that the Great William Ahern once stated:
> > >
> > > IMO, a sockets library cannot be non-blocking if the DNS is blocking.
> > > Queries can often take several seconds to complete, or in some cases, never.
> > > If you're concurrently servicing 100 or 1000 open connections (or more!),
> > > blocking on DNS for 5 seconds, or just .5 seconds, is an absolute
> > > non-starter. I work at a networking appliance and "cloud" company, and this
> > > happens _all_ _the_ _time_, and almost invariably if the names aren't
> > > cached. Out-of-bailwick SOAs are the norm, and they dramatically increase
> > > resolution time.
> > > 
> > > I don't have the time to fix the Win32 build (it worked once-upon-a-time),
> > > but you can try with this library:
> > > 
> > > 	http://25thandclement.com/~william/projects/dns.c.html
> > 
> >   Another DNS library is SPCDNS [1].
> 
> Nice.
> 
> > It's primary purpose is to encode and decode DNS packets, which makes it
> > rather easy to integrate into a project with an existing network API
> > instead of it (poorly) handling the network activity. And it comes with
> > Lua bindings.
> > 
> 
> Are you implying that my library does network I/O poorly? ;)

  Well ... 

  True story.  At work, two developers (on two different projects) were both
trying to use an existing DNS resolving library (c-ares).  Both were having
major difficulty in getting it to work and it all came down to the network
code in the library.  Not only was it trying to do too much, but it didn't
mesh well with the existing network stack in the application.  

  I'm sure that c-ares would be fine for an application that wasn't so
network heavy as both projects (both in telephony [2]).  But with SPCDNS,
since it doesn't really handle the network portion of DNS, was much easier
to integrate into the projects (literally within a couple of days) since
they could integrate the DNS calls with the rest of the network stack in
place.

  What I've noticed (having looked at most of the existing DNS resolving
libraries) is that they tend to skimp on decoding DNS records (leaving most
of that up to the application) and go to extreme lengths in handling the
network side of the protocol.  SPCDNS took the opposite approach---handing
the DNS decoding [3] and leaving the network side to the application.

  -spc (There's something to be said about separating encoding/decoding and
	transports in protocols ... )

[1]	Footnote from a previous message

[2]	Telephony uses DNS for caller ID information.  

[3]	It handles 32 DNS record types---about 26 more types than other DNS
	resolving libraries.