RE: LCUP and PSearch on Sync-And-Persist

What is the scenario in which a client needs to do something special on
receipt of the "in sync" notification?

The only one I can see is on an "initial sync," where some clients might
want to know they have a reasonably complete set of search results as
they existed in the recent past (excepting loose consistency due to
replication latency between DSAs, etc.).  In such a case the client
could initially use a synchronizeOnly LCUP exchange with the DSA, then
switch to synchronizeAndPersist for future LCUP interactions.

The example scenario cited by Mircea -- ensuring the client has a
consistent view across many objects -- is not one that can or should be
solved through LCUP.  The solution to this problem is the use of
application versioning of objects.  Many strategies for this exist --
e.g., those detailed at
http://msdn.microsoft.com/library/en-us/netdir/ad/detecting_and_avoiding
_replication_latency.asp.

In short, I am not yet convinced that the currently specified behavior
of LCUP in this area is deficient.

-J

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email protected]] 
Sent: Thursday, April 04, 2002 10:12 AM
To: Rich Megginson
Cc: Mark C Smith; Timothy Hahn; [email protected]
Subject: Re: LCUP and PSearch on Sync-And-Persist


At 09:07 AM 2002-04-04, Rich Megginson wrote:
>"Kurt D. Zeilenga" wrote:
>
>> There are many clients which need to know they are 'in sync'.
>> I note that this is not just after the initial 'sync up' phase,
>> but subsequently.  Also, there are cases where the server
>> needs to update the cookie without sending an update (in the
>> 'persist' phase.
>>
>> I suggest that we add a 'in sync' notification to LCUP.  Basically,
>> just a (intermediate) response PDU which says "you're in sync"
>> and, OPTIONALLY, provides a new cookie.
>>
>> The server should send one when it has sent all changes necessary
>> to 'sync' the client.  The server may send them subsequently to
>> again notify the client it is 'in sync'.
>
>But what exactly does 'sync' mean?

It means that the server has sent all the messages necessary for
the client to have a complete and accurate copy of the requested
(and provided) information.

>Does this mean 'all changes between the time I last connected and the
time I connected for this
>session'?

It means all the changes necessary to have a complete and accurate
copy of the requested (and provided) information.

>Because changes may come in to the server during the sync phase.

The server may send them or queue them or possible use other
approaches.

>What should happen to these changes?  Or should those
>entries be included?  What if the server is under a heavy update load
and never gets to the end of the sync phase?

If it never reaches the 'in sync' condition, it never should sent
the 'in sync' message.

I think we should get away from this 'sync'/'persist' phase
business and look at this simply as a sequence up messages which
'updates' entries of interest.  When the sequence of updates
sent is known to reflect the server's current state (for all
entries of interest), the server sends an 'in sync' message
notifying the client of this.

The initial 'in sync' message should be sent as soon as the
all the changes necessary to be 'in sync' have be sent.
Subsequent 'in sync' messages can be sent whenever the
server desires to send them.

Kurt
Kurt