Hello Patrick, On 07.06.2013, at 16:37, Patrick Ohly <patrick.o...@intel.com> wrote:
> Couldn't the ordering of statuses be enforced by queuing the response of > commands which complete out of order, without forcing the strict > ordering of command execution? I'd say yes - as long as the statuses arrive in the order the commands were sent, the peer doesn't see in what order the commands were actually executed. However, there are tons of edge cases to consider, especially for split message commands (<moredata/>) and multi-message issues in general. The SyncML state machine was already a mess in the specs, and got even more so by all the workarounds for peers that didn't work correctly (or interpreted the weak specs differently) in one or the other case. So while out of order execution and re-ordering statuses afterwards is certainly thinkable, I don't have a firm idea how difficult that would be to implement without breaking compatibility with all the weird peers out there. My general feeling is: more complicated than it looks on the first sight. > Anyway, I tried with "<strictexecorder>no</strictexecorder>" in the > remote rule for SyncEvolution. That had the desired effect of processing > all <Add> commands in a message. > > However, client and server then got confused about whether the session > had ended. I'm not surprised :-( Finding out if the session has ended or not is one of the most messy aspects of the state machine, and you'll even find some heuristics like counting Alert 222 commands to end a phase even if the state machine would think it should continue. > The server expected another message whereas the client closed > the connection, leading to an error in SyncEvolution's message > transport: [...] > I am a bit at a loss stepping through the client and server states here > that led to this situation. Lukas, can you help? I looked through the logs, but can't see right away what's going wrong. I'd guess that the problem is the updating of the fNeedToAnswer flag, which does not get properly set or reset due to the out-of-order execution. The basic mechanism is that the flag gets set in TSyncSession::issuePtr() whenever a command is issued which is not the OK-SyncHdr-Status, or in ContinuePackage() if a bracket command (<Sync>) was interrupted and must be continued. The flag is unconditionally reset when a new message starts processing. Depending on the changed order of events when executing commands in different order, that's probably not sufficient logic. Best Regards, Lukas Zeller _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
