Menu
▾
▴
|
From: <mci...@si...> - 2002-06-17 10:20:20
|
Michael Str=F6der =3Cmichael=40stroeder=2Ecom=3E writes=3A =3E Mauro Cicognini wrote=3A =3E =3E = =3E =3E However=2C I have seen that the searches don=27t show significant= = =3E =3E differences with the old 1=2Ex version=2E =3E = =3E Can you provide numbers=3F Hmmm=2C not really=2E It=27s just my feeling trying to do some simple = searches from the Python command line=3A I type the instruction=2C hit = return and =27=3E=3E=3E=27 comes up immediately (i=2Ee=2E no visibile del= ay)=2E I could do some timing=2C but I don=27t have the time now to set up the = environment now=2E=2E=2E sorry about this=2E I=27d be glad to supply sources and binaries to anyone interested=2C = though=2E =3E =3E The single call that takes a lot is the bind step=3A when I ask a= = =3E Python = =3E =3E script to bind it just seems to sit there and wait=2C more or les= s = =3E for 5 = =3E =3E seconds (strange coincidence)=2E =3E =3E = =3E =3E Could all this be related to the SASL libraries=3F =3E = =3E Hmm=2C no idea=2E I guess you are you talking about a simple bind=2E Yes=2C it=27s a simple bind=3A username and password=2E I guess it=27s also the only one supported by Win32 without certificates = or the whole Kerberos shebang=2E I really hope someone with SASL experience comes to our rescue=2E Mauro |
|
From: Mauro C. <mci...@si...> - 2002-06-24 08:01:33
Attachments:
smime.p7s
|
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 |
|
From: <mi...@st...> - 2002-06-24 09:20:46
|
Mauro Cicognini wrote: > I'm glad to announce that I've found the limiting factor for the 5-odd > seconds delay during binds, Note that with python-ldap 2.0.0pre04 ldap.initialize() is used in any case which wraps ldap_initialize in the OpenLDAP libs. ldap_initialize() has a slightly different behaviour than ldap_open(). AFAIK it just initializes the LDAP connection context but does not open the LDAP connection. The LDAP connection is opened when doing the first LDAPRequest - no matter which one. Having said this I'd like to see your test script. You might wanna check if the delay really happens during BindRequest or any first LDAPRequest. Note that LDAPv3 does not require you to send a BindRequest prior to other LDAPRequests. > 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). Hmm, reverse lookups might make sense when using LDAP over SSL or LDAP with StartTLS to cross-check the server's name with the CN attribute in the subject DN of the server certificate. Since the OpenLDAP 1.x libs did not have any support for SSL/TLS this might be an issue with OpenLDAP 2.x libs. Just thoughts, not sure though... > 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. Can you please try to use the IP address directly and check if the same behaviour happens? > 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. > [..] > I can tell that it isn't Windows fault, at least: I'm not sure if that conclusion is right. 1. I remember reverse lookup problems with various software on Windows. (Therefore your observation is very interesting for other things too.) 2. I can't imagine why the OpenLDAP 2 libs should explicitly do reverse NETBIOS lookups other than using a default parameter somewhere which causes that. Now how's the behaviour on Windows with the normal OpenLDAP tools ldapsearch, etc.? Ciao, Michael. |
