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>