Re: Adding caching to ldapd

Luis P. Caamano (
Wed, 12 Jul 95 13:19:27 EDT

First thanks a lot for your quick reply. You don't know how much I
appreciate that. My wishful thinking led me to believe that ldapd was
caching not realizing that the ldap_enable_cache subroutine was part of
libldap and hence the client. brainlock :) No biggie, I'm praying,
only that we are now running out of time on this prototype. :)

"Tim Howes" <> writes:
>> From: "Luis P. Caamano" <>
>> b) Would it be adding caching to ldapd a major change? That is, would
>> it be just adding some lines in ldapd's request.c and result.c to call
>> libdsap's local_find_entry, cache_entry, and the likes or would it need
>> an architecture redesign? Of course, it would include delete_cache in
>> modify.c and delete.c to flush updated entries.
> It's not major in concept, but the problem is that the dsap library is
> set up to do caching for read and list operations. ldap does not have
> those operations, emulating then both via search. So, the trick is to
> recognize in ldapd when somebody is doing a "read" (i.e., a base object
> search), and to use the cache. Similarly, if somebody's doing a "list"
> (i.e., a one-level search) one could recognize that and look in the cache.
> A compare should be pretty easy.

Yeap, I see what you mean. It would not make sense to look in the
cache for a search since local_find_entry takes a DN. Thanks for the

> Another tricky part is knowing when you've got all the attributes for
> an entry in the cache. In a simple approach, if I do a base object search
> asking for the objectClass attribute, recognize it, cache the result,
> and then do another base object search asking for the cn attribute, if
> I look in the cache I won't find it. So, you either need to intercept
> searches and ask for more than the user wants (which also means you need
> to separate the results sent back), or you need to be aware of what's
> in your cache, or make it a pass-through-on-failure kind of cache.

Uhhm, I was thinking about doing this in search_result

for ( e = sr->CSR_entries; e != NULLENTRYINFO; e = e->ent_next ) {


[ some appropriate place ]

if (all_attributes && all_values)
cache_entry(e, 1, 1);


where all_attributes and all_values are saved from the
ds_search_argument that ldap_search encoded in the request which is
somewhere in ldapd (I still haven't worked on where the request is,
perhaps I'd need to add flags to the struct msg that is passed to
search_result). In summary, only cache entries that we think have all
the attributes and values.

This is tricky, I agree 100% since my scheme above means that if
clients ask just for a few attributes, which is probably going to be
the case most of the time in our architecture, we'd practically have no

I'll have to consider your suggestions.

> Hope that helps. -- Tim

It does, especially from you.

Luis P. Caamano (LC2385) |
SecureWare, Inc. Atlanta, GA, USA | (404) 315-6296