Re: [ldap] Re: LDAP SDK API question.

[Raj Kunjithapadam <rajk@home.com>]

Gordon Good wrote:

> My responses are inline:
>
> JR Heisey wrote:
>
> > Hi Gordon,
> >
> > Blow are my responses marked >>>
> >
> > Gordon Good wrote:
> >
> > > This isn't quite correct. There are two separate things here; (1) client SDK timeouts and (2) server time and size
> > > limits,  I think you're confusing the two.
> > >
> > > Client SDK timeouts:
> > > ==============
> > > When you call ldap_search_st(), which has the following signature:
> > >
> > > int ldap_search_st( LDAP *ld, const char *base, int scope,
> > >    const char* filter, char **attrs, int attrsonly,
> > >    struct timeval *timeout, LDAPMessage **res );
> >
> > >
> > > ...the "timeout" parameter tells the SDK how long it should wait for the results of the search operation to come
> > > back from the server. This parameter is *not* passed to the server. It's meant to allow you to deal with the case
> > > where a server accepts a request and just never answers.
> > >
> > > If you look at the source, you'll see that ldap_search_st() is just a call to ldap_search() and then a call to
> > > ldap_result(), passing the "timeout" parameter to ldap_result(). If the timeout expires, ldap_result() will return
> > > and the SDK will abandon the operation.
> > >
> >
> > >>> This is not correct for Mozilla code. This is correct for OpenLDAP code.
>
> I stand corrected. The Mozilla code implements the new draft C API (with one problem I can see). The following is an
> excerpt from http://search.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-c-api-02.txt that describes the "timeout"
> parameter of the ldap_search_st(), ldap_search_ext(), and ldap_serarch_ext_s() functions.
>
> ---begin excerpt---
> "timeout      For the ldap_search_st() function, this specifies the local search timeout value (if it is NULL, the
> timeout is infinite).  For the ldap_search_ext() and ldap_search_ext_s() functions, this specifies both the local search
> timeout value and the operation time limit that is sent to the server within the search request.  For the
> ldap_search_ext() and ldap_search_ext_s() functions, passing a NULL value for timeout causes the global default timeout
> stored in the LDAP session handle (set by using ldap_set_option() with the LDAP_OPT_TIMELIMIT parameter) to be sent to
> the server with the request but an infinite local search timeout to be used."
> ---end excerpt---
>
> > >>> However the OpenLDAP code calls ldap_build_search_req() which in turn includes ld->ld_timelimit
> > >>> when it sends the request to the server. If this timeout value is smaller than the value
> > >>> passed to ldap_search_st() the server will timout prematurely.
> >
> > >>> The Mozilla code calls ldap_search_ext() which calls ldap_build_search_req() however
> > >>> this version of ldap_build_search_req() has been modified to accept a timeout value which
> > >>> will override the value in ld->ld_timelimit.
>
> Correct, and for ldap_search_ext_s(), this behavior is as specified in the C API Internet Draft. However, looking at the
> Mozilla code, I see that the ldap_search_st() call is implemented in terms of ldap_search_ext_s(), which means that the
> "timeout" parameter sets *both* the local and server-side timeout, which is in violation of the language from the draft.

If this is true, I am using the mozilla SDK version 3.0 and using ldap_search_st()  with a timeout of 5 secs
going against Netscape Directory 4.0

This is what I see in the server logs.
/****************
[18/May/1999:12:51:06 -0700] conn=7 fd=24 slot=24 connection from 24.0.17.128 to 24.0.30.194
[18/May/1999:12:51:06 -0700] conn=7 op=0 BIND dn="cn=Directory Manager" method=128 version=2
[18/May/1999:12:51:06 -0700] conn=7 op=0 RESULT err=0 tag=97 nentries=0 etime=0
[18/May/1999:12:51:06 -0700] conn=7 op=1 SRCH base="o=At Home Global IP Pools" scope=2 filter="(atmailgenid=zzzz)"
[18/May/1999:12:51:11 -0700] conn=8 fd=23 slot=23 connection from 24.0.17.128 to 24.0.30.194
[18/May/1999:12:51:11 -0700] conn=8 op=0 BIND dn="cn=Directory Manager" method=128 version=2
[18/May/1999:12:51:11 -0700] conn=8 op=0 RESULT err=0 tag=97 nentries=0 etime=0
[18/May/1999:12:51:11 -0700] conn=8 op=1 SRCH base="o=At Home Global IP Pools" scope=2 filter="(atmailgenid=zzzz)"
[18/May/1999:12:51:12 -0700] conn=7 op=1 RESULT err=3 tag=101 nentries=0 etime=6
[18/May/1999:12:51:17 -0700] conn=8 op=1 RESULT err=3 tag=101 nentries=0 etime=6
[18/May/1999:12:57:38 -0700] conn=7 op=-1 fd=0 closed error 11 (Resource temporarily unavailable)
[18/May/1999:12:57:38 -0700] conn=8 op=-1 fd=0 closed error 11 (Resource temporarily unavailable)
*******************/
This leads me to beleive that the server side time out for the operation is not set. Correct me here if I am wrong.
This is because the server sends a return code of 3 back.
On the client side I get the return code of 81 (LDAP_SERVER_DOWN) for ldap_search_st()
The client correctly calls ldap_unbind_s() and retries. This is reflected by conn=8
Now why is the server freeing the socket after 6 minutes.

Should I not expect to see something like
[18/May/1999:12:57:38 -0700] conn=9 op=1 UNBIND
[18/May/1999:12:57:38 -0700] conn=9 op=1 fd=0 closed

since the client called ldap_unbind_s()
instead of seeing

[18/May/1999:12:57:38 -0700] conn=7 op=-1 fd=0 closed error 11 (Resource temporarily unavailable)

The bigger problem here is that the server uses up the allowed limit of 1024 socket descriptors
pretty quickly and the server goes into a weird state.

This is easy to do, when you have multiple sendmail relays going against the same directory server.

-KRaj




>
>
> So, to summarize:
>
> OpenLDAP doesn't yet implement ldap_search_ext() and friends, and "timeout" parameters in the API calls only affect the
> local timeout. To set the server-side timeout, you must use ldap_set_option(). This is the same as the original umich
> code.
>
> Mozilla code implements ldap_search_ext() and friends, and the "timeout" parameter can affect both the local and
> server-side timeouts, as described above, with the caveat that ldap_search_st() isn't treated specially, as called for
> in the draft.
>
> Apologies for the error. I guess I'm living a little in the past.
>
> -Gordon

begin:vcard 
n:Kunjithapadam;Raj
tel;cell:408-504-3254
tel;home:510-651-9978
tel;work:650-569-5733
x-mozilla-html:TRUE
org:@Home Network;Set Top Engineering
adr:;;4023 Budwing Terrace;Fremont;CA;94538;US
version:2.1
email;internet:rajk@home.com
title:Software Engineer
x-mozilla-cpt:;0
fn:Raj Kunjithapadam
end:vcard