RE: Another problem with abandon

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Surely the rebind will abandon ALL outstanding oerations. Doesn't RFC 2251 recommend a search? In any case, I don't believe this is an appropriate use of the bind service.

-----Original Message-----
From: Jim Sermersheim [mailto:jimse@novell.com]
Sent: Friday, 20 June 2003 16:03
To: Ramsay, Ron; Kurt@OpenLDAP.org
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: Another problem with abandon


A client can have knowledge of whether the update was abandoned by
abandoning the update, then rebinding (or just rebinding).

If I get a response to the update op before I get a bind response, then
the update op result tells me what happened.
If I don't get a response to the update op before I get a bind
response, then the update was abandoned. This is because the server must
either abandon outstanding ops or wait for them to complete before a
bind can be serviced.

This probably is not clear in that last sentence below. I will break it
up and clarify.

Jim

>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 6/19/03 11:36:14 PM >>>
You went off the rails at the end! A bind operation does not signify a
successful abandon. The only way to ensure an update operation was
abandoned is to perform a search. It seems unnecessary to know whether a
query operation was successfully abandoned.

-----Original Message-----
From: Jim Sermersheim [mailto:jimse@novell.com] 
Sent: Friday, 20 June 2003 15:16
To: Kurt@OpenLDAP.org 
Cc: ietf-ldapbis@OpenLDAP.org 
Subject: Re: Another problem with abandon


Here's my proposal for this (it's a little wordy, I may try to fix
that):

There is no response defined in the Abandon operation. Upon reciept of
an AbandonRequest, the server MAY abandon the operation identified by
the MessageID. Operation responses are not sent for successfully
abandoned operations, thus a client SHOULD NOT use the Abandon
operation
when it needs an indication of whether the operation was abandoned.
For
example, if a client performs an update operation (Add, Modify, or
ModifyDN), and it needs to know whether the directory has changed due
to
the operation, it should not use the Abandon operation to cancel the
update operation. Clients can ensure that an operation has been
successfully abandoned by performing a subsequent bind operation, and
this method only works when the underlying transport guaranties
ordering
of messages.

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/19/03 8:41:11 PM >>>
In an attempt to bring closure to an other thread...
  http://www.openldap.org/lists/ietf-ldapbis/200211/msg00000.html 

As John McMeeking pointed out, this isn't really a protocol
issue as LDAP assumes it is mapped onto a connection-oriented
transport which ensures in-order delivery of PDUs.
   This protocol is designed to run over connection-oriented, reliable
   transports, with all 8 bits in an octet being significant in the
data
   stream.

If the server chooses to use an multi-threaded approach, then it
needs to maintain appropriate state information to ensure the
appropriate behavior is provided.

I do, however, think the following statement:
   If the LDAP session is operating over a connection-oriented
transport
   such as TCP, the server will return to the client a sequence of    

   responses in separate LDAP messages.

needs clarification (s/If ... TCP//) as it implies the protocol
is designed to run over non-connection-oriented transports such
as UDP.

(This is not to say that LDAP cannot be mapped onto UDP, just that
this is not discussed in the technical specification.)

Kurt


At 11:31 AM 11/1/2002, Jim Sermersheim wrote:
>Due to abandon not having a response, I've found another little
problem with message ID re-use.
>
>The current protocol draft says that a client can re-use a messageID
as long as it can be determined that the operation associated with
that
messageID has completed (this can be determined either by seeing a
response to the earlier message, or completing a successful bind).
>
>Here's the problem:
>
>MessageID 1 is used for an operation, the server is processing this
op.
>Abandon is sent for MessageID 1
>A response is sent for operation 1
>The client, seing that operation 1 has returned a response, uses
messageID 1 again for another operation
>This next message reaches the server, and is processed before the
previously sent abandon request.
>The previous abandon request ends up abandoning the second operation.
>
>I'm not sure yet how to fix this. If we say that:
>- a messageID cannot be reused until a subsequent bind, we limit the
number of messages between binds to maxInt.
>- a messageID of an abandoned operation cannot be reused, it limits
the number of abandoned messages between binds to maxInt.
>
>I sure wish abandon had a resonse...
>
>Jim