Interfacing Excel 2010 (64 bit) and others to IB's TWS system
C++ Shell C Objective-C
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
bl.ocks.org @ a4a586d
build
gists
hamsterdb @ c76c20c
html
libcsv @ ea3f0be
libcsv-utils @ cdddcd8
libiconv @ 0d7057b
libjson @ 1f8c5bd
libxml @ 6e433c9
mongoose @ 0c554c6
otl @ 4a98659
tws_c_api @ 296668b
upskirt @ 95c3121
utils
xlslib @ 4e1a247
xlslib-svn
.gitattributes
.gitignore
.gitmodules
README.md
TODO
app_manager.cpp
app_manager.h
data_tracker.cpp
data_tracker.h
default.workspace
fake_hamsterdb.c
gists.html
gists.txt
interthread_comm.cpp
interthread_comm.h
json_io.cpp
json_io.h
message_queue.cpp
message_queue.h
mongoose_chat_server.cbp
mongoose_event_handler.cpp
mongoose_event_handler.h
mongoose_headers.h
mongoose_std_server.cbp
mongoose_tws_server.cbp
mongoose_utils.cpp
mongoose_utils.h
support-code.cpp
support-code.h
system-includes.h
tier2_message.cpp
tier2_message.h
tier2_message_processor.cpp
tier2_message_processor.h
tier2_message_queue.cpp
tier2_message_queue.h
tws_api_callbacks.cpp
tws_assert.h
tws_backend.h
tws_backend_io.cpp
tws_backend_io.h
tws_backend_io_logger.cpp
tws_backend_io_logger.h
tws_c_api_test.cbp
tws_callback_printf.cpp
tws_config_struct.h
tws_data_structures.cpp
tws_data_structures.h
tws_database_io.cpp
tws_database_io.h
tws_debug_printf.cpp
tws_fake_server.cpp
tws_if_main.cpp
tws_input_output.cpp
tws_instance.cpp
tws_instance.h
tws_message_base.h
tws_request.cpp
tws_request.h
tws_response.cpp
tws_response.h
tws_stocklist_loading.cpp
tws_stocklist_loading.h
unique_id_manager.h
unique_type_id.cpp
unique_type_id.h

README.md

Intent and Purposes

This application is meant to serve two purposes:

  1. interface IB/TWS with Microsoft Office Excel 2007/2010/2011/onwards via TCP (remote or local): Excel can use 'web queries' to keep its copy of the collected data up to date in 'almost real time'.

    We don't want to depend on COM or other Windows specifics as we intend to port this bugger (and the rest of the trade environment) to UNIX.

    Our experiments have shown that Excel is a very useful tool, but is a lot of bother when used as part of a real-time trade system; it's nice for analyzing data, but the trade logic and trade decisions require another type of flexibility and speed of operation, which leads us to:

  2. collect stock, etc. data, process it using public and proprietary means and derive trade decision hinting and activity from that.

    As we want a 'one click' type of user process, the easiest way to accomplish that is integrate the entire collect-analyse-advise-trade pipeline in this application, so that a user can easily control it via a web or thin application UI interface.

    The technical 'tough part' is migrating all our existing logic / glue / process to this application, while ensuring we adhere to the 'should also run on UNIX' portability requirement as closely as possible: in the end, we want to be able to run the process on both Win32/64 and UNIX platforms without any loss of functionality either way.

R & D

As we want to 'eat our own dog food' future R&D will largely be founded on top of this software; this will also ensure that we'll be able to detect (and fix) bugs at an early stage in the development process with minimal transition risk from development to production environment.

TODO / Roadmap

  • prioritizing outgoing requests, e.g. ORDERs have priority over historical data requests, and requests for recent historical data have priority over requests for older data.

  • use a priority queue for the above plus a 'idle time' delay to prevent hammering the TWS machines with historical data requests: only fire those when the interface has been 'quiet' for X seconds

  • store/cache historical data; use 'smart' code to request consecutive and large chunks of historical data to be cached: one request, served many times (from local cache)

  • async TWS TX/RX: push requests asap, using a 'telnet' TCP setting (you don't want orders to wait for a TCP buffer fill timeout!): single thread/connection connected to TWS, all requests are posted in a 'response queue' (so we know which responses are for whom) upon transmission --> true full duplex communication instead of the standard TWS sample which uses the TCP connection as a half-duplex connect (as it waits for the response to the request before firing another).

  • as you can be (almost) certain that a single TWS backend connect is handled in a single thread/task at the backend, it is opportune to have two connections open to TWS: one for scanner/historical/misc. data and one for real-time data. This should ensure that the real-time ticker data arrives ASAP at our location.