Re: libldap LDAP_OPT_NETWORK_TIMEOUT feature (ITS#239)

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

[cc'ed to devel to allow discussion]

Lars Uffmann wrote:
> "Kurt D. Zeilenga" wrote:
> > One thing I noticed last night was that you called read(2) directly.
> > read(2) doesn't always work on sockets.   We use to have wrappers
> > for read in -llber, but these now act upon Sockbufs.  This needs
> > significant reworking, but needs to coordinated with our C API
> > redesign efforts.
> 
> My opinion is to wrap around system dependencies at the lowest level
> possible, while keeping the functions signatur as close as possible
> to the well known unix interface.
>
> ldap_pvt_tcp_read(fd,buf,len),
> ldap_pvt_tcp_write(fd,buf,len),
> ldap_pvt_tcp_socket(...),
> ldap_pvt_tcp_connect(fd, ...),
> ldap_pvt_tcp_bind(),
> ldap_pvt_tcp_accept(),
> ldap_pvt_tcp_close(),
> etc.

First, I would like to push these down into ber where the interface
can be quite simple and, hopefully, blissfully unaware of threads
and other complications.

What I'd like to see is a set of hooks who's symantics are modeled
after unix interface BUT return a generized error code instead of
0 or -1.  (The use of errno is quite problematic and should be hidden
in the platform specific routines... more on error handling below).
Where the unix routine (read/write) returned something else, this
would be made a argument to the hook.  Also, a pointer to the
descriptor would be used to allow for hooking in interfaces who's
handle cannot be mapped upon a ber_socket_t.

We would than have provide default implementations:
	int ber_pvt_tcp_read(
		void* descriptor,
		const char* buf,
		ber_len_t* len )

where len would be used to pass in the sizeof buf and used to
pass out the number of bytes written to buf... (an additional bytes
argument could be used instead).

The ber routines would indicate that an error occurred as they
always have.  Applications can still use errno (because the default
hooks should preserve this behavior), but new applications should
use an accessor function.  This error would return the last BER
error code which occured.  If the application desires this error
code to be thread specific can install a hook.  (Note: this hook
would provide a thread-specific BER error value... thread specific
LDAP error values is yet another issue (for another day)).

LDAP functionality (including TLS) would be built on top of this
interface.

We'd also need to sort out how best to handle datagram services.
This is current integrated into the sockbuf layer which choose
either TCP or UDP as needed.  This could be separated into a
middle layer, left where is (yuk), or pushed down into the low
level routines (additonal arguments would likely be needed).
I'm thinking that there should be two layers: BER and protocol/interface
specific routines.  I'm think we should add a additional arguments to
the hook to allow protocol addresses (and other info) specified by the
application (or -lldap) to be passed through the BER implementation
to the hooks.

> Next step could be to abstract ugly and/or unportable interfaces
> like setsockopt/getsockopt,fcntl,ioctl,select,poll and errno:

Actually, I think one needs to start with errno then read and write
as this is what BER itself depends upon.