opening a connection with more than a single server

[Michael Ströder]

Jens Vagelpohl wrote:
>>> i had no idea that this ever worked, but apparently (i verified it 
>>> with python-ldap 1.10alpha3) ldap.open used to accept a hostname 
>>> string as argument with more than one LDAP host, separated by 
>>> whitespace. this worked in a failover fashion where if one became 
>>> unavailable the next one would be used to execute queries.
>>
>>
>> 1. You have to decide what you want. You requested the old "parameter 
>> signature" for ldap.open(). You remember? Think of defining the port 
>> number...
> 
> this actually doesn't have anything to do with my earlier complaints 
> about ldap.open.

It has.

> i'm just saying that apparently back in the 1.10 days 
> ldap.open never checked the parameter and passed it straight to the ldap 
> libraries, which would interpret it as "if the first server is dead just 
> use the second".

Well, we can implement it like this. But it contradicts your 
inquiry for a parameter signature like described in the documentation.

--------------------- snip -----------------------
open(host [, port=PORT])

Opens a new connection with an LDAP server, and return an LDAP 
object (see 1.1.4) used to perform operations on that server. host 
is a string containing solely the host name. port is an integer 
specifying the port where the LDAP server is listening (default is 
389). Note: Using this function is deprecated.
--------------------- snip -----------------------

We can either
1. change the docs and pass string-parameter _host_ to OpenLDAP's 
ldap_open() function and drop parameter _port_ or
2. comply to the docs which means not supporting the 
multiple-hosts-in-space-separated-list parameter.

If you don't get the difference I'm pretty sure that you've never 
used to connect to a LDAP server running on "non-standard" port...

>> 2. I'd recommend you drop support for old python-ldap and use 
>> ldap.initialize() directly.
> 
> my software is written so that it attempts to determine what version of 
> python-ldap is in use and behave accordingly.

I did that in former versions of web2ldap but dropped support for 
python-ldap 1.x because it's getting too complex if you want to do 
that completely (referrals, etc.). Also python-ldap does not 
support LDAPv3 which has some serious implications if you take 
RFC2251 ff. seriously (e.g. character set T.61 for LDAPv2 instead 
of UTF-8).

> i'm just 
> wondering if this "server fallback" behavior could find its way back 
> into python-ldap2, regardless of connection building method used, 
> because it seems it is supported by the OpenLDAP libraries and i am 
> thinking it is a useful behavior. that's all.

Someone has to decide on that. See above.

> if i remember correctly i had at one time tried to come up with a way to 
> test whether a given LDAP connection object was still good for use, but 
> could not find anything that would not already involve making LDAP queries.

Yes, you have to try a LDAPRequest and catch ldap.SERVER_DOWN.

 > i have
> never experimented with long-lived connections. i am all for improving 
> performance, if you can show me a good way to test existing connection 
> objects and tell me that it is indeed faster to do it, i'm all ears.

Well, if you're after performance you should work with persistent 
connections. Especially for web2ldap it was a great performance 
boost since web2ldap does a lot of special stuff after 
establishing the connection. Doing this for each request is a 
performance nightmare. Think of negotiating LDAP protocol version, 
evaluating RootDSE attributes, more complex bind operations, etc.

Ciao, Michael.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2922 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20020501/38935748/attachment.bin>