Questions regarding handling disconnects

[terenyi]

I have a few questions concerning the behaviour of strategies when the connection is lost and then regained and concerning the related settings:

1. If NT is disconnected and then reconnects and the setting for strategies is "Keep Running" then I suppose the state (e.g. variables, etc.) of the strategy is preserved but no OnBarUpdate is called for the missing bars (i.e. OnBarUpdate is called until the last bar while NT was still connected and then form the first bar on when it's connected again). But are the data series updated after the reconnect, i.e. would Close[1] in OnBarUpdate after the reconnect refer to the bar before NT was disconnected or would it contain the value of the last "missing" bar? And what about inidcators that the strategy uses? Will they be recalculated or do they skip missing bars also (would certainly lead to strange results)?

2. What if orders were executed while NT was disconnected? Will the events (e.g. OnOrderUpdate) be fired retroactively once NT reconnects and will the status of IOrder objects be updated?

3. What if strategies are set to "Recalculate"? Will the previous state (e.g. saved IOrder objects) be lost once NT reconnects and the strategy is recalculated? And what about events? Will they be fired in the recalculated strategy if an order was executed while disconnected?

4. What happens to open orders when a strategy is recalculated? If the previous state of the strategy is lost then it can't know about open orders which might lead to uncontrolled behaviour.

5. Does the setting "wait until flat before ..." mean that the strategy position has to be flat before orders are submitted live or the account position or both?

6. Is the account position managed separately for each strategy (assuming "immediately submit live..." is set)? E.g. if strategy A is running and both the account and strategy positions are long and if I then start strategy B whose strategy position is flat, the position from strategy A will not be closed?

7. Can you tell me what would happen in the following situations (or correct me if my assumptions are wrong) so that I can understand the behaviour of NT better (SP = strategy position, AP = account position):

Assuming strategies are set to "Recalculate", "wait until flat before ..." is set and using low level order handling functions:

a. NT connected > start strategy > entry signal, submits long order > order is executed > SP=1, AP=1 > connection is lost > exit signal is missed > NT reconnects > strategy is recalculated and sees exit signal > SP=0, AP=1 > new entry signal, submits order (because SP=flat) > order is executed > SP=1, AP=2 > mismatch!

b. NT connected > start strategy > entry signal, submits long order > order is executed > SP=1, AP=1 > connection is lost > NT reconnects > strategy is recalculated > SP=1, AP=1 > exit signal > sell order is not sumbitted live because SP is not flat > SP=0, AP=1 > new entry signal, submits order > order is executed > SP=1, AP=2 > mismatch!

c. NT connected > start strategy > entry signal, submits long order, saves IOrder > connection is lost > entry order executed > NT reconnects > strategy is recalculated > IOrder still saved? OnOrderUpdate fired (e.g. to place a stop loss order)?

d. NT connected > start strategy > entry signal, submits long order > order is executed > OnOrderUpdate places stop loss order (not using the SetStopLoss function but just by placing a normal stop sell order) and saves it > connection is lost > NT reconnects > strategy is recalculated > exit signal, sell order submitted > sell order executed > can strategy still know about the stop loss order (so that it can be cancelled) or will it be executed once the stop price is hit leading to SP=0 and AP=-1?

Assuming strategies are set to "Recalculate", "immediately submit live..." is set and using low level order handling functions:

e. NT connected > start strategy > entry signal, submits long order > order is executed > SP=1, AP=1 > connection is lost > exit signal is missed > NT reconnects > strategy is recalculated and sees exit signal > SP=0, AP=1 > sell market order is generated to sync AP to SP?

f. NT connected > start strategy > entry signal, submits long order > order is executed > OnOrderUpdate places stop loss order (not using the SetStopLoss function but just by placing a normal stop sell order) and saves it > SP=1, AP=1 > connection is lost > exit signal is missed > NT reconnects > strategy is recalculated and sees exit signal > SP=0, AP=1 > sell market order is generated to sync AP to SP? (is OnOrderUpdate fired?) > stop loss order still active (leads to AP=-1 once the stop price is hit, stop loss order should have been cancelled in OnOrderUpdate when exit order is executed)?

Basically I want my strategies to behave as in case e but I want to avoid the following scenario:

g. NT connected > AP=0 > start strategy > generates historical buy order > SP=1 > buy market order triggered to sync AP to SP > market is being "chased"

I could prevent my strategy from placing entry orders on historical bars but that would then cause this:

h. NT connected > start strategy > entry signal, submits long order > order is executed > SP=1, AP=1 > connection is lost > NT reconnects > strategy is recalculated > no entry order on historical bars > SP=0, AP=1 > position closed to sync AP to SP

I.e. postitions would always be closed once NT is disconnected and then reconnects.

8. Is there any way I can enumerate open orders associated with a strategy (even if they were generated by a previous strategy instance)?

9. Can I somehow access the account position in a strategy (to check if it matches the strategy position)?

10. Could I save data (e.g. IOrder objects) in some global (static) variables once NT is disconnected (using OnConnectionStatus) and then load these values in the new (recalculated) strategy instance? Would the IOrder objects still be valid?

I hope you can clarify and have suggestions for these problems.

[Jetjockey737]

Hi terenyi,

we have tested many strategies on Ninja7 on demo so far, and we have exactly the same problems as you, i couldn't have it explained better on my own.
On friday we opened a thread concerning these problem's ( synchronisation problems........).
we are more than curios about ninja answers to your exhaustive questions.
but in our opinion the only thing if really works, if you want to have real money managed solely by a strategy, and you wan't to sleep well in the meantime, is what you considered at point 9.
you must have the possibility to check the actual account position against your strategy position whenever you want to. Thats the only way to make sure that both connections are always synchronized.
if ninja is not willing to provide this possibility ( the appropriate function call ) there is no way to let a strategy run unattended with real money.

best regards,

jetjockey

[terenyi]

I think I found a way to get some info (might not be officially supported though):

[FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff][SIZE=2][FONT=Courier New][COLOR=#0000ff]for[/COLOR][/FONT][/SIZE][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Courier New][SIZE=2][FONT=Courier New][SIZE=2]([/SIZE][/FONT][/SIZE][/FONT][FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff]int[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Courier New][SIZE=2][FONT=Courier New][SIZE=2] i=[/SIZE][/FONT][/SIZE][/FONT][FONT=Courier New][SIZE=2][COLOR=#800080][FONT=Courier New][SIZE=2][COLOR=#800080][FONT=Courier New][SIZE=2][COLOR=#800080]0[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Courier New][SIZE=2][FONT=Courier New][SIZE=2]; i<Account.Positions.Count; i++)[/SIZE][/FONT]
[SIZE=2][FONT=Courier New]Print(Account.Positions[i].ToString());[/FONT][/SIZE][/SIZE][/FONT]

This should list all open (live) positions of the current account.

[FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff]for[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Courier New][SIZE=2][FONT=Courier New][SIZE=2]([/SIZE][/FONT][/SIZE][/FONT][FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff]int[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Courier New][SIZE=2][FONT=Courier New][SIZE=2] i=[/SIZE][/FONT][/SIZE][/FONT][FONT=Courier New][SIZE=2][COLOR=#800080][FONT=Courier New][SIZE=2][COLOR=#800080][FONT=Courier New][SIZE=2][COLOR=#800080]0[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Courier New][SIZE=2][FONT=Courier New][SIZE=2]; i<Account.Executions.Count; i++)[/SIZE][/FONT]
[SIZE=2][FONT=Courier New]Print(Account.Executions[i].ToString());[/FONT][/SIZE][/SIZE][/FONT]

This should give a history of all (live) executions in the current account.

[FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff]for[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Courier New][SIZE=2][FONT=Courier New][SIZE=2]([/SIZE][/FONT][/SIZE][/FONT][FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff][FONT=Courier New][SIZE=2][COLOR=#0000ff]int[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Courier New][SIZE=2][FONT=Courier New][SIZE=2] i=[/SIZE][/FONT][/SIZE][/FONT][FONT=Courier New][SIZE=2][COLOR=#800080][FONT=Courier New][SIZE=2][COLOR=#800080][FONT=Courier New][SIZE=2][COLOR=#800080]0[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Courier New][SIZE=2][FONT=Courier New][SIZE=2]; i<Account.Orders.Count; i++)[/SIZE][/FONT]
[SIZE=2][FONT=Courier New]Print(Account.Orders[i].ToString());[/FONT][/SIZE][/SIZE][/FONT]

This should give a history of all (live) orders (both working and completed) of the current account.

However, all positions/executions/orders are listed and not only those tied to a specific instrument or strategy. So these lists would then need to be filtered to find out what the account position is in regard to a specific strategy and instrument.

[NinjaTrader_JoshP]

terenyi,

1. When you get reconnected you do not get the missing bars populating into the chart all of a sudden. You just continue as if nothing happened. So [1] will be the bar before you disconnected. You would have to reload your historical data to repopulate the missing bars and that would instigate a recalculation of your whole strategy.

2. IOrders start afresh.

3 and 4. Recalculate behavior depends on WaitUntilFlat or ImmediatelySubmit. If you have it WaitUntilFlat, then it will cancel all non-terminal orders previously generated by the strategy and your IOrders will start anew. If you have ImmediatelySubmit, it will try to match your prior orders to the newly calculated IOrder orders. If there are any orders that can't be matched, they will be cancelled.

5. The setting is for the strategy position only. The strategy position needs to cross a flat state before the strategy will trade live.

6. The account position is not managed separately. It is one overall account position. If you start Strategy B as flat the account position of long will not change. The account position is the overall position of all your strategies and trading combined. Strategy A could be long, strategy B could be short causing account position to be flat.

7. The behavior here for all of these depends on if you have "Sync account position" set to true or false.

a. If sync=false, you could have the mismatch you see. If true, as you reconnect it will close that AP=1 to AP=0.

b. If sync=false, mismatch as you stated. If true, account position is closed so it will wait for the flat to be reached and there will be no problem once strategy reaches SP=flat.

c. Depends on the state of the order when recalculated. If it recalculates as if it got filled then you have the same problem as in B if you are using sync false. If you are using sync true, it will just close that filled AP and wait for SP to be flat.

d. When you use WaitUntilFlat, it will cancel non-terminal orders so that stop loss order you may have placed will be cancelled.

e. If sync=false, you have a mismatch. If sync=true, a market order to deal with the difference will be sent to match your AP to your SP.

f. Not sure what you mean by reconnecting sees the exit signal. SP would not be 0 if there was still an exit signal in place so you should never run into this situation. Once SP=0, there is no more exit signals that could lead to -1.

g. You would want to use WaitUntilFlat if you do not want it to generate historical matchings.

h. You should not use Recalculate and should use KeepRunning then. KeepRunning will allow you to keep your AP intact.

8. You would have to hold onto all your IOrder references to do this.

9. Unfortunately there is nothing to check the account position.

10. That would be beyond the level of support we offer. Generally speaking though, those IOrder references would not be valid on a reconnect as a recalculated strategy could yield different trades. Believe you could still use that type of information to know the trades you had prior to the disconnect/reconnect, but they would not necessarily match back to any of the strategy's new state or orders.

[terenyi]

Thanks a lot for your comprehensive answer Josh! That helps me to understand the behaviour of NT better so I then can decide what settings would work best and what other measures need to be taken.

Just to clarify:

I. All open orders are cancelled when using WaitUntilFlat? What about when using ImmediatelySubmit? I do not want my AP to be synced to flat with ImmediatelySubmit and then still have other orders (take profit, stop loss, pyramiding entry, etc.) still alive.

This is what I meant in case f). If a strategy is recalculated after the reconnect it could see an exit signal among the previously missing bars and submit an historical exit order, causing the SP to be flat. But the AP would still be long so ImmediatelySubmit would cause that position to be closed. However, if there is still a stop loss order in place (if it wasn't cancelled by ImmediatelySubmit), it could cause AP to go short once the stop price is reached.

II. Are events (e.g. OnOrderUpdate) fired retroactively (once reconnected) when an order was executed while disconnected? (I guess this only makes sense when using KeepRunning as the variables of the strategy would probably not contain the right data to handle the event when using Recalculate.)

Obviously, what I'm trying to accomplish is having a strategy run by itself while making sure no unexpected things are going to happen on a live account while I'm away. Since disconnects do occur, the strategy must be able to handle them. So the question is now whether to use KeepRunning or Recalculate. KeepRunning keeps the strategy state intact so it should not cause any mismatches between AP and SP but the missing data could mess up the strategy behaviour, e.g. miss exit signals, etc. (bad). Recalculate makes sure all data is being used, however it will most certainly lead to some kind of mismatch between the AP and SP (worse) when using WaitUntilFlat. Using ImmediatelySubmit should take care of missed exits (good) but would also chase the market on missed entries (bad). So now I'm trying to figure out how to only do the one thing and avoid the other.

[terenyi]

One more questions. You said (in reference to cases b and c)

If true, account position is closed so it will wait for the flat to be reached and there will be no problem once strategy reaches SP=flat.

and

If you are using sync true, it will just close that filled AP and wait for SP to be flat.

If it has to wait for SP to be flat, it means that the SP is still long. But if the SP is long, then it matches the AP so why would the sync close the AP when the strategy is recalculated?

[NinjaTrader_JoshP]

terenyi,

I. When using ImmediatelySubmit it will try to match non-terminal orders (like your profit target, stop loss, etc.) to working orders held at your account. If it cannot match them then it will cancel unmatched account orders.

II. No, you will not get "retroactively" triggered events.

You could try using OnConnectionStatus() and programming in some of your own handling to try and help prevent "chasing".

When using WaitUntilFlat, it will always flatten the AP because the strategy only starts live trading from a flat state. Just because SP=AP, it is still waiting for SP=flat. If AP did not start flat, the strategy would become out of sync once the strategy goes live on an SP=flat.

[terenyi]

Thanks again!

Although I'm a bit confused now. I thought we were talking about the behaviour of SubmitImmediately when you said

If you are using sync true, it will just close that filled AP and wait for SP to be flat.

But in your last post you said

When using WaitUntilFlat, it will always flatten the AP because the strategy only starts live trading from a flat state.

So what will NT do if I have let's say AP=1 and (historic) SP=1 too. Will WaitUntilFlat flatten the AP immediately and then wait for SP=0 before submitting live orders again? SubmitImmediately should leave the AP untouched since it matches the SP?

And if SP=0 and AP=1 then WaitUntilFlat will do nothing (which will probably lead to inconsistencies later) while SubmitImmediately will close the AP?

And if it's the other way around, SP=1 and AP=0 then WaitUntilFlat will do nothing again and will also not submit a sell order live (which leads to SP=0 but leaves AP untoched and from then on orders are placed live), while SubmitImmediately will open a new AP?

This is all kind of complicated. But I really need to understand the behaviour of NT (and I'm sure others too) so that I can react accordingly.

Hm, if OnOrderUpdate is not triggered "retroactively" for orders which were executed while disconnected, then it will be difficult to implement bracket orders. I guess I'd have to check in OnConnectionStatus if there had been any executions.

Even though I won't get an OnOrderUpdate for orders which were executed while disconnected, will NT still know about that execution? I.e. if I go through Account.Executions, will that execution be in there?

When will OnConnectionStatus be triggered once NT reconnects? Before or after the strategy has been recalculated (i.e. before or after all OnBarUpdates)? Will OnConnectionStatus be called on the old or new strategy instance?

One other thing I have noticed: Does SubmitImmediately not work with Sim101? (Have only tried it with Sim101 and not a live account yet, so I don't know if it works there.) Because even though I set the options accordingly and both StrategySync and StrategySyncGlobal read SubmitImmediately, the historic SP (long 1) was not synced (leaving AP flat). Once the exit signal came, a live order was submitted (to Sim101), leaving SP flat but AP short. I have noticed that the property SyncAccountPosition was set to false. I had to explicitly set it to true in Initialize and then the sync worked. Does only Sim101 or do all accounts behave like this?

[NinjaTrader_JoshP]

So what will NT do if I have let's say AP=1 and (historic) SP=1 too. Will WaitUntilFlat flatten the AP immediately and then wait for SP=0 before submitting live orders again? SubmitImmediately should leave the AP untouched since it matches the SP?

Yes, WaitUntilFlat will flatten it immediately and wait for SP=0. Yes, ImmediatelySubmit will not touch AP since it equals SP.

And if SP=0 and AP=1 then WaitUntilFlat will do nothing (which will probably lead to inconsistencies later) while SubmitImmediately will close the AP?

No, WaitUntilFlat will flatten AP to 0. ImmediatelySubmit will submit a market order to reconcile AP to SP as well.

And if it's the other way around, SP=1 and AP=0 then WaitUntilFlat will do nothing again and will also not submit a sell order live (which leads to SP=0 but leaves AP untoched and from then on orders are placed live), while SubmitImmediately will open a new AP?

Yes, WaitUntilFlat will do nothing. Sell order will be a virtual trade and would only close SP to 0. AP remains zero till SP reaches 0. ImmediatelySubmit will indeed open a new AP.

Even though I won't get an OnOrderUpdate for orders which were executed while disconnected, will NT still know about that execution? I.e. if I go through Account.Executions, will that execution be in there?

Account.Executions is beyond what we support, but I do believe you will see it there.

When will OnConnectionStatus be triggered once NT reconnects? Before or after the strategy has been recalculated (i.e. before or after all OnBarUpdates)? Will OnConnectionStatus be called on the old or new strategy instance?

OnConnectionStatus() is triggered on connection loss and reconnection. Believe it triggers right as the connection is establish. If you were to use this I would imagine it would work best with using KeepRunning and that would be the same instance.

One other thing I have noticed: Does SubmitImmediately not work with Sim101? (Have only tried it with Sim101 and not a live account yet, so I don't know if it works there.) Because even though I set the options accordingly and both StrategySync and StrategySyncGlobal read SubmitImmediately, the historic SP (long 1) was not synced (leaving AP flat). Once the exit signal came, a live order was submitted (to Sim101), leaving SP flat but AP short. I have noticed that the property SyncAccountPosition was set to false. I had to explicitly set it to true in Initialize and then the sync worked. Does only Sim101 or do all accounts behave like this?

Please see your Control Center log for the line that says starting NinjaScript strategy. It will outline what the account position is and the strategy position is as you started. Sim101 works just the same as other accounts and should be synced if sync is true.

[terenyi]

Thanks a lot again for your reply! I think I start to understand.

So far my conclusion is that I can't use KeepRunning for my strategies as this could mess up the calculations because of missed data. I also can't use WaitUntilFlat because that would always close an open position when a disconnect/reconnect occurs. So I have to use Recalculate and ImmediatelySubmit.

Recalculate has the downside that the state of my strategy is lost, but I think I should be able to reconstruct it by saving data to somewhere (e.g. global vars) when the connection is lost and then reloading it in the new strategy instance (I will experiment to find out how OnConnectionStatus behaves exactly). Another problem are missed OnOrderUpdate events (bye-bye event driven programming), but I think I can extract the necessary information by examining the data in Account.Executions, Account.Orders, etc. after a reconnect.

The downside of ImmediatelySubmit is that the market would be chased if a position is opened during the "missing" bars. I think I can avoid that by remembering from when to when the strategy was disconnected and not generate any entry orders during this period when the strategy is recalculated.

I hope I don't annoy you too much, but I have one more question regarding the synchronization of orders (assuming ImmediatelySubmit is being used):

Does it only work one way (i.e. account orders are cancelled if no matching historic strategy orders are found) or both ways (i.e. new account orders are placed if there is a historic strategy order but no matching account order)?

And how are orders matched and are account orders updated? Assume I have a stop sell order (both in the strategy and in the account). Then NT disconnects/reconnects and the strategy is recalculated. Processing the data of the missing bars causes the strategy to move the stop order to a different price. So when it's time to sync the AP and SP, the are both let's say long and both have a sell stop order active. However, the difference is that the orders are at different prices since the strategy order was updated. What will NT do now? Will it update the account order to match the price of the strategy order?

Sim101 works just the same as other accounts and should be synced if sync is true.

But sync was set to false by default (even though NT was configured for ImmediatelySubmit) and I had to explicitly set it to true in my code. That's why I was wondering. BTW: What happens if StrategySync is set to ImmediatelySubmit but SyncAccountPosition is set to false?

[NinjaTrader_JoshP]

terenyi,

What it tries to do is bring the account position in line with the strategy position. If there are open account orders that can be matched to strategy orders then those will be kept. Otherwise they will be cancelled. Any active strategy order that does not exist in the account will be submitted to the account.

In your scenario, since it was unable to find an exact match, the account order is cancelled and a new one is placed with the new price.

Choosing to sync your account or not for the strategy needs to be decided prior to running the strategy either from code or through the strategy selection UI. If you have it not to sync account position it will not do any of the reconciliation action I have been discussing. It will just carry on assuming you had the account position synced beforehand. Basically, 6.5 behavior.

[terenyi]

Thanks a lot, I think I finally understand.

I missed that StrategySync can be set in the UI as well. So if StrategySync = false then NT will do nothing. It it's true, NT will try to synchronize the AP and SP. How it will do that exactly depends on if ImmediatelySubmit or WaitUntilFlat is set. Right?

And ImmediatelySubmit will always make sure that both the positions (by submitting market orders if necessary) and the orders (by cancelling and/or submitting new orders) are the same.

The only difficulty is that the IOrder objects in the strategy probably refer to the historic orders (which were never submitted live) and not to the actual orders that the sync mechanism created. So I guess I have to update these objects myself by looking for the real ones in Account.Orders, right?

BTW: When the connection is lost, an always on top window pops up (in addition to generating an alert) which must be closed by the user. It might make sense to inform the user if he is sitting in front of the computer, but if the strategy is running unattended then I think the log entry and alert email are enough and having 100 windows open when returning to the computer might be a bit annoying. So maybe the message window could close itself once the connection is reestablished. Just my two cents though.

[terenyi]

A few more little questions (I ask because I don't really want to experiment with these things on my live account):

1. When the sync mechanism creates a new account order (because there is an historic one in the strategy), will the IOrder object in the strategy (so far referencing the simulated order) be updated to refer to the live order? I thought this might be the case since the document about the code breaking changes says

Do NOT hold onto .Token values since they will change as the strategy goes from historical to live.

2. What happens if there is already a matching order in the account (i.e. no new order needs to be created)? Will the IOrder of the strategy be updated to refer to the live order?

3. What fields must match so that the sync mechanism considers an account order and a strategy order to be the same? Do they have to have the same name too? If yes and if (1) is true, then using different order names would force the old account order to be deleted, a new one to be placed and most importantly it would update the IOrder object in the strategy.

4. I have noticed that no events (OnOrderUpdate, OnExecution, ...) are generated when the sync mechanism places orders, opens/closes positions, etc. But I suppose if orders, which were originally placed by this mechanism, are later executed, an event will be generated in the strategy as normal?

Thanks!

[terenyi]

Oh another question:

When data is reloaded to get the missing bars after the reconnect - I guess that's what's supposed to happen, although it doesn't seem to be working, see my other thread -, is only the missing data pulled from the historical data source (and all other data stays the same as it was recorded while NT was connected live) or will a complete reload of all historical data on the chart be performed (which might lead to the strategy running differently even on bars that were not missing as there might be slight differences in historical data and data that was recorded while just being connected live)?

[NinjaTrader_JoshP]

The only difficulty is that the IOrder objects in the strategy probably refer to the historic orders (which were never submitted live) and not to the actual orders that the sync mechanism created. So I guess I have to update these objects myself by looking for the real ones in Account.Orders, right?

Not sure why you would need to update historical IOrder objects at all. As the strategy starts up and recalculates it would only need to sync up what is currently held as an open position or order.

BTW: When the connection is lost, an always on top window pops up (in addition to generating an alert) which must be closed by the user. It might make sense to inform the user if he is sitting in front of the computer, but if the strategy is running unattended then I think the log entry and alert email are enough and having 100 windows open when returning to the computer might be a bit annoying. So maybe the message window could close itself once the connection is reestablished. Just my two cents though.

Thanks for the suggestion.

1. When the sync mechanism creates a new account order (because there is an historic one in the strategy), will the IOrder object in the strategy (so far referencing the simulated order) be updated to refer to the live order? I thought this might be the case since the document about the code breaking changes says

That is correct.

2. What happens if there is already a matching order in the account (i.e. no new order needs to be created)? Will the IOrder of the strategy be updated to refer to the live order?

Correct. In the sync process it will try and map trades back to the account.

3. What fields must match so that the sync mechanism considers an account order and a strategy order to be the same? Do they have to have the same name too? If yes and if (1) is true, then using different order names would force the old account order to be deleted, a new one to be placed and most importantly it would update the IOrder object in the strategy.

Believe it needs to be a 100% match.

4. I have noticed that no events (OnOrderUpdate, OnExecution, ...) are generated when the sync mechanism places orders, opens/closes positions, etc. But I suppose if orders, which were originally placed by this mechanism, are later executed, an event will be generated in the strategy as normal?

Sync orders are placed outside of the strategy. If they were placed within the strategy they would change the SP which is not desired.

When data is reloaded to get the missing bars after the reconnect - I guess that's what's supposed to happen, although it doesn't seem to be working, see my other thread -, is only the missing data pulled from the historical data source (and all other data stays the same as it was recorded while NT was connected live) or will a complete reload of all historical data on the chart be performed (which might lead to the strategy running differently even on bars that were not missing as there might be slight differences in historical data and data that was recorded while just being connected live)?

To clarify, as you are reconnected, there is no reloading of historical data. Recalculating the strategy just allows it to reestablish itself to the current data shown on the current chart. If you want the missing information you need to do a reload of the data and that would be a complete reload. There is no way to only reload the portion of data you are missing.