Re: C API draft 3: ldap_search_ext() timeout param

[Mark Smith <mcs@netscape.com>]

JR Heisey wrote:
> 
> Referencing the paragraph on page 27
> 
> timeout      For the ldap_search_st() function, this specifies the
> local
>              search timeout value (if it is NULL, the timeout is
> infin-
>              ite).  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,
> pass-
>              ing 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.
> 
> This indicates at the function ldap_search_ext_s() does not have a
> local timeout.

No.  The intent is that for ldap_search_ext_s() the local timeout and
the timelimit sent to the server are one and the same.  More precisely,
the tv_sec component of the timeout parameter is passed to the server in
the timeLimit field of the LDAP SearchRequest message and both the
tv_sec and tv_usec values are to be used for the local timeout.  In the
Netscape/Mozilla implementation, we pass 1 to the server if tv_sec is
zero but tv_usec is not.  I think this behavior should be clarified in
the draft.


> ... One of two situations comes to mind.
> 
> 1) The server, for one of many reasons ( busy, infinite loop, race
> condition ),
> may never respond to the search request or take a very long time.
> 2) The server crashes.
> 
> Q1: What is the guarantee that the client app will not hang for either
> of these
> situations?

Given what I said above, just use a non-NULL, non-zero timeout
parameter.


> Q2: Are applications expected to use the asynchronous functions if
> they wish/need to abort a search locally?

Yes, if they actually need to send an abandon they should use the
asynchronous functions -- or multiple threads.


> Q3: Will a blocked call into select() at the client return an error if
> the socket is closed by the OS at the server due to the server crashing?

This is of course implementation-specific, but my experience is that TCP
connections that are closed by servers are always reported to clients...
assuming that the underlying network and both protocol stacks are still
functioning.  If you pull the network cable out of the wall on your
server, in the absence of a client-side timeout or keepalive, the client
may never notice that the server is no longer available.

Thanks for your comments on the draft.

--
Mark Smith
Netscape Communications Corp. / Directory Server Engineering
"Got LDAP?"