Hello Congwu! I have a question about abort handling and hope that you remember how this was meant to work. Did we want to abort instead of sending a message that was just generated by the Synthesis engine? According to your code comment, this was the goal: //check for abort, if so, modify step command for next step. //We think abort is useful when the server is unresponsive or //too slow to the user; therefore, we can delay abort at other //points to this two points (before sending and before receiving //the data). if (checkForAbort() && (stepCmd == sysync::STEPCMD_RESENDDATA || stepCmd ==sysync::STEPCMD_SENDDATA || stepCmd == sysync::STEPCMD_NEEDDATA)) { stepCmd = sysync::STEPCMD_ABORT; } I tried to abort before sending a message via some other means (script sets a flag, flag gets checked in addition to checkForAbort()) and found that this didn't work: * SessionStep() returns STEPCMD_SENDDATA * our case statement for that starts sending, then sets STEPCMD_SENTDATA * the code above is invoked, but doesn't abort * SessionStep() is called with STEPCMD_SENTDATA, returns STEPCMD_NEEDDATA * our case statement for that waits, eventually might end up in TransportAgent::FAILED (which checks for abort by itself) or TransportAgent::GOT_REPLY (which doesn't check for abort and instead goes to STEPCMD_GOTDATA) In none of these cases does the checkForAbort() quoted above have any effect, as far as I can tell. Do you know in which case it is needed? Do we miss a check for abort directly after SessionStep and/or should the code above perhaps be moved there? -- 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.