Subject: Re: LCUP and PSearch on Sync-And-Persist

From: "Timothy Hahn" <[email-masked]>
Date: Wed, 3 Apr 2002 22:05:00 -0500

Rich,

Two comments below - with <TJH> ... </TJH>

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

                      [email-masked]                                                                                                
                      m (Rich                  To:       [email-masked]                                                            
                      Megginson)               cc:       [email-masked]                                                             
                      Sent by:                 Subject:  Re: LCUP and PSearch on Sync-And-Persist                                      
                      owner-ietf-ldup@m                                                                                                
                      ail.imc.org                                                                                                      

                      04/03/2002 09:34                                                                                                 
                      PM                                                                                                               

>                       Mircea Pana
>                       <[email-masked]        To:       IETF LDUP
<[email-masked]>
>                       om>                      cc:
>                       Sent by:                 Subject:  LCUP and PSearch
on Sync-And-Persist
>                       owner-ietf-ldup@m
>                       ail.imc.org
>
>
>                       03/26/2002 10:25
>                       AM
>                       Please respond to
>                       mpana
>
>
>
> Both LCUP and PSearch are unclear on the order of results sent back to a
> client in case of a sync-and-persist search request. An order seems to
> be suggested but not formally recommended.
>
> If a client issues a search requests with the appropriate control and
> specifies updateType=synchronizeAndPersist (LCUP) or changesOnly=FALSE
> (PSearch), in response the server will start by sending all the data
> needed to synchronize the client. If a change occurs to an entry which
> satisfy the search criteria while the server is still synchronizing the
> client then:
> 1. the server will pause the synchronization, sent that changed entry to
> the client and then resume the synchronization
> -or-
> 2 (suggested). the server will queue the changed entry and sent it to
> the client after the synchronization is completed
> -or-
> 3. the server will ignore the change
>
> Which one of the above is recommended by LCUP / PSearch?

I'm speaking only for LCUP, not PSearch.
I think the above assumes that entries sent during the synchronize phase
are somehow different from the entries sent during the
persistent phase.  Why should the client care if either 1 or 2 is used?
For 1), why would the server have to pause?  It could
just insert the changed entry either into it's outgoing sync queue, or it
could put it on the end of the queue.  I don't think it
matters as long as the implementor has designed the server such that the
server knows exactly where it left off if the connection
is cut.  The cookie sent back to the client should contain all the
information required to resync that client, hopefully with no
overlaps.
<TJH>
I suspect there exists a "time window" where the client may not have enough
information
(yet) in order to do anything "meaningful" with the "changed entry",
depending
on where the server "inserted the changed entry" into the outgoing sync
queue,
based on what has been sent to the client so far.  This implies to me that
the
server has to be "somewhat intelligent" in when it can finally send
"changed entries"
to the client.
</TJH>

> How is a client informed that the synchronization is complete and the
> only results that it may eventually receive are changes?

I'm not sure why the client would need to know that in the LCUP case.  I
would appreciate more information about what type of
application you have that would require that information.
<TJH>
What about a client that wants to "hold off" on handling search requests
until it knows that its
information is "close" to what is held in the server?  "close" being
defined as the "synchronization"
part being done and only "updates" will be sent from here forward.
</TJH>

> Regards,
> Mircea Pana.

---

From: [email-masked] (Mark C Smith)
Date: Thu, 04 Apr 2002 10:02:01 -0500

> part being done and only "updates" will be sent from here forward.

I think this may be a valid requirement for LCUP. With Persistent 
Search, a client can tell where the stream of changes begins, but only 
after the first change is received (by looking for the presence of an 
entryChangeControl in the SearchResultEntry PDU).

-Mark Smith
  Netscape

---

From: [email-masked] (Rich Megginson)
Date: Thu, 04 Apr 2002 09:16:56 -0700

> entryChangeControl in the SearchResultEntry PDU).

Do we need to have the sync phase be completely finished before the persistent phase begins?  Or is it merely enough to know that
a returned entry is from the sync phase or the persistent phase?  For the latter, it would be easy to add another field to the
response control.  For the former, that would be much harder for server implementors to guarantee some sort of order I think.
What is the requirement?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 04 Apr 2002 09:03:48 -0800

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

Kurt

---

From: [email-masked] (Rich Megginson)
Date: Thu, 04 Apr 2002 10:07:09 -0700

> again notify the client it is 'in sync'.

But what exactly does 'sync' mean?  Does this mean 'all changes between the time I last connected and the time I connected for this
session'?  Because changes may come in to the server during the sync phase.  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?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 04 Apr 2002 10:12:10 -0800

At 09:07 AM 2002-04-04, Rich Megginson wrote:
>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

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