Subject: RE: Another problem with abandon

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 20 Jun 2003 13:56:50 +1000

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:[email-masked]]
Sent: Friday, 20 June 2003 12:41
To: Jim Sermersheim
Cc: [email-masked]
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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 19 Jun 2003 21:39:54 -0700

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.