LDAP timeouts during failure conditions

[Alan DeKok]

John Dennis wrote:
> Glad to see someone tackling the LDAP code. This comment is beyond the
> connection issue, but from working with rlm_ldap in the past it seemed
> to me the implementation was a bit "crufty", probably the result of
> incremental evolution by multiple parties over time (no criticism, just
> an observation). I kinda think it might be worthwhile to start with a
> clean slate, write down the requirements for the module and write it
> cleanly from scratch to match the requirements.

  I'd welcome that.

> Now here is the silly egregious part of this comment I have to apologize
> for, while I could technically do the work or contribute to it (I work
> in a group dedicated to identity/authentication solutions based on LDAP,
> Kerberos & PKI) I am so swamped with work at the moment I couldn't
> volunteer, sorry :-(

  Like most people.

> Perhaps a bit off topic for this discussion, but I always thought it was
> dubious to have special code for a specific LDAP server in FreeRADIUS. I
> wonder if it should be removed and just stick with the standardized LDAP
> API.  If there was a strong argument for server specific logic perhaps
> LDAP should follow the SQL model with a generic LDAP module and driver
> specific sub-modules.

  Possibly.  But eDir has weird requirements on getting clear-text
passwords.

> Sorry, forgot who said this in the last couple of days, but they
> endorsed the event loop driven asynchronous model.

  The server is largely already event driven.  All of the socket code is
based around even loops.  All of the request processing in 3.0 is event
(and state-machine) driven.

  The main concern I have about adding more event loop code is lock
contention.  Many DBs don't expose an event API.  So when they lock,
they lock the entire server.  The only way to avoid that is to use child
threads.  Then, the child threads need to update a global event queue,
meaning that there is lock contention.

  And where do you stop?  It makes sense to have a flat code path
through the "process modules" section.  There isn't much need to do
anything event based on a per module basis.

> After working for
> many years on a variety of servers I too have come to believe event loop
> driven architectures are superior in contrast to forking children,
> spawning threads, etc. Anything we've written recently follows the event
> loop model. It's not perfect by any means but it gets rid of a lot of
> nasty problems and IMHO the resulting code simplier and easier to
> understand, which means less bugs. It's too big a change for FreeRADIUS
> but I thought I would at least endorse the previous comment.

  I think it wouldn't be hard to do.  Much of it is already there.  The
question is only how far can you go down that path.

  Alan DeKok.