RE: Another problem with abandon

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

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