Your efforts are appreciated.
Please see my additional responses inline below.
My single-threaded application requires that multiple connection attempts may be in-progress simultaneously, in conjunction with other activities that need timely attention. In other words, I need to have multiple connections in non-blocking SSL_connect() at the same time, with the application doing select() on all the LDAP connection sockets as needed. The fix you have provided will allow this?
What is the time-frame for this to be available in a "stable" version?
That's all for now,
--Larry Morris Interlink Networks, LLC. lrm@interlinknetworks.com
On Mon, 2007-01-08 at 08:39, Pierangelo Masarati wrote:
Is it an option for you to use Start TLS instead of ldaps? In this
I could try using ldap_start_tls() as a quick-and-dirty test to verify that you have fixed the connection issues, but it is not acceptable for our production use. We must support LDAPv2, which does not allow the use of start TLS.
Are you planning to support this for ldaps: URLs in the future?
Do you need/want me to verify that using start TLS with your patches fixes the connection issues? I would prefer to hold off until the ldaps: support is in place.
case, code in right HEAD should fix all non-blocking issues, as soon as you specify a network timeout and LDAP_OPT_CONNECT_ASYNC (undocumented yet, it's been committed just hours ago).
What is the "right HEAD" CVS branch? Do I have access to that branch via anonymous CVS? I am not very familiar with CVS, a sample command line to retrieve the correct sources would be quite helpful.
The usage I suggest is to set LDAP_OPT_NETWORK_TIMEOUT to a positive value; then set LDAP_OPT_CONNECT_ASYNC to TRUE before performing the first operation, and reset it to FALSE after the first operation succeeds. In your case, the first operation would be ldap_start_tls[_s](3).
Can I leave LDAP_OPT_CONNECT_ASYNC set to TRUE always? I would like referrals, if used, to be non-blocking as well.
Could you make this automatic in ldap_int_tls_start()?