Matt Sergeant wrote:
On 11-Apr-06, at 12:02 PM, Elliot Foster wrote:
Matt Sergeant wrote:
On 11-Apr-06, at 2:56 AM, Elliot Foster wrote:
I would like to submit another plugin for your consideration.
This plugin is different from auth_ldap_bind in that it supports
CRAM- MD5 authentication. The two plugins have different
applications (mostly due to different security requirements,) but
I could put some effort into merging the two plugins together if
it is so desired.
Could you connect to the LDAP server just once (in register()) to
save the overhead of doing that for every email in persistent
environments?
That would be a bit of work, but would be possible. There would
have to (obviously) be some sort of method to do a health check/
reconnect for the connection, but I suppose that would be done when
a query over the connection fails. In the case that the query
fails, simply store a new connection object over the old (hopefully
invalid) one. There would be additional complexity in the reaction
of the LDAP server to a long-running connection, as well. This
would obviously not work if there is any forking involved (feel free
to correct me if I am wrong.)
Sounds about right. Basically you'd wrap it in a singleton class
thing - sort of like Apache::DBI. Hmm, maybe Net::LDAP needs an
equivalent to DBI's connect_cached() ;-)
I don't know what your goal is from this (or if it's purely fun), but if
you want to get slick, maintaining a pool of connections would be very
nice. You would need enough traffic to keep the connections alive (not
idle), but it would allow for a more smooth reaction to one lost
connection, and would give you the opportunity to make use of multiple
Directories (four persistent connections to four different servers.)
I'm not familiar with connect_cached, but a quick read of the cpan page
says "yeah, that would do it."
What I had planned to do for the new code was to make the LDAP
queries asynchronous, but I could see why you would want to reuse
the same connection, to not have to tear down and build up on every
query.
Yeah, basically in my experience LDAP is pretty slow for what it
does, and anything that can help that performance the better.
Interesting. I've found it to be rather good for what it does (scalable
flexible information storage optimized for reads.)
What Directories did/do you use? Tuning is also very important, as a
poorly tuned LDAP server is a horrible thing to use.
But yes, there is a fair amount of overhead in the build up/tear down of
the TCP connection for every query. Load-balanced asynchronous queries
to a pool of connections would be pretty zippy, though. :)
