[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Multiple extended responses per request
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