Subject: Re: Another problem with abandon

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

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: "Jim Sermersheim" <[email-masked]>
Date: Thu, 19 Jun 2003 22:39:38 -0600

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" <[email-masked]> 6/19/03 8:41:11 PM >>>

   transports, with all 8 bits in an octet being significant in the
data
   stream.

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    

Kurt

At 11:31 AM 11/1/2002, Jim Sermersheim wrote:
>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).
>- 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.

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 20 Jun 2003 15:10:45 +1000

There were two attempts to define connectionless LDAP. I think they were both unsuccessful. Yes, there are problems. Please don't go there!

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Friday, 20 June 2003 14:40
To: [email-masked]
Cc: [email-masked]
Subject: Re: Another problem with abandon

Kurt

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 20 Jun 2003 15:36:14 +1000

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:[email-masked]]
Sent: Friday, 20 June 2003 15:16
To: [email-masked]
Cc: [email-masked]
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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 20 Jun 2003 00:03:20 -0600

A client can have knowledge of whether the update was abandoned by
abandoning the update, then rebinding (or just rebinding).

If I get a response to the update op before I get a bind response, then
the update op result tells me what happened.
If I don't get a response to the update op before I get a bind
response, then the update was abandoned. This is because the server must
either abandon outstanding ops or wait for them to complete before a
bind can be serviced.

This probably is not clear in that last sentence below. I will break it
up and clarify.

Jim

>>> "Ramsay, Ron" <[email-masked]> 6/19/03 11:36:14 PM >>>
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:[email-masked]] 
Sent: Friday, 20 June 2003 15:16
To: [email-masked] 
Cc: [email-masked] 
Subject: Re: Another problem with abandon

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

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

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 20 Jun 2003 18:09:27 +1000

Surely the rebind will abandon ALL outstanding oerations. Doesn't RFC 2251 recommend a search? In any case, I don't believe this is an appropriate use of the bind service.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Friday, 20 June 2003 16:03
To: Ramsay, Ron; [email-masked]
Cc: [email-masked]
Subject: RE: Another problem with abandon

Jim

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Friday, 20 June 2003 15:16
To: [email-masked] 
Cc: [email-masked] 
Subject: Re: Another problem with abandon

Jim

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 20 Jun 2003 08:16:43 -0600

No, RFC 2251 does not recommend a search, for at least two reasons:

1) Either the update or the search operation may be chained to a
different server(s), thus giving a false positive, or false negative.
2) Another DUA, or DSA may have changed the entry between the update
and the search.

I didn't want to suggest that clients go around using re-bind in order
to abandon operations. I just wanted to point out that it's the only
mechanism available to actually know what happened. If I could, I'd make
the suggestion that clients use the cancel operation and forget about
abandon. I can remove the whole bit about re-bind if people think it's
not useful.

Jim

>>> "Ramsay, Ron" <[email-masked]> 6/20/03 2:09:27 AM >>>
Surely the rebind will abandon ALL outstanding oerations. Doesn't RFC
2251 recommend a search? In any case, I don't believe this is an
appropriate use of the bind service.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Friday, 20 June 2003 16:03
To: Ramsay, Ron; [email-masked] 
Cc: [email-masked] 
Subject: RE: Another problem with abandon

If I get a response to the update op before I get a bind response,
then
the update op result tells me what happened.
If I don't get a response to the update op before I get a bind
response, then the update was abandoned. This is because the server
must
either abandon outstanding ops or wait for them to complete before a
bind can be serviced.

This probably is not clear in that last sentence below. I will break
it
up and clarify.

Jim

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:[email-masked]] 
Sent: Friday, 20 June 2003 15:16
To: [email-masked] 
Cc: [email-masked] 
Subject: Re: Another problem with abandon

Jim

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 20 Jun 2003 08:49:18 -0600

>>>> "Kurt D. Zeilenga" <[email-masked]> 6/20/03 8:42:22 AM >>>
>At 10:16 PM 6/19/2003, Jim Sermersheim wrote:
operation
For
to
ordering
>>of messages. 
>
>I suggest dropping the last sentence as it implies the client can
>get an indication of success of the abandon operation by issuing
>a subsequent bind operation.

Well, it can. I can crop it anyway as no one seems to find it useful.

>Also, change the "MAY" to a "may".  MAY implies that a server
>can elect to implement the abandon operation while may
>implies the server which implements the abandon operation can
>choose when to honor the request.

yes

>Likely, the "SHOULD NOT use" does not appear to be an implementation
>imperative and likely should be a "should not".
>
>And, you left "Delete" out of list of update operations.

yes and yes.

Jim