On Thu, Nov 27, 2014 at 3:27 PM, Michael Ströder michael@stroeder.com wrote:
Qian Li wrote:
On Thu, Nov 27, 2014 at 4:51 AM, Michael Ströder michael@stroeder.com wrote:
Qian Li wrote:
On Wed, Nov 26, 2014 at 5:30 PM, Michael Ströder <michael@stroeder.com
wrote:
Qian Li wrote:
Recently, I tried to write a ldap client to do ldap search
asynchronously,
but failed to perform search operation after a successful async sasl (digest-md5) bind.
What's your use-case for having async bind operation?
Note that the bind operation is somewhat special because it
establishs a
security context/association.
The ldap client is a daemon which accepts arbitrary request from outside
What kind of requests?
There are IPCs from other processes and the ldap client is only single thread.
I did something very similar recently.
I don't know what's your exact use-case. But if you're cautious about performance you should open a connection pool of persistent connections
and
always bind *once* during connection lifetime.
Yes, persistent connections pool is another solution. The search operation works in both async simple bind and sync SASL/DIGEST-MD5 bind, but doesn't work in async SASL/DIGEST-MD5 bind.
This
confuses me...
You have to wait for the SASL bind to complete *before* sending the subsequent search operation anyway => persistent connections are *the* solution.
I did wait for the async SASL bind to complete. Unfortunately, the search operation still didn't work. I have to use sync SASL bind, like persistent connections pool.
In my case such a simple local demon served 300+ requests/second with the
LDAP server with debug log and the demon running on the same old laptop. One request to the demon sends three synchronous LDAP requests.
In my case, every response from LDAP server may include many entries. Async search will be more efficient.
Thanks -Qian