Alright, lets admit that we don't have control over those. We have to act within an existing framework that we inherit. Any more thoughts?
First, what you did is crazy. The fact that you could buy but could not sell suggests the bug was in the market connection, not the trading system logic. So, you should have started manually sending limit orders far enough from the market so that they don't get accidentally executed. Then you could send an order that gets executed but do so during congestion period so that there is a good chance of breaking even if you wait for a minute or 2. Second, if you actually ARE connected directly to an exchange (I guess WinstonTJ has proved you wrong) exchanges tend to offer access to "test" servers for testing market connectivity. These work exactly like real servers except the "trades" are not real trades. All features of a market connection should be tested on such a test server before going live.
For my experience to connection my application to the ARCA servers I can say that you have to pass a certification process before you can go live. They will check if your app follows the communications (in most cases the FIX protocol) and exchange rules. If you pass that, you are allowed to access the production servers of the exchange.
no he just used simple open-source code and didn't properly debug before he compiled. don't waste your time. he is just looking for someone to tell him how to buy back the book quicker than goldman
yes... this... any true/pure DMA or direct access will require this. OP you can't "suppose" you have "constraints" If you can execute in 200ms then build a box that makes money in the 200ms space... its easy - be realistic and thats that - shooting for 5ms while you are in the 500ms space is foolish.
as you know the QA simulator exchange is crappy and you often need to massage the "send-trades-out" function in order to get a test trade filled... then when we turn back to real-exchange, we somehow changed the code, etc. so that happened... that's why we are asking for better process control...
Are you simulating or are you trading? If your programmer/s can't debug and you guys can't sort out simulation vs. real trading I don't suggest connecting to an exchange. I still have a very hard time believing that you are "directly connected to an exchange" since the cost to do that would far outweigh the cost of a decent programmer. you seem to be grasping at straws and looking for anything that will make you rich quick... Here is a good HFT strategy, simple, easy and can make a killing: Develop an envelope/spread a penny or two outside the bid/offer. When someone buys the book up you get filled... when the book fills back in use that as your out - make 1-3 cents per share and kill it... Good luck!
If you use a Liquid helium cooled josephson for your primary logic, you would be able to cut your latency enough that you would be able to beat out the colos. There is a company called E-systems that sells liquid helium cooled SQUID (150 million gate josephson logic array) systems that would meet your requirements, it requires programming in Lisp and Assembly and a Front End Processor (FEP could be a Cray running Unicos and HIPPI interconnect) The starter package (MASS-4000 series, 5 picosecond roundtrip license) with the daily liquid helium deliveries should get you going in the right direction. I forgot to add, for DASD it requires the use of TMS (Texas Memory Systems) RAMSAN's the RAMSAN-6300 which can do 14,000,000 IOPS and 140 GB/sec of sustained, random bandwidth.