For those who may be interested, I have made the first release of my
port
of perl’s Net::DNS library to Ruby. The project is called pnet-dns, and
can be found here :
This project is a direct port from the perl, warts and all. Any perl
code
using the library can be ported quickly and easily to Ruby. All the perl
tests have been ported and run successfully (from perl Net::DNS version
0.57).
Just a quick RTFM question : is it only a client or is it also
possible to build a server with it ?
It is primarily a client. However, with some work, it would be possible
to
build a server from it.
It is a direct port from perl, so is best suited to code that folk are
porting from perl, rather than new design work in Ruby. It’s pretty
“perlish”!
I am looking at implementing a new Ruby DNS library, dnsruby ( http://rubyforge.org/projects/dnsruby/), but this is still some time
away.
This library will be much closer to the Java DNS library ( www.dnsjava.org), which is a nicer, more OO library. Instead of being a
direct port (folk wanting to use dnsjava can always run in JRuby), it
will
be a rubified version, which should be much nicer to work with.
While I appreciate the effort, I’m curious why you didn’t join Marco
Ceresa’s project instead of creating your own project.
Marco had agreed to take my code during this summer, while I was still
developing. Once I had finished, Marco then decided that he wanted to
renew development of his Net::DNS project, but in a new, Ruby direction.
Rather than throw away the finished perl port, it seemed better to
release
it, for those that want a perl port.
I also wonder if
creating yet another DNS library (dnsruby) is really a good idea (too
many choices). Would a dnsruby really any better in practice? Why
not just refactor pnet-dns to incorporate the best of dnsjava?
pnet-dns is a direct port of a perl library. The “refactor” of which you
speak is essentially a complete rewrite. I propose to make the rewrite a
separate project, as it targeting separate needs (those who would like a
port of a perl library, to aid in porting code which uses it, versus
those
who want a “real” Ruby DNS library).
While I appreciate the effort, I’m curious why you didn’t join
Marco C.'s project instead of creating your own project. I
also wonder if creating yet another DNS library (dnsruby) is really
a good idea (too many choices). Would a dnsruby really any better in practice? Why not just refactor pnet-dns to incorporate the
best of dnsjava?
I’m curious how all of these options differ from the standard resolv
library?
I’m curious how all of these options differ from the standard resolv
library?
I’m also curious if any of these options solve the DNS latency problem
that
kills performance in programs that fire off a large number of
connections to
network servers. (I know libcurl has a partial solution to this
problem.)
tests have been ported and run successfully (from perl Net::DNS version
0.57).
While I appreciate the effort, I’m curious why you didn’t join Marco
Ceresa’s project instead of creating your own project. I also wonder if
creating yet another DNS library (dnsruby) is really a good idea (too
many choices). Would a dnsruby really any better in practice? Why
not just refactor pnet-dns to incorporate the best of dnsjava?
I’m also curious if any of these options solve the DNS latency problem
that
kills performance in programs that fire off a large number of
connections to
network servers. (I know libcurl has a partial solution to this
problem.)
I don’t know of the latency problem of which you speak. I have run my
non-blocking Java DNS library (dnsjnio) with tens of thousands of
concurrent connections to nameservers, with no issues.
I’m talking about blocking DNS requests. I’ve wanted to add a
nonblocking
DNS client to the EventMachine library for some time, but haven’t gotten
around to it yet.
pnet-dns can run non-blocking requests (using an ugly perl API).
Out of curiosity, why does your Java product run DNS over TCP instead of
UDP?
I don’t know of the latency problem of which you speak. I have run my
non-blocking Java DNS library (dnsjnio) with tens of thousands of
concurrent connections to nameservers, with no issues.
I’m talking about blocking DNS requests. I’ve wanted to add a
nonblocking
DNS client to the EventMachine library for some time, but haven’t gotten
around to it yet.
Out of curiosity, why does your Java product run DNS over TCP instead of
UDP?
but it will hardly give you performance (just now)…
I need an asynchronous client that I can add to EventMachine, so I need
pure
Ruby or C/C++. If you want to discuss further, we should take it
off-list to
avoid boring everyone else
I need an asynchronous client that I can add to EventMachine, so I need
pure
Ruby or C/C++. If you want to discuss further, we should take it
off-list to
avoid boring everyone else
I’ve looked at EventMachine, and was impressed with it. I’d be very
happy
if you were able to use some of my code with it. pnet-dns is available
now, but is very ugly, being a direct port of a perl project (and a
badly
implemented perl project, at that). dnsruby will be available in the
next
few months, but will be a real DNS library, based on dnsjava.
pnet-dns is pure Ruby, and dnsruby will be as well. I have had to make
use
of the Socket class for TCP (I need to control the source port), which I
believe may be implementation-dependent. However, I know that it runs
fine
on Windows, Linux and Solaris.
I’m going to model dnsruby on dnsjava, as dnsjava is the best and most
mature OO API for DNS that I know. However, the non-blocking API will be
much closer to the dnsjnio project.
My dnsjnio project streams all requests over a single socket, and runs
them all in a single thread. This allows me to do massive amounts of DNS
requests concurrently. I will be implementing this approach for dnsruby.
Unfortunately (well, fortunately for me!) I’m off for a three week
honeymoon in a fortnight, returning just before Xmas. So I’m unlikely to
get too much dnsruby implemented in the immediate future!