RE: Another problem with abandon

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:56 PM 6/19/2003, Ramsay, Ron wrote:
>Is the URL correct?

The URL is for the top of the thread.

>I couldn't see the quotes.

They are actually from:
  http://www.openldap.org/lists/ietf-ldapbis/200211/msg00010.html

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

Or by tracking the order in which operations were received so that
the abandon request will act upon the appropriate operation.  Or
by a number of other approaches.

Basically, the semantics of the abandon are tied to the ordering
of requests from the client.  The abandon operation requests that
a previously sent operation be abandoned.  It would be inappropriate
to apply the abandon to subsequently requested operations.

>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