https://bugs.openldap.org/show_bug.cgi?id=9244
--- Comment #4 from Ondřej Kuzník ondra@mistotebe.net --- On Sun, May 10, 2020 at 06:12:44PM +0000, openldap-its@openldap.org wrote:
Other patches by the same author are similar workarounds to issues that shouldn't happen - need to identify and fix the root cause. The changes to avoid sockets being set to blocking should all be unnecessary, because none of them should be reached until after the connection is established. (For example, I think ldap_int_start_tls shouldn't need to consider the async setting at all, only the timeout.)
Not sure I agree, but see note around the end for more context.
ldap_int_check_async_open doesn't check the network timeout. The code that _does_ check it can't be reached before the connection is established, so as far as I can tell, the connect timeout is currently just ignored when async.
Yes, we could adjust ldap_int_check_async_open() to check whether the network timeout has been reached yet and mark it as error.
ldap_send_initial_request calls ldap_int_check_async_open(ld_defconn). But when chasing a referral, that's a different connection! Again, Linux masks this bug by returning EAGAIN, but on Solaris 10 I can see that the referral connection sends its Bind too early and gets ENOTCONN. That one should be an easy fix.
Yes, referral chasing doesn't mesh well with async in many ways. The subconnection setup is questionable when it comes to TLS, calling ldap_start_tls_s as well.
A few more notes:
ldap_connect_to_host() behaviour changes when async is on, the getaddrinfo result list is lost as we return on LDAP_X_CONNECTING.
Our implementation doesn't seem to have a way of handling happy eyeballs either.
Overall, running with async would need a lot of context to be maintained across calls that just isn't being done and either the application assumes a lot of control over e.g. referrals and other smarts or it won't get (reliable) async management.