And yes, I openly admit I am a dick at times, but I also reiterated times and again that I am more than happy to see my statements and arguments refuted. What I do not accept and makes me throw tomatoes is arguments like "because it is this way", or "because I say so". If everyone here is as intelligent as they claim they are then they should be able to make a coherently logical argument. Is it too much to expect after all?
Well I'm not saying you're wrong, in fact I tend to agree with you. I guess we'll have to wait until OPs system go live to see whether non low latency book trading is possible. I think that should be a priority for the OP, test his prototype system in the live market ASAP before fiddling around too much the SE aspect of it.
By SE, I assume you mean Software Engineering? If that is the case, I guess I have a philosophical difference with you here. I think all ducks should be in order from an engineering perspective prior to going live, and sensitivity analysis should be conducted in fill modeling to try to get a best estimate of what to expect when the system does goes into live testing. If there are discrepancies when it does go live, the system needs to be taken off line and the source of the discrepancies understood. That being said, I do recognize nothing will ever be perfect and there is a point of diminishing returns when it comes to software engineering.
Ah, you are thinking like an engineer building a car or plane. Prototype testing in trading can be relatively cheap compared to what your time is worth. Since its not low latency just risk a few hundred bucks to get an early feel of live market behaviour.
Wine can be a bit of a pain... Ideally I prefer to avoid windows altogether, but if given the choice I rather run a windows box and share the data through a samba server or write from the windows straight into db... mixing apples and oranges only leads to strange headaches in hard to reach parts of one's head... As for "brokers who support c++ and linux", if you want to use c++ on linux boxes it is easier to find brokers who support FIX protocol and write your own parser (every trading order must be translated to FIX at some point in the way to the exchange) PS... I was under the impression that NxCore is compatible with linux... http://nxcoreapi.com/doc/concept_Basics.html
how is running some processes on windows (other than UI) and some in linux not mixing apples with oranges? And why are you still promoting the idea that the choice of brokers is a function of your technical setup rather than the other way around? Brokers (aka cost and quality of execution) are what should drive your implementation effort and not the other way around.
NxCore is not compatible with Linux. It is Dependant on windows.h . They do have a beta release API that is for Linux, but NxAccess is still windows only so it defeats the purpose of using the Linux API because it is not longer an " in memory" solution. Their technical team has mentioned to me that they are trying to put together a pure Linux solution though. As for broker, IB has a pure Linux C++ API
On the execution side of the business, FIX is the standard. If your system works through FIX it can work through most big brokers, regardless of your choice of OS. When it comes to institutional order flow, almost 100% goes through fix. Im not promoting to chose the broker based on a technical setup, Im promoting to select the technical setup where you are flexible to change to almost any broker in a heartbeat.