> Mircea Pana > <mpana@xxxxxxxxxx To: IETF LDUP <ietf-ldup@xxxxxxx> > 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. > 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. > > > Regards, > Mircea Pana.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature