Search results

The scenario you described should not happen. The broker will get all skipped FIX messages once it restores back connection to the exchange.

What exchange?

That's a good one. I'd add Tape Reading And Market Tactics by Humphrey B. Nail

I think you should see "Received logon response" in you log right after you sent logon request (35=A)

Try to remove tag 141 (ResetSeqNumFlag)

In most cases, client side FIX protocol provided by a broker far more reacher than API, and I'm absolutely sure Genesis just converts your API calls into an appropriate FIX message and sends it out to the destination exchange: http://www.gndt.com/download/Genesis_FIX_API.pdf

If you cannot connect at all, try telnet ADDRESS PORT If your side is connected, double-check sender and target IDS, and login info. The next check would be seq numbers.

I don't see anything funny here - there are some strategies that count every millisecond, and people pay big bucks to co-locate their boxes. Look at BATS for example, it took a lot of volume away from NYSE by providing blazing fast executions and market data, and a lot of alogs park their orders...

I use ACTIV Financial and quite happy with them - rock solid API (my ATS is Unix based), extremely accurate data, datacenters in Chicago and NY (Rector street), and very good market coverage. They are one of the best in this field.

AFAIK, they don't have a data center in NY/NJ, and the number of covered market centers is quite limited.

I've been using C/C++ for two decades, doing trading systems last decade, high-frequency trading systems for the last 5 years for different shops and lately for myself. I have enough knowledge in C# and Java to stay away from them in the subj, i.e. real-time data processing. Waste of time...

You must be kidding me. Faster to develop? This absolutely great philosophy! C# and Java for real-time high frequency trading systems. Hmmm... Best of luck to you guys!

Only top of book is protected, and unless you specify otherwise, the rest size would sweep the book. Think about it: why a market center would ship the rest of the order if it doesn't have to and loose commissions on an execution? Remember, commissions and market data are two major income...

Try it out :) I'd say if NBBO on bid side is on ARCA, by default you'd sweep ARCA book (scenario B) unless you use specific order type instructing what to do with the reminder (ord_size - top_of_book_size). http://www.nyse.com/equities/nysearcaequities/1157018931913.html At any rate...

The clueless one is you that have absolutely no expertise nor experience. Having 13+ years of experience in C++/high-frequency trading systems, I've build C++ high-frequency trading system by myself from the ground. It took me one full year to do that. But I know what I'm doing since I know...

I hate to state this knowing that Java-lovers would jump after me the very next second, but Java was never intended for any near real-time data processing by design. You'll be killed by garbage collections at the worst possible moments (under heavy load), not mentioning other virtual machine...

If you don't want to be disappointed later when you decide to plug-in real tick-by-tick feed instead of 1 second snapshot-based feed, forget about Java and code your system in C++ right from the beginning.

Do not mix execution platforms and market data vendors. Very often a black-box setup is FIX connection to a broker and data feed via custom API from a third-party vendor. Not many brokers give you reliable tick-by-tick data feed, and some of them may not give it via FIX. From this prospective...

150 messages/sec is a cap at IB Very few data vendors support data dissemination over FIX. FastFIX may be an option though it's not supported by IB.

As I previously stated, it really depends on the nature of your system and the issues you trade. Some systems a fine having snapshot based data, some systems require co-location and sub-ms latency for proper market-making & arbitrage. Have you ever seen tick-by-tick data for a stock doing...