ldap_result() doesn't detect eDirectory server dead

[tfif]

Hi,
My app has an async search running and uses ldap_result() to look for
changes.
The eDirectory it is connected to runs on a separate Windows 2003 box, and
this took a blue screen of death. ldap_result() continued to return zero
(timeout expired) and didn't detect that the session/server had died.
I can reproduce this running the eDirectory server under VMware and then
pausing the VMware image.
I am using build: novell-cldap-devel-2006.02.20-1netware_windows on XP for
app.
The app works fine when the server is up.

Any ideas?

Cheers
Steve

[Susan Perrin]

Hi

What behavior would you prefer? Timing out seems reasonable to me. If you
cycle through a few timeouts you can check the connection. Please let me
know what you would expect here.

Thanks
Susan

[Peter Kuo]

How do you want the client (any comm-related client really) to be able to
detect the difference between a server down and a LAN/WAN link down or
whatever caused a no response (thus a timed out)?

[tfif]

Post by Peter Kuo
How do you want the client (any comm-related client really) to be able to
detect the difference between a server down and a LAN/WAN link down or
whatever caused a no response (thus a timed out)?

Well, I assumed that the time out error code was intended to indicate that
the timer specified on the ldap_result has run out. My app does an
ldap_result for 5 seconds to see if there are any directory changes,
checks a few other things and then does another ldap_result. On a quiet
directory server, the app will quite easily sit there for some time on
these 5 second timeouts until a change occurs.
I don't see why just because the app has had several timeouts in a row
that it should have to check that the server is still there or not!
Shirley this is the job of the network layer provided by the ldap api? I
have very much similar code doing the same to Sun iPlanet and Microsoft AD
and they all return a different error code when the server goes away.
Are you telling me that the api code responsible for the connection to the
directory server doesn't get any indication that the TCP session has died?

Steve

[Peter Kuo]

If you're simply looking/waiting for changes, you probably should be doing
a persistent search instead ... its lot less resource intensive as your
app gets notified /when/ there's a change (ie push) and not have to poll
for it constantly.

[Peter Kuo]

It is my understanding that the TCP transmission timeout is handled at the
driver level and if your application is required to be notified, it is up
to the application in question to query the driver for that info and not
the responsibility of any intervening API that utilizes the transport.
Although for TCP the SO_SNDTIMEO socket option will affect how long a
system call to send data may block (waiting for buffer space to become
available etc.) but it does not affect the TCP transmission timeout, far
as I know.