API - InterActive Brokers - (Using Silverlight)

UniversalGoldmine

Junior member
Messages
26
Likes
0
Hi,

I have got 2 .DLL files from InterActive Brokers that supports the Language C++, C# and VB. The 2 DLL files is the API to have the ability to call their functions.
* AxInterop.XLib.dll
* Interop.TWSLib.dll

I do my coding in C# using Silverlight 3.0 and are trying to add these 2 .DLL with "Add reference"
When I add those .DLL files, I get this error message:

"You can´t add a reference to AxInterop.XLib.dll as it was not built against the Silverlight runtime. Silverlight projects will only work with Silverlight assemblies"

I do understand the errormessage but my question is if there really aren´t any solution to use these .DLL with my Silverlight project and I also are open for workaround solutions in order to use the functions that those .DLL provides. Also I wonder if Interactive do have .DLL:s that directly will work with Silverlight or any other solution for Silverlight ?

Thank you!
 
Pardon me if I haven't really understood your problem, but basically you want a silverlight app to be sending orders to IB ? not sure this is the right way to go here.
A better approach would be to use silverlight as it is supposed to, ie, a lightweight Web compatible UI, and have a back end server (in proper C#) that is the one who is going to be sending orders. The silverlight part is only going to be displaying what is happening (what the server tells it is happening) and sending commands to the server.
That way your server will be fully compatible with the Dlls, is written in a way that will probably be much more reliable, and, why not, could be located very close to the exchange so as to optimize the order round trip (at the expense of UI reactivity).
You will probably have much less difficulty making a silverlight app communicate with a C# backend rather than trying to force an Interop library into silverlight (my 2 cents).
Also, just for information, you might want to check out http://www.dinosaurtech.com/2009/9-6-3-14-release-bug-fix-release/ , the guy is offering an IB API in .net (which *might* be a bit more usuable than Interop libraries).
Good luck
 
Thank you for your response.
>> but basically you want a silverlight app to be sending orders to IB ?

Yes, that is what I am truly looking for. The thing is that I am making an application in Silverlight that has a lot of functions and what now is missing, is to be able to send orders etc to IB. I have thought about a wcf as you mention at serverside but the problem might start here:
Later on perheps, say 100 persons or more will use this application and what I then wonder is that everyone will communicate with this very same server to get updateinformation etc using the .DLL:s.

I am thinking of that this will be a pressure on the server. Say that all these people want to do a historical backfil for 1000 symbols and 500 bars back at the same time. Here I am not sure if the data will go from IB - Server - Client or from IB - Client directly ?

So to have the ability to not use a server and rather have the client to only be dependent on his/her own computer would be the optimal of all.
So I might really wonder again if there really isn´t any solution for this in any way with Silveright. It suprises me a little if this isn´t possible.

I downloaded the fix-release from the link and red the "Release Notes" but did not understand if this release could be any kind of solution for Silverlight as you mention: "(which *might* be a bit more usuable than Interop libraries)."

Thank you again...
 
Last edited:
A server can easily (if done properly) accommodate hundreds of clients in terms of connection.
In terms of backfill, you should probably look at caching the data, ie whatever comes from IB should only be requested once, and kept in memory, so that if another client asks for the same data it will not request IB again.
Of course, that goes without saying, you should avoid any verbose format when transferring data, so xml is way out of the question.
What I would recommend, is for you to implement a proper multithreaded server (using a tcp/ip engine with IOCompletionPorts for handling the clients), use Protocol Buffers (Google's own serialization format for internal communication), and have the Silverlight clients be only "very light" clients, ie only presentation. You will then be able to scale according to the number of users (by adding more servers, more ram) instead of hoping the IB servers will scale for you (which they probably won't, IB will probably be a bit wary of you providing direct access to their servers to hundreds of users like that).
If data caching is too much for even a RAM overcharged server, I would probably try to store all historical data in a time series database, for example, I have had success with Db4o (a free object oriented database) in terms of query time (a second for 6 months worth of raw tick data, will be much less if you also compress it (in bars for instance).
Silverlight is a technology that has been made for one specific purpose (ie presentation, light clients), trying to make it do anything else is usually asking for troubles (that is why they insist you cannot do with it *everything* that you can with C#).
It is only my advice to you.
I can't comment on whether the API for IB that the guy publishes works with silverlight, I have never tried it like that (and I never will, for the reasons explained above).
All in all, it feels like you are embarking on a potentially large scale project and I can only stress (by experience, I develop algorithmic trading software for investment banks for a living) how important a good architecture is from the very beginning (like using the right tools for what they were meant t be used, leveraging as much as possible from all the technologies available).
 
Thanks for your answer again, it was really informative.
I think I need to think of how I can make the best out of the situation with your info in mind and also perheps other solutions too.

Thank you again for your help, alexis_michel
 
Top