Re: Overlays and OpenLDAP multi-threading model

[masarati@aero.polimi.it]

> Hi
>
>> Now I understand a bit more of your question.  OpenLDAP does not work as
>> I
>> presume you imagined.  There is one thread that listens for requests.
>>  As
>> soon as a request is received, an operation structure is created, and
>> queued for execution.  As soon as one thread is available from a thread
>> pool, the first operation in the queue is executed.  So threads *do not*
>> accept connections (a connection is a persistent channel between the
>> client and the server; a connection is not related to a thread).  A
>> specific thread accepts requests (a request is mapped onto an
>> operation),
>> and each operation is executed by a different thread.
>
> Thanks for your explanation. But, is this operation structure also
> points (or stores)
> connection related data like the binding DN and it's credentials
> (password) ? If
> so, do you can point me in which structure member it is stored ? The
> overlay
> has to have those informations...

The Operaton structure points to the Connection structure (op->o_conn,
which is actually a macro that expands to op->o_hdr->oh_conn); it also
contains copies of data that could be modified.  For example, the DN the
connection is bound as is in op->o_dn (pretty) and op->o_ndn (normalized).
 It is a copy, because the operation could modify it (e.g. via the proxied
authorization control).  The original value is in op->o_conn->c_ndn.  Of
course credentials are not stored; actually, slapd should have no notion
of how the client bound after the bind succeeds, except for what type of
mechanism was used, and the related ssf.

>> If your overlay takes a lot of time, in principle it will only affect
>> its
>> operation.  If the client is performing multiple operations
>> concurrently,
>> only that operation will be delayed.  Of course, if all operations use
>> your overlay, and all operations of your overlay take a lot of time, at
>> some point all the threads of the pool will be busy.  Further requests
>> will be accepted by the listener thread, but they will be queued until
>> one
>> thread of the pool is available.
>
> Great! So the overall performance of OpenLDAP won't be compromised, once
> the overlay will only act over modifications operations of one
> attribute (userPassword).

Your overlay can access the password during a simple bind operation.  It
is in op->orb_cred.

p.