|
Hi. I'm Jong Choi of IBM Research.
Below are the issues I found in the LCUP
draft.
<Section 4.4>
It is stated that the server SHOULD send the cookie in the entryUpdate control for every sendCookieInterval number of SearchResultEntry PDUs to the client. It seems not clear whether this applies to synchronize as well as persist.
(Below, I assumed RUV (as in section 7) as the cookie.) In the case that RUV is returned to the client periodically during a synchronize session, it may not have much
meaning unless the returned entries are sorted
(as in size limit case in section 7).
Otherwise, upon error during a synchronization session, the next synchronization should restart from
the RUV before the failed synchronization not from the last received RUV before error.
If this is the case, periodic delivery of cookies during a synchronize section may be
meaningless.
<Section 4.5>
The contents of this section seems to be applied to persist scenario only. The synchronization case need to be considered as well in this discussion. <Section 4.6>
> If server resources become tight, the server can terminate one or > more search operations by sending a SearchResultDone message to the > client(s) with a resultCode of lcupResourcesExhausted. Unless the > client sets the updateType field to persistOnly, the server attaches > a clientUpdateDone control that contains the cookie that corresponds > to the current state of the client's data. A server set policy is > used to decide which searches to terminate. This can also be used as > a security mechanism to disconnect clients that are suspected of > malicious actions, but if the server can infer that the client is > malicious, the server should return lcupSecurityViolation instead. Does synchronizeAndPersist become the same as
persistOnly
after the latter finishes the initial priming
?
Hence, we need to distinguish whether a synchronizeAndPersist in the initial mode and in the change notification
mode
to be able to terminate synchronizeAndPersist in the initial mode only. On the other hand, it may be required for the
server to terminate
persistOnly or synchronizeAndPersist in the change
notification mode.
If there are too many persist searches to take care
of upon modification,
it may be required to terminate some of them to limit their performance impact. <Section 4.9 and the following paragraph from
Section 7>
> An implementation must make sure that it can correctly update the > client's cookie when there is a size limit imposed on the search > results by either the client's request or by the server's > configuration. If RUV is used as the cookie, entries last modified > by a particular master must be sent to the client in the order of > their last modified CSN. This ordering guarantees that the RUV can > be updated after each entry is sent. It seems that the above paragraph also holds when a
time limit is imposed.
A possible issue with the time limit is that the time to sort the result set may be larger than the time limit itself. The sorting may also be required when we decided to cope with errors during a synchronization session in such a way that avoids restart from the pre-session state. <Section 5.1>
The issue of leftSet change type in the triggered search change type support needs to be brought out to the general discussion of how to maintain the convergence. <Section 7>
It is said that an LDUP compliant server can notify the client of the deletion using the tombstone. It is not clear how this
notification is delivered to the client,
whether the deleted entries are automatically
delivered to a client as a part
of the resynchronization or the client has to issue
separate resynchronization
search to tombstone to get the list of all deleted
entries after the last
synchronization time. Because only a small set of
required attributes
are retained in the tombstone, it may happen that a search specification cannot match entries in the tombstone using its filter
containing non-retained attributes.
In this case, it seems that all the deleted entries
after the last synchronization
point should be delivered to the client. LCUP
clients needs to request synchronization
at least more frequently than the lifetime of the
entries in the tombstone. It would be
helpful for the server to optionally deliver this
lifetime value as a part of control,
so that the client may consider this value when deciding the synchronization interval. ------------------------
Jong Hyuk Choi IBM Thomas J. Watson Research Center - Enterprise Linux Group P. O. Box 218, Yorktown Heights, NY 10598 email: jongchoi@xxxxxxxxxx, jongchoi@xxxxxxxxxxxx (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 |