Re: Bugfix: wait4msg() hangs when using SSL/TLS (ITS#446)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:05 AM 3/21/00 +0000, Andrew Hacking wrote:
>"Kurt D. Zeilenga" wrote:
>
>> At 06:35 AM 3/20/00 +0000, Andrew Hacking wrote:
>> >I take it you are referring to the top level ldap API, not the internals here, since
>> >that would really mean non-blocking cannot be supported and it certainly *appears* that
>> >the code is written to handle non-blocking sockets.
>>
>> No, I'm talking about internals.  The code does NOT support non-blocking
>> streams.  In particular, write selection needs work.
>>
>
>OK, so I take it we don't want it to stay that way ?

No, but we must resolve a variety of issues if we are to support
non-blocking streams in -lldap.  In particular, what to do when
an async operation would block, whether or not to provide an
ldap_push()/ldap_flush() call to push/flush outstanding writes,
etc..

I raised a number of these issues with the LDAP C API draft authors
as it clear to me that the current draft (and RFC 1823) are not
designed with non-blocking implementations in mind.

>>
>> >What is the rationale for using and defaulting to blocking sockets within libldap ?
>>
>> UNIX sockets default to blocking...
>
>Yes, thats a fact, and a weak rationale at best.

Okay, how about simplicity of use, design, and implementation.  (I really
don't known the designers rational... this stuff was written way before
I even heard of LDAP).

>There appears to be no real *need* for using blocking sockets (other than thats the way it
>is at present), ie no rationale, and blocking sockets are certainly _not_ going to "help"
>in moving forward.

Don't ignore ease of implementation.  It was likely a large factor in the
design of the SDK.

>Is anyone else out there currently looking at these issues because I'd like to help if
>possible.

There are folks working in related issues such as SASL integration.  SASL
is related as it supports integrity and privacy layers which need to be
plugged in below LBER (and above TLS).  It may be that we need to
reevaluate how we integrate TLS and SASL.  It's not clear to me that
pushing low level I/O down into -llber was the best idea.

There was some prior discussion concerning these issues:
http://www.openldap.org/lists/openldap-devel/199906/msg00069.html
http://www.openldap.org/lists/openldap-devel/199907/msg00101.html