Hello!
It seems that Funambol has implemented some kind of protection against
excessive slow syncs: I can do a slow sync once fine. Doing it again
shortly afterwards (say, a few seconds later, as in automated testing)
results in a 417 "retry later" status for the Alert command (in the
SyncML response message).
They have not responded to my question about this behavior, so I don't
have an official confirmation that my interpretation is correct.
This server behavior makes one (otherwise useful) feature of
libsynthesis a bit troublesome: when an app requests a refresh from
server ("forceslow" = 1, "syncmode" = 1 in the binfile client API), then
the engine will ask the server for a slow sync instead of telling it to
do a refresh-from-server. In other words, the Funambol server has to
assume the worst (a slow sync) and applies its throttling even though
the client only wants to do a relatively benign "refresh from server".
I've checked that the Funambol server does many "refresh from server"
syncs without 417. For that I patched libsynthesis:
diff --git a/src/sysync/localengineds.cpp b/src/sysync/localengineds.cpp
index ce3d034..98f15dc 100644
--- a/src/sysync/localengineds.cpp
+++ b/src/sysync/localengineds.cpp
@@ -3481,6 +3481,11 @@ localstatus TLocalEngineDS::engGenerateClientSyncAlert(
));
// create appropriate initial alert command
uInt16 alertCode = getSyncStateAlertCode(fServerAlerted,true);
+ if (alertCode == 201 &&
+ fSyncMode == smo_fromserver &&
+ true) {
+ alertCode = 205;
+ }
// check for resume
if (fResuming) {
// check if what we resume is same as what we wanted to do
Does that patch look right in principle?
The "true" part needs to be replaced with a configuration option that
chooses between old (use "slow sync") and new behavior (use "refresh
from server"). Or has enough time passed that we no longer have to care
about servers which implement slow sync, but not refresh from server?
Then we could switch to the new behavior unconditionally.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
