Quote from crmorris:
it's coded, been running for years. it's relatively high frequency (thousands of modifies daily). i would like to improve it -- port it to a framework that's faster, more stable, more productive.
FWIW I'm not a software engineer by profession or training. So this is more or less what I've hobbled together from friends who build automated trading systems for a living.
Operating system should not matter, just whatever is easiest given your broker API.
If milliseconds matter to you, then writing a production trading system in any scripting language (e.g. python) would be foolish IMO.
Now I think the trade-off here is building your research infrastructure in R or Python. Then your trading framework in a proper programming language. Dev time under Java will generally be faster, but you'll need to deal with GC if you're doing HF.
Now to answer your question about reliably submitting, modifying, and cancelling orders. From the sounds of things, you're doing some kind of liquidity providing strategy, as such you probably want to use an event-driven design pattern.
I think explaining everything in depth is beyond what I can type up here. However, you basically need to keep track of order states (treat it as a FSM) within your strategy class. Here's a code snippet from my system..
Code:
public void doOnNewOrderAccepted(final ClOrdId clOrdId, final OrderSpecification order) {
if (order.getTradeType() == TradeType.SELL || order.getTradeType() == TradeType.SHORT) {
this.askClOrdId = clOrdId;
this.currentAsk = order;
this.pendingAskClOrdId = null;
this.pendingAsk = null;
} else {
this.bidClOrdId = clOrdId;
this.currentBid = order;
this.pendingBidClOrdId = null;
this.pendingBid = null;
}
}
Then just build out methods for all other possible actions (e.g. doOnAsk, doOnBid, doOnFill, doOnCancelRejected) and link the logic together.
For a non HF system, it makes more sense to build out a StrategyManager then have Strategy instances talk to it. The method explained above is fairly computationally intensive.
