directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: New LDAP client patch
Date Tue, 10 May 2016 14:52:57 GMT
Le 10/05/16 16:28, Kristinn Örn Sigurðsson a écrit :
> Hi Emmanuel and thank you for your reply.
> Your points are 100% valid and I actually did think about them before I
> made the patch.
> However, it's not sufficient to be able to fix the issue at hand (at least
> in my case).
> I don't know beforehand what kind of connectivity the machine will be able
> to facilitate. So listing all addresses on the machine and/or enforcing the
> system to prefer ipv6 is not an option for me (which also has lots of side
> effects in terms of other components of the service we are developing).

There are 6 use cases :

- the client is IPV4 only and the server is IPV4 only : all is fine, you
will only get an IPV4 address whe doing a getAllByName().

- the client is IPV4 and the server is supporting both IPV4/IPV6. If you
can't enforce the "" option on the client,
you know you have to use the server's IPV4 address

- the client is IPV4 and the server is only supporting IPV6 : you are

Same but with a client being IPV6 and the server IPV4, 3 more use cases,
symetric to the previous ones.

Bottom line, you can detect the client's capabilities, and behave
accordingly by processing the getAllByName() addresses for the 4 working
use cases, without trying to open a connection, right ?
> I would assume others might be in the same situation. We did some
> benchmarking and the performance hit by this patch is very minimal. It was
> not an extensive burst performance test though.
> Developers that are creating software that needs to be shipped to others as
> part of an appliance will most likely run into similar issues as I have -
> since I don't know what type of connectivity the appliance will have access.
yes, but that can be determinated without having to create multiple

View raw message