Re: Another problem with abandon

[John McMeeking <jmcmeek@us.ibm.com>]

First,  I better say that I agree that it would simplify things if abandon
had a response.  But I don't think we're broke without a response, and some
could argue we're broke if it is added.

> If the client is multi-threading these messages, and/or the server is
> mutithreading its handling of these requests, how is the order of
requests
> determined?

Talking TCP/IP, I don't think client multi-threading affects this.  From
the server side, it seems like this requires synchronization when reading
incoming messages and keeping some kind of timestamp for each request - at
least with respect to making sure you don't abandon a later request that
reused a message id.  The server might need to serialize more processing to
make sure that when the abandon is processed, the operation that is being
abandoned is known (that is, we don't have thread 1 getting a search
request, and thread 2 getting an abandon without thread 1 having recorded
the search request where thread 2 can find it, otherwise there could be
nothing for thread 2 to abandon), but I don't think that has anything to do
with whether abandon has a response (unless you want the client to retry
the abandon) or reuse of message ids.

> Also, we need to allow for LDAP to be transferred over other transports
(like UDP)
> which don't guarantie delivery.

Talking UDP, there's more to this: messages can be received out of order
(abandon before the abandoned request), received multiple times (search,
abandon, resent search), never received.  I don't think the LDAP over UDP
draft (or my understanding of the issues associated with UDP) has
progressed to where I'd know under what circumstances message ids could be
reused even without throwing abandon into the fray.  If the "result code
cache" concept is used, it seems clear you would never want to reuse
"recent" message ids - they'd be ignored by the server as repeats.  I think
you'd be safest using increasing message ids and wrapping at maxint.  But
the "result code cache" is only mentioned as one way, not "the" way, so who
knows.

> Jim

>> John McMeeking <jmcmeek@us.ibm.com> 11/04/02 07:22AM >>
>>
>> I can see the problem, but it seems like it could be handled on the
server
>> side.  The server shouldn't abandon a request that is received after the
>> abandon request.  TCP/IP delivers these messages to the server in order,
so
>> at a protocol level, it doesn't seem like this particular problem
exists.
>> It may be worth a cautionary note to server implementors.
>>
>> John  McMeeking


John  McMeeking