My initial model I was using C++.NET extension. The extension remoted over to my external process app. This wokred very well since I was doing much historical analysis outside ANVIL process.
In my latest strategy I need performance so I natively made everything in a C++ extension dll. I do monitor about 2k equities. Orders are executed in about 100ms. Not bad considering is not a direct exchange API.
If you still want to use external app, your best perfromance is going to be shared memory.
Once you get accustomed to the messaging architecture everything starts to make sense and you extract evey bit of perfromance possible.
I do agree that it would of been better to add the API. But one thing that I like is that I can use ANVIL GUI itself as my oms system. I can see all my orders, pnl, etc ... all I have to worry about is my strategyy and order entry/exits. For exmaple, I can expire orders and positions in any exchange since I wrote the monitors into my extension.
I hook into the pump when the DLL initializes. Here is partial code:
g_AnvilHook = SetWindowsHookEx( WH_GETMESSAGE, CAnvilStatic::ANVILThreadMainMessageProcHook, NULL, g_MainThreadId );
I send WM_USER* messages from my worker threads to the main thread for ANVIL functionality, like place orders, etc ... without interferring with ANVIL processing. IT is pretty fast. All you have to make sure your code that runs on the main thread is FAST. This way your ANVIL perfroms better..
I run a gray box so I want to see it running jsut in case
. But you can use the service if you want it as black box.
ALso to run it off market hours use login: A and no password. You will not get real time data but you can load you extension and basically interact with ANVIL. It is limited but you can workout those bugs like loading DLL exception, etc...
If you are using MFC, set module state on eahc API call.
AFX_MANAGE_STATE(AfxGetStaticModuleState());
In my latest strategy I need performance so I natively made everything in a C++ extension dll. I do monitor about 2k equities. Orders are executed in about 100ms. Not bad considering is not a direct exchange API.
If you still want to use external app, your best perfromance is going to be shared memory.
Once you get accustomed to the messaging architecture everything starts to make sense and you extract evey bit of perfromance possible.
I do agree that it would of been better to add the API. But one thing that I like is that I can use ANVIL GUI itself as my oms system. I can see all my orders, pnl, etc ... all I have to worry about is my strategyy and order entry/exits. For exmaple, I can expire orders and positions in any exchange since I wrote the monitors into my extension.
I hook into the pump when the DLL initializes. Here is partial code:
g_AnvilHook = SetWindowsHookEx( WH_GETMESSAGE, CAnvilStatic::ANVILThreadMainMessageProcHook, NULL, g_MainThreadId );
I send WM_USER* messages from my worker threads to the main thread for ANVIL functionality, like place orders, etc ... without interferring with ANVIL processing. IT is pretty fast. All you have to make sure your code that runs on the main thread is FAST. This way your ANVIL perfroms better..
I run a gray box so I want to see it running jsut in case
. But you can use the service if you want it as black box. ALso to run it off market hours use login: A and no password. You will not get real time data but you can load you extension and basically interact with ANVIL. It is limited but you can workout those bugs like loading DLL exception, etc...
If you are using MFC, set module state on eahc API call.
AFX_MANAGE_STATE(AfxGetStaticModuleState());
I had used named pipes for a similar project before, so I was able to just snag the code -- they're pretty simple, and I can easily create any sort of command objects I want. Since my apps are running on the same machine, local named pipes operate in kernal mode and are very fast, but if necessary I could easily move apps to other machines without breaking the communication code (as long as I'm on the same LAN).
ostThreadmessage() to my worker thread.