Re: Still one comment on the LCUP scalability

[email protected] wrote:

> I found the text in the LCUP draft:
>
>    Implementors of servers that support the mechanism described in this
>    document should ensure that their implementation scales well as the
>    number of active persistent operations and the number of changes
>    made in the directory increases. Server implementors are also
>    encouraged to support a large number of client connections if they
>    need to support large numbers of persistent operations.
>
> So I assume this means that one client can do a lot of persistent searches
> as well.

I think if a server is designed to support a large number of persistent searches and a large number of client connections, that
should not exclude the possibility that a single client may have a large number of persistent searches and open connections.

In fact, this may happen.  Let's assume you have a server with several naming contexts.  Each naming context is in a separate LCUP
context.  This means that you must do several different searches.  Let's say you have a client maintaining a cache.  That client
may have to issue multiple concurrent LCUP persistent searches for each naming context.

You could design the data layout of your server such that all LCUP contexts are contained within a single naming context, so that
a single LCUP search with a single base could receive update notifications for all suffixes e.g.
o=LCUP Contexts
    o=foo org
        ou=People
        ou=Groups
    o=bar org
        ou=People
        ou=Groups

Then, you could issue a search with a base of o=LCUP Contexts and a search filter of (objectclass=mySubscriber).  Then, any time a
new subscriber is added to o=foo org or o=bar org, the LCUP search will provide notification.

>
>
> Jukka
>
> > -----Original Message-----
> > From: ext Rich Megginson [mailto:[email protected]]
> > Sent: 24. September 2001 17:20
> > To: Aakula Jukka (NET/Espoo)
> > Cc: [email protected]
> > Subject: Re: Question on LCUP
> >
> >
> > JUKA AAKULA wrote:
> >
> > > Thank you for the answer, Rich
> > >
> > > Still a question below:
> > >
> > > >> But suppose the client keeps a more dynamic cache in the sense
> > > >> that when the client "gets interested" in a certain entry,
> > > >> the client allways makes a Persistent Search ?
> > > >
> > > >Do you mean the client makes an additional Persistent
> > Search?  I don't
> > > think that would be necessary.  If the client somehow
> > > >becomes interested in an entry outside the scope of the
> > current LCUP
> > > request, the client could simply close the connection
> > > >and issue another LCUP request with a wider scope.
> > >
> > > Take an example: there are one million subscribers in a telephone
> > > catalogue. Each subscriber entry is immediately
> > > below the root entry.
> > >
> > > A client maintains a cache with a subset of the subscriber
> > entries using
> > > persistent search. Each time a new subscriber is added in
> > the subset the
> > > subscriber entry is searched for in the telephone catalogue using
> > > persistent search. (The subset is say
> > > members of some club.)
> > >
> > > Is such use of LCUP fully infeasible ?
> >
> > No.  In the LCUP model, you would do an LCUP (persistent)
> > search with (for example) a base of o=root and a search filter of
> > cn=some club.  When a new entry is added, only that new entry
> > is sent back via the persistent search.  If for some reason the
> > client was disconnected, the client issues an LCUP search the
> > next time it is connected and gets back only the entries which were
> > added or modified since the last LCUP search.
> >
> > > Or should the client make a persistent search for all the
> > entries in the
> > > catalogue but skipping those
> > > it's not interested in ?
> >
> > I'm not sure that's necessary, since LCUP should only give
> > you back the entries you are interested in.
> >
> > >
> > >
> > > Jukka
> >