On Sun, 2013-06-09 at 12:59 +0200, Lukas Zeller wrote: > 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.
My idea was to use the same delayed command queue for commands that finished and those that still need to execute: when encountering a finished command in that queue, the level processing the queue would issue the status command already prepared earlier. That way correct ordering would always be guaranteed. > > 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. What exactly does "fNeedToAnswer" mean? Initially I thought it meant "my peer needs to send me an answer", because you were talking about it in the context of the server sending a message and then expecting an answer that the client doesn't send. But after looking at the code more closely, it seems to have the meaning of "I need to send my answer". Right? In that case, the flag is irrelevant on the server except for (perhaps) some state changes, because the server always has to reply to the client. The problem in my case is not that the flag is set when it shouldn't be set (or vice versa), the problem is that the server expects another message. I think the client is correct in not sending that message. The key difference in the logs is that in the normal case, the server stays in the "map" phase, while in the failure case it goes Okay: [2013-06-07 15:55:13.697] ---> MessageEnded starts : old incoming state='sync', old outgoing state='sync', NeedToAnswer <server processes Add> [2013-06-07 16:14:55.625] ---> MessageEnded finishes : new incoming state='map', new outgoing state='map', NeedToAnswer <server sends reply, stops session, and so does the client> Failed: [2013-06-07 15:55:13.697] ---> MessageEnded starts : old incoming state='sync', old outgoing state='sync', NeedToAnswer <server delays Add, sends <Alert 222> [2013-06-07 15:55:13.697] ---> MessageEnded finishes : new incoming state='map', new outgoing state='sync', NeedToAnswer <client sends Alert 222> [2013-06-07 15:55:13.777] ---> MessageEnded starts : old incoming state='map', old outgoing state='sync', NeedToAnswer <server executes delayed Add and sends their Status> [2013-06-07 15:55:13.777] ---> MessageEnded finishes : new incoming state='map', new outgoing state='map', NeedToAnswer <client quits, server continues with session => error> Looking at it like that, the question becomes: how does the server decided that it still needs an answer from the client? -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
