FIX vs. ActiveX

Oh the humanity.......

Just for clarification:

ActiveX is a term from Microsoft that simply stands for a set of technologies, built by microsoft, for COM and OLE integration. It has nothing to do with DDE or FIX. Most people think of ActiveX Controls when they talk of ActiveX, which is what the op is referring to. This simply means the control adheres to a certain set of standard interfaces that allows other components to 'talk' to it in a way it understands. Its nothing more than a small program that allows other programs to interact with it. With the advent of .NET, COM and ActiveX are being fazed out.

FIX, on the other hand, is a protocol. That is, it is a standard specification for messages to be sent to and from financial institutions. There is no technology involved in a specification, its just a layout for records and such. To interface with FIX, you will still have to use some type of component. If you don't write it yourself, then chances are, it too will be some sort of ActiveX component(if you are using a Windows environment) someone else already wrote to send and receive FIX messages.





To address your original concern, something sounds wrong on your end. Based on the very limited information you provided, it almost sounds like every time you send an order you are creating the activex object, consuming resources, connecting to the broker and then sending the order. The best solution would be to hold the object in memory once you open the connection to the broker, and then reuse that copy of the object everytime you send and order. Again, Im just guessing to what the problem is as I have no experience with redi+'s activeX control.

I also assume its your code, as it seems that redi would have received tons of complaints if in fact the normal CPU load was 100% per order. Have you looked at the redi+ support boards?(if they have any) Do they offer any support via email?

I know Im stating the obvious, but you have said you have no coding experience so Im just trying to help you narrow down your options. Just for reference, the program I am currently writing communicates with several brokers and data vendors, and I have not had a circumstance yet that the program became unresponsive. that's with having about 20 time and sales windows open processing every tick of data on highly liquid instruments all while submitting orders based on user input and automated processes. My program uses socket connections when available from the vendor, and ActiveX controls with others. This is yet another reason I am almost positive its a coding issue on your end.

One last note, I would make sure your programmer is top notch. Even if he has no idea about trading, he should still be able to create a program to do anything based on your specs, including interfacing to an ActiveX component. There are lots of places in a trading application that you can leak money, and anyone working on one should have a strong understanding of threads, resources, and Windows system architecture in general.(assuming of course, its a Windows trading app)

- jeff
 
pjbreen,

No problem. I took a look at the link you provided, and it looks like a pretty good library they have going. You mentioned the C++ api. Since you are writing your app in C++ .NET, make sure you get the managed .NET object and not the regular C++ object. Otherwise, you will be back in this same boat of COM interop. (Meaning, the older C++ dll will still use COM as its interface).

After thinking about it some more, I had a thought that maybe the COM interop is your problem. Perhaps some objects were not mapped correctly when you imported the activex control. If I were you, I'd de-reference the activeX control and then re-import it into the project. This might fix some of your problems. Just a thought.

Also, a note on FIX. Even though it was supposed to be a standard, many companies have added custom implementations onto the protocol. Im not sure about redi+, but you might want to make sure they adhere to the standard v4.x that quickfixengine supports. It would suck to change all that code, and then find out they have a custom order entry spec that the package doesn't support. Also, I don't know if you have been to http://www.fixprotocol.org/products/ yet, but they have a ton of alternative fix engines you may want to look at.

What ever way you go, good luck.

- jeff
 
quickfix is actually pretty flexible.. you can define more messages in the master config file and it'll regenerate all the datatypes and marshalling code for you.

--Stephen

Quote from jfilla:

pjbreen,

No problem. I took a look at the link you provided, and it looks like a pretty good library they have going. You mentioned the C++ api. Since you are writing your app in C++ .NET, make sure you get the managed .NET object and not the regular C++ object. Otherwise, you will be back in this same boat of COM interop. (Meaning, the older C++ dll will still use COM as its interface).

After thinking about it some more, I had a thought that maybe the COM interop is your problem. Perhaps some objects were not mapped correctly when you imported the activex control. If I were you, I'd de-reference the activeX control and then re-import it into the project. This might fix some of your problems. Just a thought.

Also, a note on FIX. Even though it was supposed to be a standard, many companies have added custom implementations onto the protocol. Im not sure about redi+, but you might want to make sure they adhere to the standard v4.x that quickfixengine supports. It would suck to change all that code, and then find out they have a custom order entry spec that the package doesn't support. Also, I don't know if you have been to http://www.fixprotocol.org/products/ yet, but they have a ton of alternative fix engines you may want to look at.

