Re: CLDAP issues

[Simon E Spero <[e-mail]>]

I don't think I've explained myself very well; maybe an example will 
clarify  where I think the problem is.

We'll construct a hypothetical query 'Q' which has 3 matches; 'r1' 'r2' 'r3'.
At the message level, the transaction looks like this. We'll use message-id
101.

Origin				Target
------				------

{101,Q}   --------------------->
	  <--------------------- (101,r1)
	  <--------------------- (101,r2)
	  <--------------------- (101,r3)
	  <--------------------- (101,ok)

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. 

Origin				Target
------				------

{101,Q}   --------------------->
	  <--------------------- (101,ok)
	  <--------------------- (101,r1)
	  <--------------------- (101,r2)
	  <--------------------- (101,r3)

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.

Origin				Target
------				------

{101,Q}   --------------------->
	  <--------------------- (101,r3)
	  <--------------------- (101,ok)

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. 

Simon