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?
- has anything been added in more recent versions that will help with this?
- if not would this new option LDAP_OPT_REF_SOCKBUFS be a useful addition? If so I could submit it via the bug reporting.
Ian
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.
-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Friday, January 28, 2011 1:20 AM
- 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.
Thanks Howard,
I'm looking at upgrading our OpenLDAP port to 2.4.23 so I can make use of this, but in doing it I think I spotted a bug with this new callback.
In function ldap_connect_to_host are two calls to . The first for "#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP )" looks OK, but the 2nd for the #else case of that is this:
i = ldap_int_connect_cbs( ld, sb, &s, srv, (struct sockaddr *)&sin ); if ( i ) rc = i; else break;
But this is inside a for loop that uses i as a counter for the loop control. ldap_int_connect_cbs returns an error code so, unless I'm missing something, setting i to that will break the loop control.
Shall I put in a bug report for this?
Ian
Ian Puleston wrote:
Thanks Howard,
I'm looking at upgrading our OpenLDAP port to 2.4.23 so I can make use of this, but in doing it I think I spotted a bug with this new callback.
In function ldap_connect_to_host are two calls to . The first for "#if defined( HAVE_GETADDRINFO )&& defined( HAVE_INET_NTOP )" looks OK, but the 2nd for the #else case of that is this:
i = ldap_int_connect_cbs( ld, sb,&s, srv, (struct sockaddr *)&sin ); if ( i ) rc = i; else break;But this is inside a for loop that uses i as a counter for the loop control. ldap_int_connect_cbs returns an error code so, unless I'm missing something, setting i to that will break the loop control.
Shall I put in a bug report for this?
Please do, thanks.
openldap-technical@openldap.org
-
Howard Chu -
Ian Puleston