Re: Client update protocol

[richm@xxxxxxxxxxxx (Rich Megginson)]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature