Re: Another problem with abandon

["Jim Sermersheim" <jimse@novell.com>]

I second the proposal to remove the "If the LDAP session is operating
over a connection-oriented transport
   such as TCP,". Not only does it cause the problem Jurt raises, it
also leaves one wondering just how search responses are to be returned
over a non-connection-oriented transport. It makes one wonder if
different protocol elements need to be defined for when running over
non-connection-oriented transports.

>>> "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