|
From: Mauro C. <mci...@si...> - 2002-06-24 08:01:33
|
I'm glad to announce that I've found the limiting factor for the 5-odd seconds delay during binds, which I was annoyed by, and that I was able to remove it. Therefore, it appears that the native Win32 (i.e., non-Cygwin) version of PythonLDAP 2.0.0pre04 (linked against OpenLDAP 2.0 libs) is indeed a workable replacement for PythonLDAP 1.x (under Windows, that is). If anyone's interested, here's what I found. By sniffing network traffic I saw that it wasn't LDAP's fault per se. In fact, for some reason the current libraries (as opposed to the old UMich libs that I used in PythonLDAP 1.x) do a reverse-resolution on the server's IP address before attempting to bind, on both DNS _and_ NetBIOS (remember I'm dealing with Windows machines here). Note that the I passed the LDAP server's address as a DNS name, and that the IP address was correctly resolved by my DNS server. Anyhow, the client always tries to find the NetBIOS name of the server machine, and this was what caused the delay, since my LDAP server is behind a firewall which is configured to disallow NetBIOS queries (the client tries 3 times the query, then gives up). Once I let NetBIOS-ns through (UDP port 137) the delay disappeared. If anyone has a clue to what is causing this rather bizarre behavior in the client, please let me know: I do think this is a misfeature, and I'd like to #ifdef it away at least in my version of the libs. However, I can't really tell who's doing this: it might be happening within SASL, or within OpenLDAP, or in any of some minor different components that need to be there when compiling. I can tell that it isn't Windows fault, at least: I'm sure of this because I compiled, on the same machine (WinXP Pro using MSVC++ 6.0sp4), both versions of PythonLDAP (old 1.x style linked with UMich libs, and new 2.x linked with OpenLDAP libs); and the former isn't trying reverse resolution, whereas the latter is. If anyone's interested, I can post the compiled Win32 binaries somewhere so that others may test them more thoroughly than myself. Thanks everybody Mauro |