Tums, thank you. That's an important point. A few PM's verify that IB is important. I have looked at the API and will study it more closely this week to give an ETA of when to have it finished. I'll add it to the "road map" specifically. Sincerely, Wayne
Wayne - Open E Cry is the broker I use. I have had very favorable experiences with their software. While not as big as IB in terms of customer count, they may be a good brokerage house to use as they seem very interested in expanding. Their software & API is worth checking into to connect with. One could also probably use their data feed to collect DOM & tick level data. Below is some info on it: http://www.openecry.com/software/softwarehighlights.cfm Open Documentation Clients from all around the world rely on OEC One Link every day for Direct Market Access to data and trade execution. Our innovative approach to developing trading software has helped our clients achieve their objectives of speed and reliability with access to major pit and electronic markets. See how OEC One Link can take your trading to the next level by checking out the documentation below: * OEC One Link OEC API is a software component intended for development of applications accessing OEC System. Technically, it is a .NET 2.0 assembly (DLL library), which can be accessed from any .NET 2.0 enabled platform and language, such as Microsoft Visual Studio 2005, C#, C++/.NET and VB.NET. There is also OEC COM API library intended for environments, which could not access .NET directly, but supports Microsoft component object model (COM), such as C++, Delphi, VBA (Excel) etc. OEC COM API is a .NET COM Interop library and requires OEC API presence. OEC API library encapsulates network communication between client application and OEC Servers and provided object-oriented access to OEC functionality through exposed components (objects), their properties, methods and events. OEC API is a multi-threaded library and processes user requests asynchronously, but it should be accessed only from creating thread and serializes responses in form of events (callbacks) to the same thread. * OEC One Link Remoting The ability to share a single API instance among several software applications. The OEC System does not support multiple connections from the single user (login name). However, some clients use distributed frameworks for separate order and price processing. The OEC API Remote Connection avoids using a secondary login name and downloading the same data twice. Also, it does not require significant changes in the client code â so multiple client applications share the OEC API instance exactly as before. * Compiled API Documentation OEC One Link - zipped up version. * API COM Interface COM is Microsoft's Component Object Model, another technology available for building applications from binary software components to OEC. There is also OEC One Link COM library intended for environments, which could not access .NET directly, but supports Microsoft component object model (COM), such as C++, Delphi, VBA (Excel) etc. OEC One Link COM is a .NET COM Interop library and requires OEC One Link presence. * API COM Interface No Samples API COM Interface without samples. Regards, Eric
I'm curious about this one Eric and IB trading also. How well do they support/encourage automated trading? MB trading was a hassle to implement because when I had issues with a connection lost and unable to reconnect, they're answer was always... "It happens rarely, just close and reopen the software." My rebuttle was, but I'm auto trading, I'm not around to do this manually. We should be able to reestablish the connection in case of hickup. I had it working for everything I could create on my end like unplugging the network cable, etc. Anyway, it turns out MB allows this but won't provide tech support I think because they want to avoid responsibility for someone losing money while away from their PC. Anyway, does anyone know if IB or OEC is more supportive? I guess it doesn't matter really. I gotta do IB, either way. Just curious if anyone already did it or any tips. The key is to reestablish connection reliably when there's an temporary outage of any kind. Sincerely, Wayne
I think that Open E Cry is much more supportive of automated trading. They have API Samples & documentation on their site & also provide links to OpenQuant, RightEdge & Collective 2 for strategy trading. Free advertising by a broker is good right? I am not sure but OEC may be small enough to provide TickZoom with more attention & free advertising than a broker of IB's size would. Regards, Eric
Wow. You are very persuasive, Eric. Sure, that advertising, I'm sure goes both ways, since those platforms post that they support Open E Cry. I'll look at their API. In fact, it will be good to study both IB's api and OEC to compare them. Then think of the easiest way to support all of them and make it easy to plugin others along the way. Hmm. Hey, you aren't by any chance a programmer who'd like to fiddle with making that work yourself are you? Sincerely, Wayne
If you are dealing with IB (and not using FIX), then your connection is to TWS and not direct to IB servers. TWS manages reconnects in the event of network failure and does this fairly reliably. You will get notifications via the API when data connection is lost and reestablished. If any data has been lost you will be told about it. There is no programmatic control over TWS reconnection logic. So, in a way it is not an issue because there is not much you can do about it. One other thing about TWS is that it shuts down every day at a user configurable TOD. You either restart it by hand or use one of the automatic restarters that are floating around, or roll your own restarter which is not too hard in Java. In this case you will have to reestablish a connection from the API to TWS.
Wayne - At this point I don't think that my coding skills are anywhere close to what is needed for the project. I'll do the best I can but cannot promise anything worthwhile. I may have a friend that would help out that is a rockstar at this kind of stuff. He is currently writing code for something similar to the sync system in Ford cars now: http://www.syncmyride.com/#/home/ Regards, Eric
The Yahoo! user group has a number of IB auto-login bits... http://finance.groups.yahoo.com/group/TWSAPI/
It'll be tough... Learning all the Broker and Datafeed APIs... The list will keep on: Growing, growing and growing... and... once some specification changes: You get bugged by people to update them... bugging and bugging and bugging you... Just my 2 cents
You asked for examples of queries that weren't based on symbol and date. A key reversal, a large block trade or doing frequency analysis of price and/or volume all fall under that type of query. Well, the exact protocol would be provider dependent, but yes, in general terms it would be one of the following; a tick that replaces an existing one, is a new one, or an instruction to delete an errant tick. I'm under the impression that your tick stream is compressed, only deltas are saved to reduce storage requirements. If that's correct then I assume that the ability to go back and modify the tick file is going to be a bit more complex to accomplish. Okay, but be aware that some data providers have a data quality function, so you might receive data corrections well after the trading session and might end up coming days or weeks after it was originally captured. Understood. Here's an example; a walk-forward test that only trades the first hour of a regular trading session with an N-minute opening range breakout system.