tinyldap - a small LDAP implementation

What is it?

tinyldap is an attempt to write a very small and very fast LDAP server.
openldap is the reference when it
comes to LDAP servers, and it performs very poorly despite using
techniques such as thread pools.

The latest version is always available via anonymous CVS (which is the
recommended way to get the sources):

If you want to take part in tinyldap development, please subscribe
to the tinyldap mailing list (send an empty email to tinyldap-subscribe@fefe.de).

Recent News

[20150508] Several bugs related to error handling have been
fixed, at least one of which looks potentially exploitable. Please
upgrade!

[20060301] I'm still working on tinyldap. tinyldap has ACL
support now, a new index type (twice as large and twice as fast), the
client can parse RFC-style search expressions. The only thing missing
for a release is write support. I'm working on it.

Why?

I installed openldap and set up a slapd. I put in some 3000 records.
I asked for a specific record. It took 0.75 seconds on an otherwise
idle 1.3 GHz machine. That is absolutely unacceptable, even if slapd
does a sequential search. To prove that I wrote a small LDIF parser
that parses the same data in 0.02 seconds on the same hardware. Also,
openldap is far too heavyweight for my taste.

Adding an index to openldap made it much faster (7 seconds for 1000
queries), but a trivial tinyldap query implementation that does a
sequential search has about the same speed as that. I also wrote an
index module for tinyldap and it can now to 1000 queries in less than 1
second on the same hardware, although one new process is forked and
executed for each request.

Parsers are in scan_* style and
formatters are in fmt_*style like -lowfat.

Small and fast read-only "database" backend with indexing format

Small (11k uncompressed static binary on x86-linux) and fast (1000
EQUAL queries for one of 3000 records in less than one second on an 1.3
GHz Athlon, over 3000 separate TCP connections, using tcpserver). No tricks like file
descriptor passing, thread pools or cacheing are used (besides the
buffer cache from the operating system) read-only LDAP server.

About the database backend

I spent some time defining a trivial file format
for a generic text database with records and attributes where a record
can have multiple attributes of the same name. The database format
does not use compression but is nonetheless smaller than the LDIF source
file, even with two indices (at least for my test data, about 3000
records). The file format should be generic enough to be useful for
other purposes, too. One could, for example, write a simple SQL layer
on top of it.