On 25.09.2014, at 08:43, Patrick Ohly <patrick.o...@intel.com> wrote:
> [...]
> Would this "save state" include resetting the sync anchor?
No.
> I can't think
> of any other way how the server could avoid duplicates, because it
> cannot know whether the client has added the items and if so, under
> which ID... except that there is also suspend/resume.
Even without suspend/resume, the client should remember unsent map commands and
send these at the beginning of the next session ("early maps") in all cases.
With these, the server will know of items actually added vs those only sent and
not added. AFAIK this "early map" even predates SyncML 1.2, but few
implementations actually used it.
> It's different on the client side because the client can detect the
> duplicate item based on the server's ID.
Yes.
>> Did you actually see such problems happeing or do you just anticipate
>> them because they *would* occur if the engine *did* abort without
>> saving state in all cases?
>
> I've seen it happen in the the case that I described (message sent with
> several <Add>s inside, server aborts before receiving a response).
Ok, so it does not work as *intended* :-/
> So the expected result is that a suspend state needs to be written on
> both sides and then the next sync must resume?
With SyncML 1.2 and both sides capable (DB-wise) of Suspend&Resume, yes.
>> The only thing I could imagine going wrong would be not to continue
>> calling SessionStep() after the STEPCMD_ABORT until SessionStep()
>> actually signals session done, because it might take another step to
>> completely clean up the session, which is needed to make all
>> datastores call saveAdminData.
>
> I need to check this on both server and client side. I suspect that
> SyncEvolution is too aggressive on the client side and doesn't let it
> finish the session normally.
>
> If STEPCMD_ABORT leads to suspend state being written and resuming the
> sync in the next session, why is STEPCMD_SUSPEND needed? My understanding
> is that STEPCMD_SUSPEND will take longer because it relies on further
> SyncML message exchanges. Does this perhaps make it more reliable?
STEPCMD_SUSPEND causes the client to send a suspend alert (explicit suspend),
whereas abort just saves the state and hopes for the other side to detect the
abort and save its state as well (implicit suspend). So STEPCMD_SUSPEND is the
more graceful way to stop a sync. In my mobile clients the stop button issues a
STEPCMD_SUSPEND when pressed the first time, and a STEPCMD_ABORT when pressed
the second time (e.g. for when network is stalled and the suspend message does
not get through).
Best Regards,
Lukas
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
