[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Multiple extended responses per request
My example is hypothetical and is only to be used to illustrate one possible reason why you'd one multiple responses for an extended request. Each extension would need to be designed so that information sent on the wire was done in an efficient and reasonable way. The key is to give the extension designers the ability to use multiple responses so we has a choice in the first place.
Roger
>>> Gil Kirkpatrick <gilk@netpro.com> 09/14/99 09:15AM >>>
Roger,
If the purpose is to provide progress information to the client, doesn't
this scheme generate an inordinate amount of traffic, e.g. in your example
of the tree delete, a packet per entry in the tree being deleted?
Gil
> -----Original Message-----
> From: Roger Harrison [SMTP:RHARRISON@novell.com]
> Sent: Tuesday, September 14, 1999 12:31 AM
> To: <
> Subject: Re: Multiple extended responses per request
>
> 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
>
>
>