Re: CLDAP issues

Alan Young <Alan.Young@calibre.ch> Mon, 13 December 1993 06:06 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18867; 13 Dec 93 1:06 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18859; 13 Dec 93 1:06 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id ac05839; 13 Dec 93 1:06 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.02277-0@haig.cs.ucl.ac.uk>; Sun, 12 Dec 1993 17:13:25 +0000
Received: from calibre.switch.ch by bells.cs.ucl.ac.uk with Internet SMTP id <g.10693-0@bells.cs.ucl.ac.uk>; Sun, 12 Dec 1993 17:13:09 +0000
Received: from calibre.ch by calibre.switch.ch with SMTP (PP) id <08037-0@calibre.switch.ch>; Sun, 12 Dec 1993 18:12:26 +0100
To: Simon E Spero <ses@tipper.oit.unc.edu>
cc: ldap@umich.edu, osi-ds@cs.ucl.ac.uk
Subject: Re: CLDAP issues
Phone: +41 1 312 1648
In-reply-to: Your message of Sun, 12 Dec 93 12:06:10 -0500. <9312121706.AA00869@tipper.oit.unc.edu>
Date: Sun, 12 Dec 93 18:12:21 +0100
Message-ID: <8033.755716341@calibre.ch>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Young <Alan.Young@calibre.ch>

> I don't think I've explained myself very well; maybe an example will 
> clarify  where I think the problem is.
>
> ...
>
> However, we're using an unreliable transport protocol; if we allow different
> messages to be carried in different transport data units, then messages can be
> lost, duplicated or delivered out of sequence. Here's a few examples of what
> can go wrong:
>
> 1) Out of order message delivery. 
>
> ...
> The 'ok' message  which marks the last search response appears before the
> first search response. To the client it appears that no matches were 
> found. 
>
> 2) Lost messages.
>
> ...
> r1 and r2 are lost; only r3 is present. The client sees only one match, and 
> can't detect the loss of the packets. 


> Does this make things any clearer? I can't see any way around the problem
> without either extending the protocol or requiring all responses to a given
> request be sent in a single TPDU. 

Now I get it!  Okay, I buy it, all responses *must* go in a single
Transport PDU.

Alan.