What ever way you go, good luck.

- jeff
More...
 
pjbreen,

I'm going to help you out. I've been using the Redi API for at least 5 years, and I've never been able to get it to work reliably. It's good for about 2 orders per second maximum ... and that's under absolute ideal conditions i.e., when overall market volume is light. If you are trading lots of different stocks at once, and start monitoring the Message Table and the Position Table, you will easily bog down the system to a point where it completely hangs up or starts throwing lots of errors. Of course, most automated systems require you to update orders, so you will be forced to access the Message Table. Over the years I have looked into using Redi FIX, but everybody that I knew who was using it, had just as many or more problems. My solution was to reduce my order flow to less then 1 per second and deal with the consequences. I also never, ever update to a new version of Redi, unless I'm absolutely forced into it ... because it almost always causes new problems!

Regards,

Slave2Market
 
I'm not exactly sure about what all is needed for this FIX thing you're discussing, but you might want to take a look at SmartQuant QuantDeveloper.

You may read a lot out there regarding trading tools begin built using C++. I think that doing development in C# would be the modern approach now-a-days.

I've spent many years in C++, and started with MS C 6.0 when it was a console tool. So I have a certain inclination towards C++.

However, lately, I took a look at Microsoft's C# tool. It cuts back significantly on my fun with pointers, but in return, it takes the best of C++ and Delphi and becomes a very powerful, flexible object oriented development environment.

Where am I heading with this? Well, QuantDeveloper is written in C#.

Plus, it uses FIX objects for handling instrument information. It has native trading interfaces to IB and a mechanism of connection to the TT FIX gateway. How this works exactly, I havn't looked into yet.

In summary, to deal with the issues of a speed, FIX compatibility, and development environment, QuantDeveloper might be worthy of your evaluation.

Having said that, it is still in Beta, documentation is a bit sparse, and isn't for the faint of heart. But once you go poking around under the hood, your developer might be impressed.

Disclaimer: I'm not associated with the company, just an ATS developer talking about an impressive development environment.
 
I just tested speed of quickfixengine engine. Communication over local link between Sparc 400 Mhz and W2K I've got approx. 600 simple NewOrderSingle per second, which is not a world record but for a small group or individual should be ok.
 
I'm assuming your computer has only one processor and you are not using asynchronous delegates, threads, etc., and your code written, sofar, is not complex:

It sounds like a threading issue on their end (Redi+ ActiveX API,) in which case, your computer "locks up" for 1-2 seconds each time you call their method to send your order. To confirm this, step into the code and see if the debugger locks up on their method call. If that's the case, I'd dump Redi+ and look for another ActiveX, or better, a .NET native API vendor. It has nothing to do with ActiveX, just bad programming on their end.

If it doesn't lock up, however, then it's on your end. In other words, you are doing a lot of things with your order before you send it off to the API. For example, you may be implementing inefficient subroutines involving sorting and loops that keep track of all your orders and trades and is updated each time a new order is sent. In that case, you may want to learn about threading and asynchronous delegates so that you put lower priority subroutines on their own process that work in the background, so that your order will be send immediately and your processor will not get hosed and your program will not lock up.



Quote from pjbreen:

I've been working on an ATS and finally have a beta version that can do some live trading, but I'm having a problem.

To start- I'm not much of a programmer. Someone else is helping me out with the guts of the code, but he is not a trader. So both of us are somewhat in new territory here.

It's currently written in C++.net to the Redi+ ActiveX API. Everything is functioning properly, but the computer starts to get bogged down when it tries to send / update more than about 1 order per 1-2 seconds. Each order sent spikes CPU usage up to 100% and a series of orders will keep the CPU at 100% making the rest of the application unresponsive for a few seconds.

For anyone with this type of experience- does this sound typical of sending orders via ActiveX or does it sound like we've done something incorrectly?
If typical- will switching over to a FIX interface greatly improve things? What type of performance gain could we expect by going FIX?

And am I correct in my understanding that FIX is only for order management and data will still be ActiveX?

I've lookad at www.quickfixengine.org
Doesn't seem too bad- anybody used them?

And last- I've heard most brokers will want to test / certify your app if using FIX. Is this a complicated process?

Thanks,
PJ.
More...
 
You must log in or register to reply here.
Back
Top