[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Multiple extended responses per request
The idea of using SNMP for monitoring purposes is very appealing for situations where monitoring status is the desired task. In fact, Bruce's idea has given me some things to consider in some other work I'm doing. Thanks!
Gil correctly points out that my (actually Dave Wilbur's) original intent here was just to have the option of multiple responses available to extensions when what they're doing warrants it. Searching is an example of an operation that benefits greatly from this paradigm, and I imagine that other operations may similarly benefit. If this isn't a good enough reason for changing RFC 2251 to allow multiple responses to an extended request, then I guess we'll have to come up with a practical, concrete example that is more convincing to the LDAP community.
Roger
>>> Gil Kirkpatrick <gilk@netpro.com> 09/15/99 09:57AM >>>
If you provide for "detached processes", i.e. long-duation operations that
can continue beyond the scope of the connection that created them, it seems
like you're creating a whole new mechanism for the server. It would
effectively provide a batch procesing facility where clients submit commands
to be processed, and then disconnect from the server. The status of the
commands can then be monitored from anywhere using SNMP.
A neat idea, and not hard to put together a prototype. It also takes the
status notification issue out of the LDAP protocol, which may be a good
thing. Though I don't think this is where the conversation wants to go;
Roger just wants the option of multiple responses in extensions, if I
understand him properly.
-gil
> -----Original Message-----
> From: Bruce Greenblatt [SMTP:bgreenblatt@directory-applications.com]
> Sent: Wednesday, September 15, 1999 8:46 AM
> To: Gil Kirkpatrick; mcs@netscape.com
> Cc: Roger Harrison; ietf-ldapext@netscape.com
> Subject: RE: Multiple extended responses per request
>
> There are a couple of reasons that you might want to consider using SNMP.
> If you only report status via LDAP, status can only be reported to the
> client that issued the initial request. Also, assuming the basic, obvious
> implementation, the connection must remain alive for the life of the long
> lived operation. I can imagine a subtree copy of several million objects
> that could take many hours to complete. If you use SNMP, the status can
> be
> retrieved from any management station. I guess that this is analogous to
> using the stored LDAP object approach that was also suggested... Bruce
>
> At 10:10 AM 9/14/99 -0700, Gil Kirkpatrick wrote:
> >I have to agree with Mark, making LDAP clients rely on an extra-LDAP
> >protocol like SNMP sounds like a bad idea. I would say the purpose of
> SNMP
> >is to provide management information about the state of the service or
> >device, not the state of an individual operation (except possibly as it
> >relates to service management).
> >
> >A mechanism where the client polls (using LDAP) for status information
> would
> >be more appropriate for long operations. This would let the client poll
> when
> >it needed an update (if it needed it) as opposed to having to handle a
> >status message for every object affected by the operation. Perhaps the
> >operation could return an operation identifier (e.g. a handle) that the
> >client would use as part of the status request.
> >
> >Another way to reduce the notification traffic from the service would be
> to
> >include some parameters with the control that would throttle the
> >notification messages to one notification every N seconds or one
> >notification every N objects.
> >
> >-gil
> >
> >> -----Original Message-----
> >> From: Bruce Greenblatt
> [SMTP:bgreenblatt@directory-applications.com]
> >> Sent: Tuesday, September 14, 1999 10:02 AM
> >> To: mcs@netscape.com
> >> Cc: Roger Harrison; ietf-ldapext@netscape.com
> >> Subject: Re: Multiple extended responses per request
> >>
> >> It wold certainly be easy enough to put together a prototype of an SNMP
> >> status reporting thing. That's the way that I'd try and see if the
> dual
> >> protocol approach is workable. Since "everyone" already supports the
> dsa
> >> MIB, it seems like a possibility that this is a natural addon to the
> >> dsaOpsTable.
> >>
> >> At 12:44 PM 9/14/99 -0400, Mark C Smith wrote:
> >> >I for one am skeptical of the value in using another protocol (e.g.,
> >> >SNMP) to retrieve status about LDAP requests. That just doesn't feel
> >> >like the right architectural solution to me. Coordinating requests
> and
> >> >responses across two different protocols on the client side will be
> >> >awkward. I do think the topic of how best to provide status about
> "long
> >> >lived" LDAP operations is an important one.
> >> >
> >> >--
> >> >Mark Smith
> >> >iPlanet Directory Architect / Sun-Netscape Alliance
> >> >My words are my own, not my employer's. Got LDAP?
> >> >
> >> >
> >> >Bruce Greenblatt wrote:
> >> >>
> >> >> Roger,
> >> >>
> >> >> It seems to me that SNMP would be more suited to providing this
> >> feedback.
> >> >> It would be a simple matter to define a mib that AUGMENTS the DSA
> mib
> >> to
> >> >> report this feedback. You'd have one row in the MIB for each
> >> outstanding
> >> >> operation that you're providing feedback on. You could have
> whatever
> >> >> columns you want to provide details about the operation, and the
> >> current
> >> >> status...
> >> >>
> >> >> Bruce
> >> >>
> >> >> At 01:30 AM 9/14/99 -0600, Roger Harrison wrote:
> >> >> >Based on my discussions with Dave Wilbur (we both work at Novell),
> the
> >> >> idea for multiple responses to an extended request came from the
> desire
> >> to
> >> >> get status on directory operations that might take a lot of time
> rather
> >> >> than the need to collate results in some way.
> >> >> >
> >> >> >Imagine a directory operation that could take a "long"
> time--deleting
> >> a
> >> >> very large subtree, for instance. It would be nice for the server
> to
> >> >> provide feedback during the time the operation is completing so that
> >> the
> >> >> client is just left hanging until the operation finally completes.
> In
> >> this
> >> >> imaginary example, I think the dialog might look like this:
> >> >> >
> >> >> >C -> S: Delete Subtree
> >> >> >S -> C: Deleted entry a
> >> >> >S -> C: Deleted entry b
> >> >> >S -> C: Deleted entry c
> >> >> >...
> >> >> >S -> C: Deleted entry x
> >> >> >S -> C: Deleted entry y
> >> >> >S -> C: Deleted entry z
> >> >> >S -> C: Result: Success
> >> >> >
> >> >> >The client would have to know and expect multiple responses for an
> >> >> extended request of this type, just like it does for search. I
> don't
> >> see
> >> >> a problem with this since the extended operation would define the
> >> allowed
> >> >> behavior, and the client could therefore be written accordingly.
> Since
> >> the
> >> >> client initiates the extended operation, it would know to expect the
> >> >> associated behavior as well.
> >> >> >
> >> >> >Roger
> >> >> >
> >> >> >------------------------------------------------------
> >> >> >Roger G. Harrison
> >> >> >Novell, Inc.
> >> >> >roger_harrison@novell.com
> >> >> >
> >> >> >>>> "Steve Fisher" <S.A.Fisher@btinternet.com> 09/13/99 03:29AM >>>
> >> >> >Dave
> >> >> >
> >> >> > In some ways, your requirements seem similar to the X.500 DAP
> >> pagedResults
> >> >> >feature which organizes search responses into a set of 'pages'.
> This
> >> is
> >> >> >initiated by the client in the initial search request (using a
> >> non-critical
> >> >> >extension) and then collected in page size chunks of entries in
> >> subsequent
> >> >> >searchRequests. This is fine if the client anticipates that some
> type
> >> of
> >> >> >management of responses is required, but is not something that the
> >> Server
> >> >> >can initiate (as far as I can see), and which is something that
> wasnt
> >> clear
> >> >> >to me in your original message. If you are looking to the Server to
> >> prompt
> >> >> >multiple results, if the client is getting back more than it
> >> anticipated, it
> >> >> >would ordinarily perform a more refined operation rather than
> accept a
> >> lot
> >> >> >of unexpected entries.
> >> >> >
> >> >> >An extended operation which deals with searches (or maybe two - one
> to
> >> >> >initiate the orgainisation of results, the other to collect
> existing
> >> results
> >> >> >'pages') which would seem a reasonable thing to do as it would
> >> maintain
> >> the
> >> >> >single request/response model and the operation of it would be very
> >> similar
> >> >> >to the existing search results processing procedures.
> >> >> >
> >> >> >If this is a 'general feature', (i.e. the organization of any
> >> operation
> >> into
> >> >> >multiple responses) then this couldn't be an extended operation, as
> >> you
> >> >> >potentially would like to 'multiply respond' to any extended (or
> >> core)
> >> >> >operation.
> >> >> >
> >> >> >Steve Fisher
> >> >> >
> >> >> >BT Syncordia
> >> >> >s.a.fisher@btinternet.com
> >> >> >
> >> >> >
> >> >> >-----Original Message-----
> >> >> >From: Dave Wilbur <DWILBUR@novell.com>
> >> >> >To: bgreenblatt@directory-applications.com
> >> >> ><bgreenblatt@directory-applications.com>; Kurt@OpenLDAP.Org
> >> >> ><Kurt@OpenLDAP.Org>
> >> >> >Cc: ietf-ldapext@netscape.com <ietf-ldapext@netscape.com>
> >> >> >Date: 10 September 1999 17:38
> >> >> >Subject: Re: Multiple extended responses per request
> >> >> >
> >> >> >
> >> >> >
> >> >> >Thanks for the feedback from Bruce and Kurt.
> >> >> >
> >> >> >The suggestion that each response be prompted by a
> >> >> >request could also be used for Persistent Search (as well
> >> >> >as a standard Search, for that matter). The fact that Search
> >> >> >saw a need (to reduce overhead, other?) to allow for multiple
> >> >> >responses to a request, in the form of entries and a result
> >> >> >leads me to believe that an extension should be able to
> >> >> >accomplish similar functionality.
> >> >> >
> >> >> >The fact that Kurt suggested that we CAN do multiple
> >> >> >responses per exteded request leads me to believe that
> >> >> >there are others who think this should be allowed. Currently
> >> >> >the RFC implies that you only get one Extended Response
> >> >> >per request and the client SDKs are implemented so that you
> >> >> >can only retrieve one response per request. So if we are to
> >> >> >allow multiple resonses per request, then the RFC should state
> >> >> >this and the SDKs should support it.
> >> >> >
> >> >> >Dave
> >> >> >
> >> >> >>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.Org> 9/9/99 10:13:51 AM >>>
> >> >> >At 08:48 AM 9/9/99 -0700, Bruce Greenblatt wrote:
> >> >> >>Hi Dave!
> >> >> >>
> >> >> >>You'll want to do something similar to the multi-stage bind.
> >> >> >
> >> >> >Or something similiar to what search does:
> >> >> >
> >> >> >CLIENT SERVER
> >> >> > Extended Request
> >> >> > ------------------------------------------>
> >> >> >
> >> >> > Extended Response (not done)
> >> >> > <------------------------------------------
> >> >> > Extended Response (not done)
> >> >> > <------------------------------------------
> >> >> > Extended Response (not done)
> >> >> > <------------------------------------------
> >> >> > Extended Response (not done)
> >> >> > <------------------------------------------
> >> >> > Extended Response (not done)
> >> >> > <------------------------------------------
> >> >> > Extended Response (not done)
> >> >> > <------------------------------------------
> >> >> > Extended Response (done)
> >> >> > <------------------------------------------
> >> >> >
> >> >> >
> >> >> >At 03:50 PM 9/8/99 -0600, Dave Wilbur wrote:
> >> >> >>While developing an LDAP v3 extension, a developer here wanted to
> be
> >> able
> >> >> >to send multiple responses against one request. This was
> relatively
> >> easy
> >> >> >to support in our server code, but the published client APIs don't
> >> support
> >> >> >more than one response per message id. While RFC 2251 for
> LDAPResult
> >> is
> >> >> >quite clear in stating "to indicate the *final* status of a
> protocol
> >> >> >operation request", the ExtendedResponse is not quite so
> definitive:
> >> "The
> >> >> >server will respond to this with an LDAPMessge containing the
> >> >> >ExtendedResponse."
> >> >> >>
> >> >> >>Given the precedent of an interim response in the Search verb as
> well
> >> as
> >> >> >Persistent and Triggered search, it seems to make sense that an
> >> Extension
> >> >> >might want to do this as well. We were going to use different OIDs
> to
> >> >> >indicate if a response was interim or final until we ran into the
> >> client
> >> >> >issue.
> >> >> >>
> >> >> >>Is this feasible? reasonable?
> >> >> >>
> >> >> >>Looking for feedback.
> >> >> >>
> >> >> >>Dave
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> ==============================================
> >> >> Bruce Greenblatt, Ph. D.
> >> >> Directory Tools and Application Services, Inc.
> >> >> http://www.directory-applications.com
> >> >
> >> >
> >> >
> >> ==============================================
> >> Bruce Greenblatt, Ph. D.
> >> Directory Tools and Application Services, Inc.
> >> http://www.directory-applications.com
> >
> >
> >
> ==============================================
> Bruce Greenblatt, Ph. D.
> Directory Tools and Application Services, Inc.
> http://www.directory-applications.com