RE: Another problem with abandon

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

Is the URL correct? I couldn't see the quotes. I dodn't think the order of receipt of requests is related to the order of processing of the requests, and I think this is Jim's point. Naturally, this can be avoided by always processing abandons immediately. In any event, references to the connection-oriented nature of TCP are irrelevant and misleading.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Friday, 20 June 2003 12:41
To: Jim Sermersheim
Cc: ietf-ldapbis@OpenLDAP.org
Subject: Re: Another problem with abandon


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