Ian Puleston wrote:
Hi,
Some time back I implemented an OpenLDAP-based LDAP client in a network
appliance that uses code based on the tools for LDAP searches etc. I used the tool code because it gave me a nice easy LDIF-based API, but the downside was that each search operation was totally synchronous, so I'm now working on updating it to support asynchronous searches.
I have a daemon task that listens for replies from the server after a
request is set, and that then calls ldap_result, ldap_parse_result, etc. - basically all the things that ldap_do_search does synchronously. The daemon task, being ouside of OpenLDAP, gets the socket to listen on for each request via ldap_get_option with LDAP_OPT_SOCKBUF. This is working well.
The problem is when new connections are opened when a referral/reference is
followed. In this case the daemon needs to listen for replies on these too, but there is no way that I can see to get at its socket from outside the OpenLDAP core.
LDAP_OPT_SOCKBUF gets the socket for the primary connection and there is no
equivalent mechanism to get the sockets for the referral connections.
What I've had to do is to add a new LDAP_OPT_REF_SOCKBUFS in my local
OpenLDAP code to return a list of the socket buffers for additional connections opened for referrals.
I am using an oldish version - 2.3.32 so:
- am I missing any alternate way to get these sockets to listen on?
Yes. Turn off automatic referral chasing and take care of referrals in your own code, then you always have access to every socket.
- has anything been added in more recent versions that will help with this?
Yes, look at LDAP_OPT_CONNECT_CB in 2.4. You can set a callback that is invoked right after a connection is opened and right after it's closed. Your callback function gets the sockbuf as one of the parameters.
- if not would this new option LDAP_OPT_REF_SOCKBUFS be a useful addition? If so I could submit it via the bug reporting.
No, I don't think it's needed.