Language choice [was Re: Symlinks]

Dominic Marks dominic_marks at
Tue Feb 12 18:58:24 GMT 2002


On Tue, Feb 12, 2002 at 04:32:37PM +0000, Rik wrote:
> Hi all,
> Just thought I'd drop in my hapennys-worth about the design ideas I've
> had so far...
> Well, I know some people won't like this, but I'm going to write my DNS
> server in C, and be careful of strings and sizes of binary data. Indeed,
> I will probably be passing size_t's around.
> The architecture will/may be something like:
> Master Process:
>   Starts up any processes in hard-coded watch directory whose
>   executables have appeared since the last check interval, or last
>   recieved SIGCHLD.
>   When a SIGCHLD is recieved, work out which child process died, reap
>   it, and start up a new one.
> TCP/UDP Listener:
>   Listens to a port and accepts connections. When a new connection
>   appears, accept it, and attach it to the stdin and stdout of a
>   proccess that deals with the data 1 line (~= packet in this case) at a
>   time. Multiplex the data.
> Child Processes:
>   These would actually handle the protocol for each section. These would
>   be, eg a recursive resolver, an authoritative server, a zone transfer
>   server, and so forth.
> Well, that's *basically* how djbdns does things now. Possible
> modifications include combining the TCP/UDP Listener with the Child
> Processes, to avoid the fork()/exec() overhead. I'm currently (as I
> type), thinking that I'd like to do that, and bring in a single threaded

I have been researching this field extensively and certainly from
looking at applications like thttpd and the like using a single
application with non-blocking IO and a good system for reacting to
software events (as exists in kevent) seems to be provide the best
performance in terms of throughput, latency, and concurrency.

> kqueue/kevent (for FreeBSD, poll() for those that have it, select() for
> those that don't have poll()) loop with nonblocking sockets.
> There's a few other things I'm thinking about, now people have started
> me thinking again (see what you started when you asked about wu-ftpd,
> whoever it was!)
> Uhm. Hm. Anyone wanna banter on IRC? #DeNSe on

I'm there too btw.

My idea for the lookup method.

1, a cache of premade DNS responses which is held in memory, only the
most frequently requested data is stored here, and items in this cache
get the best performance, the size of this cache is configurable.

2, items not stored in the primary cache are found from working with a
djbdns file type layout. In memory we store the offsets of sections
which we use the jump to the right locations in the file rather than
store the information in memory. This would get pretty good
performance because the searching is done in memory and once the
correct offset is computed you only need to do a single read of this
file. It also has quite modest memory requirements, and the offsets
can be computed in a single pass on start up or on reception of a

Im still learning about how mmap works but if my understanding
is correct it is possible to mmap a file such that portions of the
file when used could be read into memory and so these areas would see
an improvement in performance.

Id appreciate comments and criticisms as I am a student with much
learning to do.

> rik
> -- 
> PGP Key: D2729A3F - Keyserver: - rich at rdrose dot org
> Key fingerprint = 5EB1 4C63 9FAD D87B 854C  3DED 1408 ED77 D272 9A3F
> Public key also encoded with outguess on
> ------ FreeBSD UK Users' Group  -  Mailing List ------


More information about the Ukfreebsd mailing list