> 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.
