In my discussion in the other thread, I mentioned that I am modeling my trading system after an operating system. I view market activity (ticks, level-2 quotes, etc) as asynchronous events that are analogous to hardware interrupts that an operating system processes. The trading engine will service and hold onto the data immediately, but then schedule strategies later for the processing of information. This design requires a formalization of the interface for the strategy scheduler. The first strategy I have decided to implement is Don's Openings strategy. This strategy is unique in that it only works during a certain portion of the day. Because Don's Openings will be in a separate process, it will register itself to the trading engine every morning, but then remove itself from the scheduler's process list. Rather than maintain a registry of sorts for the various strategies, the strategies themselves will use COM functionality and find a COM server in order to register themselves. Don's Openings will be a process that is scheduled to run every morning before the market opens and will receive an interface from the COM server. Strategies that are only valid during a certain portion of the day will then remove themselves as needed. Explanation: Don's Openings, for example, may only remain resident while it is managing a position. Once it liquidates all positions, it has to remove itself and cease to waste resources in the trading engine. There's no way for the trading engine to know when Don's Openings has to be removed, so the strategy has to inform the trading engine that it is done with managing a position and remove itself. The COM server must now implement a formalized interface for adding and remove strategies. ITradingEngine: - RegisterStrategy - UnregisterStrategy - HeartBeat Register strategy will also make requests for what data it is subscribing to, as well as the frequency of invocation for that data. UnregisterStrategy should be called only when no more positions are managed; however, in the event of a critical failure, UnregisterStrategy may need a variable to turn over positions to the trading engine. The positions that are orphaned by a failed strategy will need to be cleaned up. We can close all of them, or optionally defer them to human intervention. For the short-term, we will not worry about orphaned positions, except to say that there will be options in the design to account for them. There is another situation in which orphaned positions can be created: whenever a heartbeat isn't received in a reasonable amount of time. I have not fully designed the interface for order management. I am still thinking about how to design an order management interface. For example, if I separate the order management from the trading/order-routing engine, then how should the trading engine notify order management of orphaned positions? I will be thinking about these issues over the next few days, while I rapidly crank out a prototype trading system in E-Signal and then retrofirt that strategy to work with my trading engine.
you need to read your position list every 1 min and check on the pos. that you don't know what to do if you need to be there. if not cover. happenes when you get out of a long pos. and you over sell. one more thing is to do the same for open orders to check that you don't have any open orders out there that aren't needed. and same thing here, you need to check that all orders are filled and if not filled what do you do. are you chasing the stock etc. btw, about saving data from esignal, does it get stack after DL certain amount of symbols?
I don't understand your question. "Does it get stack" => I don't parse. (Seems like English is not your native language, but if you rephrase I can try to answer.)
I finished writing some data components for Don's Openings, and will be able to test his strategy formally and get results immediately. Because his strategy has been consistent, I will likely manually put it into play as soon as the backtesting results are complete. Personally, I am looking for a simple system to finance development of this framework further. Because trading time and development time are both precious resources, I'd like to formulate a model that will cover at least some business expenses in the short-run. So, in that regard, I will be moving in this direction: - Develop workable, basic system in EFS and E-Signal - Implement bridge to core trading engine using the separate-EXE trading strategy module I talked about earlier - Replace 3rd party components with my own, better-performing components over time. I'll fit the system into my existing design and then go back and replace the 3rd party components with my own implementations. Part of the problem is the financing of the development. Because I am spending my own time and money on software development, I need to try and establish an income stream to offset fixed costs in the short-term. If I sit around and manually trade and scalp stocks, then I lose development time. If I develop, then I lose trading time. I am not working a W2 job formally at the moment, and am relying on the market for income. Balancing between trading and development has actually become a really difficult task, and my income is taking a hit. The problem is somewhat worsened by the fact that Genesis API does not allow off-hours testing and development. Time to switch to ramen noodles, wear lots of layers, and drink only water so the cash bleed is not so severe. ;-)
Oh, no. There's a symbol limit, but there's no limit on how much information you want to download from each of the symbols. So I hang around and pull down as much information as possible, but the finest resolution I can get without the program going nutso is at the 1minute bar level. The program (e-Signal) stops acting right on the tick charts, for whatever reason. E-Signal pisses me off. Their UI interface is so bad, but their data source is so good.
great thread, and it's good to see more ATS threads popping up lately; perhaps consistent with where the industry is heading... i tested an OO strategy some time ago with DTN's intraday data and came across this issue: if you use DTN's daily bars, their "open price" is a "consolidated" price, i.e. it includes ECN trading from 7am ET, i.e. it's not the open price you get in the opening auction with an OPG order (same for CSI). if you use their intraday bars, they also report a "consolidated price" including ECNs, i.e. an NYSE stock may not actually open until 9:37 ET on the NYSE but they will show bars from 9:30 to 9:37 if there were trades on ECNs. the only way to get the OPG opening price is to get the data which only includes the primary exchange. my guess would be that eSignal also "consolidates" quotes, including ECN data - how do you get around this issue (i am assuming you are using eSignal's data)?
E-Signal has a feature for filtering on one exchange for the charts. When you enter in the ticker, you can enter the filter term. So, you can restrict quote data exclusively to the NYSE.
keep up the good work, i have my own .efs indicators for scalping made in esignal that work pretty well, but i dont know how to implement them in an autotrade system to trade for me and set a stop lose and stops automattically and send the the order to a broker's interface. Programming your own C++ program is totally out of my league, i am looking for smothing that is a more intuitive.
keep up the good work, i have my own .efs indicators for scalping made in esignal that work pretty well, but i dont know how to implement them in an autotrade system to trade for me and set a stop lose and stops automattically and send the the order to a broker's interface. Programming your own C++ program is totally out of my league, i am looking for somthing that is a more intuitive. any suggestions?