Re: Client update protocol

Hi,

Thanks for the reply.  Regarding your earlier comments...

I might have 30,000 LDAP clients that want to know if a particular LCUP 
context has changed.  They might "subscribe" to this particular event 
so they get notified.  Notification methods such as that suggested by 
persistent search (and variants) or polling (connect/bind/search) would 
be sub-optimal with this many clients potentially involved. The LCUP 
sync mechanism will work great...I just need a client to be "tapped on 
the shoulder" when it should connect/bind and  issue the LCUP search 
method. The same entity that is notified, will be the same entity that 
issues the special LCUP context search.

At an IETF meeting a couple of years ago I had a discussion about such 
a technique (before I actually had a need for it) during early 
discussions about CLDAP and how this type of scenario could be included 
in the problems addressed by CLDAP.

Your suggestion about a "middleware" entity that maintains a persistent 
LCUP search sounds like it would be a good start,  looking "northbound" 
to the source DIT.  Looking back towards the clients, there would still 
be a need for clients to register their interest, as well as the actual 
lightweight delivery mechanism.

If there had been an extensible "trap/inform" group in the MADMAN MIB, 
then that might be a potential solutions as well.  Not perfect, but a 
step in the right direction. Ultimately, the solution will probably 
involve work going on outside the LDAP WG, again I'm just trying to 
find anyone with a problem domain similar to this.

I don't remember the exact names of the projects regarding event 
notification systems...but if you do a google (or other) search for 
"scalable event notification", this will show you a set of starting 
points that I used for my own research. Most of the recent work has 
been in academia, but I believe there are implementations of these 
systems available, as well as some organizations looking to go 
commercial with similar technology.

Thanks again for the reply,
Randy


On Monday, February 10, 2003, at 01:26 PM, Rich Megginson wrote:

> Randy Turner wrote:
>
>> Hello all,
>>
>> I recently read over the LCUP document and this text looks very good 
>> for DIT synchronization.  What I am looking for is some type of 
>> "event" mechanism to trigger a client to connect/bind and initiate 
>> LCUP.  This would require the directory server to have knowledge of 
>> "who" is interested in being notified of DIT updates.  I may have 
>> 500,000 clients for a directory, and I would prefer not to have to 
>> have the clients poll the server.  If a particular LCUP context is 
>> modified, I would like some type of async notification sent to 
>> interested parties.   Most of the work of actually synchronizing the 
>> DIT is covered by the LCUP document, I just need the clients to be 
>> notified "when" to perform LCUP. Ideally, the trigger mechanism would 
>> be some type of lightweight, connectionless notification, similar to 
>> an SNMP trap but more specific.
>
> How many "interested parties" will there be?  Will the "interested 
> parties" actually initiate an LCUP request?
>
> A standard LDAP server is not designed to initiate connections to 
> other servers or clients (except in the case of replication, but that 
> is not a standard yet, nor would it likely serve your purpose).  Some 
> LDAP servers do support callbacks or triggers that usually involve 
> having to write your own plugin or some other mechanism.
>
> This sounds like the sort of thing that message bus/queue 
> architectures are trying to solve.  You could have an LDAP client that 
> issues an LCUP persistent search against an LDAP server, and the 
> client would put a message on the bus/queue every time it received an 
> LCUP response.  Other clients register with the bus/queue and receive
>
> BTW, for those interested, we are still working on the LCUP 04 draft 
> and hope to have something very soon.
>
>> There is activity going on with global, scalable event notification 
>> architectures that is not specific to any IETF work, and we are 
>> looking into this.  However, I wanted to make sure I understand the 
>> taxonomy of any and all work related to solving this type of problem.
>
> Can you provide more information about this work?
>
>> If there is work going on in this area in this, or another working 
>> group, I would appreciate any and all pointers, or other comments.
>>
>> Thanks in advance,
>> Randy
>>
>
> <smime.p7s>