state-threads
[Top] [All Lists]

Re: Using with LDAP

To: state-threads@xxxxxxxxxxx, parag.warudkar@xxxxxxxxx
Subject: Re: Using with LDAP
From: Gene Shekhtman <gsh@xxxxxxxxxx>
Date: Mon, 16 Jul 2001 14:38:38 -0700
Cc: Dan Melomedman <dmelomed@xxxxxxxx>
Organization: Abeona Networks, Inc.
References: <000701c10de0$24b372a0$dbbfa8c0@xxxxxxxxxxxxxxxxxxx> <20010716145831.D231@xxxxxxxx>
Sender: owner-state-threads@xxxxxxxxxxx
Dan Melomedman wrote:

>
> Does anyone have a better suggestion? Would it be possible to run two
> separate servers one being the main server, and the other being the LDAP
> helper server which would do IPC via a local UNIX socket for the purpose
> of avoiding fork()? How would we differentiate between requests from
> different state threads? The LDAP search server could be multithreaded
> using alternate threading libraries like pthreads or GnuPth.
>
> >     We are planning to use state threads library in our server application
> > which serves login requests. The UserID/Passwords are stored in LDAP. So the
> > Server needs to do network io with LDAP via the Netscape directory SDK for
> > C, which has asynchronous functions. The state threads documentation states
> > that only state thread i/o routines should be used. Is there any way to use

I'd suggest two things:

1.  Use very simple LDAP "helper" server that listens to a local (UNIX domain)
    socket and accept()s connections from the "main" server which calls ST
    functions (st_connect(), st_write(), st_read()).  The "helper" server may
    just pre-fork a fixed (and always constant) number of processes that use
    Netscape directory SDK.  Of course, you'll be able to have only as many
    simultaneous LDAP queries as the number of processes in the "helper" server.

2.  Cache UserID/Passwords in the "main" server.  Only if a UserID hasn't been
    found in the local cache, you communicate with the "helper" server to do a
    LDAP query.

Regards,
Gene




<Prev in Thread] Current Thread [Next in Thread>